bcm2838_xhci: add module

bcm2838_xhci(4) is a shim for the XHCI controller on the Raspberry Pi 4B
SoC. It loads the controller's firmware before passing control to the
normal xhci(4) driver.

When xhci(4) is built as a module (and not in the kernel), bcm2838_xhci
is not built at all and the RPi4's XHCI controller won't attach due to
missing firmware.

To fix this, build a new module, bcm2838_xhci.ko, which depends on
xhci.ko. For the dependency to work correctly, also modify xhci to
provide the 'xhci' module in addition to the 'xhci_pci' module it
already provided.

Since bcm2838_xhci is specific to a quirk of the RPi4 SoC, only build
the module for AArch64.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1142

sys: Remove $FreeBSD$: one-line .c comment pattern

Remove /^/[*/]\s*\$FreeBSD\$.*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

xhci(4): Make sure allocated bandwidth is freed in hardware by unconfiguring endpoint.

MFC after: 1 week
Sponsored by: NVIDIA Networking

usb(4): Substitute "unsigned int" using the equivalent and shorter "unsigned" keyword.

MFC after: 1 week
Sponsored by: NVIDIA Networking

XHCI: remove a self-assignment

x = x is an unneeded operation, remove it.
The value is read and assigned above for real.

MFC after: 4 weeks

USB: add quirks to XHCI

While XHCI is very generic some revisions of chipsets have problems.
On dwc3 <= 3.00a Port Disable does not seem to work so we need to not
enable it.
For that introduce quirks to xhci so that controllers can steer
certain features. I would hope that this is and remains the only one.

Obtained from: an old patch mainly debugging other problems
MFC after: 2 weeks
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D35482

xhci(4): Tweak USB port speed checks to allow newer super speed generations.

This allows setting the U1 and U2 port timeout values.

MFC after: 1 week
Sponsored by: NVIDIA Networking

xhci(4): Properly define all basic USB port speeds.

MFC after: 1 week
Sponsored by: NVIDIA Networking

xhci(4): Always add and evaluate the slot context.

Because the maximum number of endpoint contexts is stored there.

Tested by: ehaupt@
PR: 262882
MFC after: 3 hours
Sponsored by: NVIDIA Networking

xhci(4): Only drop BULK and INTERRUPT endpoints to reset data toggle.

Only drop BULK and INTERRUPT endpoints, to reset the data toggle,
because for other endpoint types this is not critical.

Tested by: ehaupt@
PR: 262882
MFC after: 3 hours
Sponsored by: NVIDIA Networking

xhci(4): Ensure the so-called data toggle gets properly reset.

Use the drop and enable endpoint context commands to force a reset of
the data toggle for USB 2.0 and USB 3.0 after:
- clear endpoint halt command (when the driver wishes).
- set config command (when the kernel or user-space wants).
- set alternate setting command (only affected endpoints).

Some XHCI HW implementations may not allow the endpoint reset command when
the endpoint context is not in the halted state.

Reported by: Juniper and Gary Jennejohn
MFC after: 1 week
Sponsored by: NVIDIA Networking

xhci(4): Add quirk for "TUSB73x0 USB3.0 xHCI Controller".

Tested by: br@
MFC after: 1 week
Sponsored by: NVIDIA Networking

Fix undefined behaviour in the USB controllers

The USB controller drivers assume they can cast a NULL pointer to a
struct and find the address of a member. KUBSan complains about this so
replace with the __offsetof and __containerof macros that use either a
builtin function where available, or the same NULL pointer on older
compilers without the builtin.

Reviewers: hselasky

Subscribers: imp

Reviewed by: hselasky
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33865

xhci: Rework 64-byte context support to avoid pointer abuse

Currently, to support 64-byte contexts, xhci_ctx_[gs]et_le(32|64) take a
pointer to the field within a 32-byte context and, if 64-byte contexts
are in use, compute where the 64-byte context field is and use that
instead by deriving a pointer from the 32-byte field pointer. This is
done by exploiting a combination of 64-byte contexts being the same
layout as their 32-byte counterparts, just with 32 bytes of padding at
the end, and that all individual contexts are either in a device
context or an input context which itself is page-aligned. By masking out
the low 4 bits (which is the offset of the field within the 32-byte
contxt) of the offset within the page, the offset of the invididual
context within the containing device/input context can be determined,
which is itself 32 times the number of preceding contexts. Thus, adding
this value to the pointer again gets 64 times the number of preceding
contexts plus the field offset, which gives the offset of the 64-byte
context plus the field offset, which is the address of the field in the
64-byte context.

However, this involves a fair amount of lying to the compiler when
constructing these intermediate pointers, and is rather difficult to
reason about. In particular, this is problematic for CHERI, where we
compile the kernel with subobject bounds enabled; that is, unless
annotated to opt out (e.g. for C struct inheritance reasons where you
need to be able to downcast, or containerof idioms), a pointer to a
member of a struct is a capability whose bounds only cover that field,
and any attempt to dereference outside those bounds will fault,
protecting against intra-object buffer overflows. Thus the pointer given
to xhci_ctx_[gs]et_le(32|64) is a capability whose bounds only cover the
field in the 32-byte context, and computing the pointer to the 64-byte
context field takes the address out of bounds, resulting in a fault when
later dereferenced.

This can be cleaned up by using a different abstraction. Instead of
doing the 32-byte to 64-byte conversion on access to the field, we can
do the conversion when getting a pointer to the context itself, and
define proper 64-byte versions of contexts in order to let the compiler
do all the necessary arithmetic rather than do it manually ourselves.
This provides a cleaner implementation, works for CHERI and may even be
slightly more performant as it avoids the need to mess with masking
pointers (which cannot in the general case be optimised by compilers to
be reused across accesses to different fields within the same context,
since it does not know that the contexts are over-aligned compared with
the C ABI requirements).

Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32554

Clamp the XHCI minimum isochronous scheduling delay to the maximum value that
will work under FreeBSD, if the value is too big.

MFC after: 1 week
Sponsored by: NVIDIA Networking

Fix USB debug print after 8fc2a3c41791b205a107dc2bec16ac7514a57958 .

MFC after: 1 week
Sponsored by: NVIDIA Networking

Factor out repeated code in the USB controller drivers to avoid bugs
computing the same isochronous start frame number over and over again.

PR: 257082
MFC after: 1 week
Sponsored by: NVIDIA Networking

Make sure the XHCI driver obeys the isochronous scheduling threshold value
as given by the XHCI hardware parameters to avoid scheduling isochronous
transfers too early.

MFC after: 1 week
Sponsored by: NVIDIA Networking

No need to stop XHCI endpoints in disabled state.

Some AMD XHCI implementations apparently assert a permanent
internal failure if this happens.

Submitted by: ali.abdallah@suse.com
PR: 251503
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

Use __containerof() instead of home-rolled versions.

Reviewed by: imp, hselasky
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27582

When doing a USB alternate setting on an USB interface we need to
re-configure the XHCI endpoint context.

Differential Revision: https://reviews.freebsd.org/D27174
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

Fix for use of the XHCI driver on Cortex-A72 by adding a missing cache
flush operation before writing to the XHCI_ERSTBA_LO/HI register(s).

PR: 237666
Discussed with: Mark Millard <marklmi@yahoo.com>
MFC after: 1 week
Sponsored by: Mellanox Technologies // Nvidia

usb: clean up empty lines in .c and .h files

Fully revert r364379.

The "Intel Sunrise Point-LP USB 3.0 controller" doesn't update the wMaxPacket
field in the control endpoint context automatically causing a BABBLE error code
on the initial first USB device descriptor read, when the bMaxPacketSize is not
8 bytes.

Reported by: wulf@
PR: 248784
MFC after: 1 week
Sponsored by: Mellanox Technologies

Fix regression after r364379.

The AMD's Ryzen 3 3200g XHCI controllers apparently need the evaluate
control endpoint context command, but we don't need to issue this
command when the bMaxPacketSize is received after the read of the USB
device descriptor, because this part should be handled automatically.

PR: 248784
Tested by: emaste, hselasky
MFC after: 1 week
Sponsored by: Mellanox Technologies

Avoid evaluating the XHCI control endpoint context.

The XHCI specification says that the XHCI controller should detect
reception of the USB device descriptors, and automatically update
the max packet size in the control endpoint context.

Differential Revision: https://reviews.freebsd.org/D26104
Reviewed by: kp@
MFC after: 1 week
Sponsored by: Mellanox Technologies

Check the XHCI endpoint state before issuing XHCI endpoint commands.

Differential Revision: https://reviews.freebsd.org/D26064
Reviewed by: kp@ and bz@
MFC after: 1 week
Sponsored by: Mellanox Technologies

Set the maximum exit latency to 0 for XHCI USB 3.0 devices, because we
don't implement link power management, LPM.

This fixes error code XHCI_TRB_ERROR_BANDWIDTH for isochronous USB 3.0
transactions.

Submitted by: Horse Ma <Shichun.Ma@dell.com>
MFC after: 1 week
Sponsored by: Mellanox Technologies

Remove the power bit from the super speed root hub port status register
because it clobbers the super speed link status when a device is in super
speed mode. Currently the power bit is not needed for anything in the USB
hub driver.

This fixes USB warm reset for super speed devices.

Tested by: Shichun.Ma@dell.com
MFC after: 3 days
Sponsored by: Mellanox Technologies

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (2 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked). Use it in
preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Reviewed by: hselasky, kib
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D23632

Revert r356598 for now because it breaks some AMD based XHCI controllers.

Reported by: jkim @
MFC after: 1 week
Sponsored by: Mellanox Technologies

Check the XHCI endpoint state before stopping any endpoint.

This avoids getting the XHCI_TRB_ERROR_CONTEXT_STATE error code from the XHCI
controller when the endpoint is disabled or already stopped.

Suggested by: Shichun.Ma@dell.com
MFC after: 1 week
Sponsored by: Mellanox Technologies

Fix a XHCI driver issue with Intel's Gemini Lake SOC.

Do not configure any endpoint twice, but instead keep track of which
endpoints are configured on a per device basis, and use an evaluate
endpoint context command instead. When changing the configuration make
sure all endpoints get deconfigured and the configured endpoint mask
is reset.

This fixes an issue where an endpoint might stop working if there is
an error and the endpoint needs to be reconfigured as a part of the
error recovery mechanism in the FreeBSD USB stack.

Tested by: Shichun.Ma@dell.com
MFC after: 1 week
Sponsored by: Mellanox Technologies

Make control endpoint quirk for xhci(4) configurable.

MFC after: 1 week
Sponsored by: Mellanox Technologies

Add quirk for XHCI(4) controllers to support USB control transfers
above 1Kbyte. It might look like some XHCI(4) controllers do not
support when the USB control transfer is split using a link TRB. The
next NORMAL TRB after the link TRB is simply failing with XHCI error
code 4. The quirk ensures we allocate a 64Kbyte buffer so that the
data stage TRB is not broken with a link TRB.

Found at: EuroBSDcon 2019
MFC after: 1 week
Sponsored by: Mellanox Technologies

The maximum TD size is 31 and not 15.

Found at: EuroBSDcon 2019
MFC after: 1 week
Sponsored by: Mellanox Technologies

In xhci(4) there is no stream ID in the completion TRB.
Instead iterate all the stream IDs in stream mode to find
the matching USB transfer.

MFC after: 3 days
Sponsored by: Mellanox Technologies

Improve fix in r304629 by allowing configuration of the behaviour
through a SYSCTL instead of a compile time define.

Add quirk by default for all LynxPoint XHCI controllers.

PR: 227602
MFC after: 3 days
Sponsored by: Mellanox Technologies

Do pass removing some write-only variables from the kernel.

This reduces noise when kernel is compiled by newer GCC versions,
such as one used by external toolchain ports.

Reviewed by: kib, andrew(sys/arm and sys/arm64), emaste(partial), erj(partial)
Reviewed by: jhb (sys/dev/pci/* sys/kern/vfs_aio.c and sys/kern/kern_synch.c)
Differential Revision: https://reviews.freebsd.org/D10385

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Fix problem with suspend and resume when using Skylake chipsets. Make
sure the XHCI controller is reset after halting it. The problem is
clearly a BIOS bug as the suspend and resume is failing without
loading the XHCI driver. The same happens when using Linux and the
XHCI driver is not loaded.

Submitted by: Yanko Yankulov <yanko.yankulov@gmail.com>
PR: 216261
MFC after: 1 week

Don't separate the status stage of the XHCI USB control transfers into
its own job because this breaks the simplified QEMU XHCI TRB parser,
which expects the complete USB control transfer as a series of back to
back TRBs. The old behaviour is kept under #ifdef in case this change
breaks enumeration of any USB devices.

PR: 212021
MFC after: 1 week

Fix for invalid use of bits in input context. Basically split
configuring of EP0 and non-EP0 into xhci_cmd_evaluate_ctx() and
xhci_cmd_configure_ep() respectivly. This resolves some errors when
using XHCI under QEMU and gets is more in line with the XHCI
specification.

PR: 212021
MFC after: 1 week

Update the definition for number of scratch pages to match the latest
version of the XHCI specification. Make sure the code can handle the
maximum number of allowed scratch pages.

Submitted by: Shichun_Ma@Dell.com
Approved by: re (hrs)
MFC after: 1 week

sys/dev: extend use of the howmany() macro when available.

We have a howmany() macro in the <sys/param.h> header that is
convenient to re-use as it makes things easier to read.

Configure the correct bMaxPacketSize for control endpoints before
requesting the initial complete device descriptor and not as part of
the subsequent babble error recovery. Babble means that the received
USB packet was bigger than than configured maximum packet size. This
only affects enumeration of FULL speed USB devices which use a
bMaxPacketSize different from 8 bytes. This patch might help fix
enumeration of USB devices which exhibit USB I/O errors in dmesg
during boot.

MFC after: 1 week

- Move the remainder of host controller capability registers reading from
xhci_start_controller() to xhci_init(). These values don't change at run-
time so there's no point of acquiring them on every USB_HW_POWER_RESUME
instead of only once during initialization. In r276717, reading the first
couple of registers in question already had been moved as a prerequisite
for the changes in that revision.
- Identify ASMedia ASM1042A controllers.
- Use NULL instead of 0 for pointers.

MFC after: 3 days

Add quirk to disable 64-bit XHCI DMA after r276717.

Requested by: Gary Jennejohn <gljennjohn@gmail.com>
MFC after: 3 days

Ensure that the XHCI driver will refresh the control endpoint settings
when re-enumerating a FULL speed device. Else the wrong max packet
setting might be used when trying to re-enumerate a FULL speed device.

MFC after: 3 days

Fix DMA address casts. Regression issue after r278279.

MFC after: 3 days

Section 3.2.9 in the XHCI specification about control transfers says
that we should use a normal-TRB if there are more TRBs extending the
data-stage TRB. Add a dedicated state bit to the internal USB transfer
flags to handle this case.

Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
MFC after: 1 week

Add 64-bit DMA support in the XHCI controller driver.
- Fix some comments and whitespace while at it.

MFC after: 1 month
Submitted by: marius@

Add missed flushing of data which can happen when "xhci_configure_mask()"
is called from "xhci_configure_reset_endpoint()". Ensure the 3-strikes
error feature is always enabled except for ISOCHRONOUS transfers.

MFC after: 1 week
Suggested by: marius@

Make sure we always set the maximum number of valid contexts.

MFC after: 3 days

Set default cycle state in case of early interrupts.

MFC after: 3 days

Some XHCI hardware requires dropping the endpoint context before
adding it again.

MFC after: 3 days
Submitted by: Kohji Okuno <okuno.kohji@jp.panasonic.com>

Split the XHCI TRB allocations into smaller parts, so that we don't
end up allocating contiguous busdma buffers above PAGE_SIZE bytes.

MFC after: 1 week
Tested by: Ruslan Bukin <br@bsdpad.com>

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

These changes prevent sysctl(8) from returning proper output,
such as:

1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

- Fix a bug where the TLBPC value was forced to being odd for IN
direction isochronous transfers.
- Remove setting of fields which does not belong to the respective
TRBs. These fields are currently set as zero and this is more a
cosmetic change.

MFC after: 3 days
Submitted by: Horse Ma <HMa@wyse.com>

Setting the IMOD value below 0x3F8 can cause IRQ lockups in the Intel
LynxPoint USB 3.0 controllers found in MacBookPro 2013's.

MFC after: 2 days
Tested by: Huang Wen Hui <huanghwh@gmail.com>

Fix for infinite XHCI reset loops when the set address USB request fails.

MFC after: 2 days

Fix minor logical error in the XHCI driver. Set correct SETUP packet
direction value.

MFC after: 2 days
Reported by: Horse Ma <HMa@wyse.com>

Optimise interrupt logic. Technically writing a zero to the XHCI USB
status register has no effect. Can happen when the interrupt vector is
shared.

MFC after: 1 week

Force clearing of event ring interrupts. The "Intel Lynx Point" XHCI
controller found in the MBP2013 has been observed to not work properly
unless this operation is performed.

MFC after: 1 week
Tested by: Huang Wen Hui <huanghwh@gmail.com>

Check the XHCI event ring regardless of the XHCI status register
value. The "Intel Lynx Point" XHCI controller found in the MBP2013 has
been observed to not always set the event interrupt bit while there
are events to consume in the event ring.

MFC after: 1 week
Tested by: Huang Wen Hui <huanghwh@gmail.com>

Minor correction for the XHCI reset logic.

MFC after: 1 week
Found by: Horse Ma <HMa@wyse.com>

Fix regression issue after r259248:

Some Intel XHCI controlles timeout processing so-called "TRBs" when
the final LINK TRB of a so-called "TD" has the CHAIN-BIT set.

MFC after: 1 week
Tested by: glebius @

Set chain bit correctly. This will fix some problems sending and
receiving Zero Length Packets, ZLPs. See comment in code for more
information.

MFC after: 1 week
Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>

USB method structures for USB controllers and USB pipes should be
constant and does not need to be modified. This also saves a small
amount of RAM.

Improve the XHCI command timeout recovery handling code.

MFC after: 1 week

Comply to the XHCI specification. Certain input context fields should
always be zero.

MFC after: 1 week

Improve XHCI stability. When a command timeout happens, the command
should be aborted else the command queue can stop. Refer to section
"4.6.1.2" of the XHCI specification.

MFC after: 1 week

Stability fixes for Intel LynxPoint XHCI controllers. Disable XHCI port
routing if we get certain errors. Poll for command completion upon
command timeouts. The XHCI error events might not generate interrupts.

MFC after: 1 week
Reported by: Daniel Gerzo <danger@rulez.sk>, Antonis Anastasiadis <anastasiadis@datalive.gr>
PR: usb/181159
Approved by: re (gjb)

Revert parts of r245132 and r245175. We don't need to write to the
IMAN register to clear the pending interrupt status bits. This patch
tries to solve problems seen on the MacBook Air, as reported by
Johannes Lundberg <johannes@brilliantservice.co.jp>

MFC after: 1 week

Disable USB 3.0 streams mode by default, hence not all XHCI chipsets
implement it to avoid undefined behaviour.

Fix an XHCI regression:

The Block Event Interrupts, BEI, feature does not
work like expected with the Renesas XHCI chipsets.
Revert feature.

While at it correct the TD SIZE computation in
case of Zero Length Packet, ZLP, in the end of a
multi frame USB transfer.

MFC after: 1 week
PR: usb/180726

Fix some recent regression issues:

1) Only multi-TD isochronous transfers should use NORMAL
type after specific type as per XHCI specification.

2) BEI bit is only available in NORMAL and ISOCHRONOUS
TRB types. Don't use this bit for other types to avoid
hardware asserts. Reserved bits should be don't care
though ...

MFC after: 1 week
PR: usb/179342

Add support for polling the XHCI interrupt handler when
the regular interrupt handler is not working properly or
in case of MSI interrupts which are not yet supported.
Remove interrupt setup code for FreeBSD versions older
than 700031.

MFC after: 1 week
PR: usb/179342

Correct the TD size computation. npkt should reflect the number of packets
remaining after the current TRB has been executed. Refer to section 4.11.2.4
of the XHCI specification for USB.

MFC after: 1 week

Correct TRB type for multi TRB transfers of non-NORMAL type, like isochronous.
Only the first TRB should be markes as special. Subsequent ones should be
marked as NORMAL. Optimise away TD first variable.

MFC after: 1 week

Block event interrupts when we don't need it as soon as possible.
Typically this feature is used for isochronous transfers.
This reduces the amount of XHCI interrupting.

MFC after: 1 week

Don't set the start ISOC ASAP bit for non-isochronous TRBs.

MFC after: 1 week

Correct some XHCI streams mode transfer handling found by code inspection.
The existing streams mode support is not working and has not been tested
due to lack of hardware which supports the given feature.

MFC after: 1 week

Add descriptive comment.

Fix spelling.

Add defines to more easily allow a single threaded version of the FreeBSD
USB stack. This is useful for non-kernel purposes, like the loader.

Do not unnecessarily split a string literal, because
splitting it makes it hard to grep.

Submitted by: Christoph Mallon

Modify the FreeBSD USB kernel code so that it can be compiled directly
into the FreeBSD boot loader, typically for non-USB aware BIOSes, EFI systems
or embedded platforms. This is also useful for out of the system compilation
of the FreeBSD USB stack for various purposes. The USB kernel files can
now optionally include a global header file which should include all needed
definitions required to compile the FreeBSD USB stack. When the global USB
header file is included, no other USB header files will be included by
default.

Add new file containing the USB stack configuration for the
FreeBSD loader build.

Replace some __FBSDID()'s by /* $FreeBSD$ */ comments. Now all
USB files follow the same style.

Use cases:
- console in loader via USB
- loading kernel via USB

Discussed with: Hiroki Sato, hrs @ EuroBSDCon

Add missing NULL pointer check.

Reported by: Lars Engels
MFC after: 1 week

Shave off another register write to save some more
microseconds of PCI access time.

Tested by: sos @
Submitted by: sos @
MFC after: 1 week

Optimise the XHCI interrupt handling.
This patch will save CPU time when the XHCI interrupt is
shared with other devices.
Only check event rings when interrupt bits are set.
Otherwise would indicate hiding possible hardware fault(s).

Tested by: sos @
Submitted by: sos @
MFC after: 1 week

- Add support for Etron EJ168 USB 3.0 Host Controllers.
This brand of controllers expects that the number of
contexts specified in the input slot context points
to an active endpoint context, else it refuses to
operate.

- Ring the correct doorbell when streams mode is used.
- Wrap one or two long lines.

Tested by: Markus Pfeiffer (DragonFlyBSD)
MFC after: 1 week

Add missing CTLFLAG_TUN flag to tunable sysctls in USB stack.
Rearrange the tunables and belonging sysctl declarations, so
that they are next to eachother.

Submitted by: n_hibma @
MFC after: 1 week

Inherit USB mode from RootHUB port where the USB device is connected.
Only RootHUB ports can be dual mode. Disallow OTG ports on external HUBs.
This simplifies some checks in the USB controller drivers.

MFC after: 1 week

Add tunable for XHCI port routing.

MFC after: 1 week

Add support for the so-called streams feature of BULK endpoints
in SUPER-speed mode, USB 3.0.

This feature has not been tested yet, due to lack of hardware.

This feature is useful when implementing protocols like UASP,
USB attached SCSI which promises higher USB mass storage throughput.

This patch also implements support for hardware processing of endpoints
for increased performance. The switching to hardware processing
of an endpoint is done via a callback to the USB controller driver. The
stream feature is implemented like a variant of a hardware USB protocol.

USB controller drivers implementing device mode needs to be updated to
implement the new "xfer_stall" USB controller method and remove the
"xfer" argument from the "set_stall" method.

The API's toward existing USB drivers are preserved. To setup a USB transfer
in stream mode, set the "stream_id" field of the USB config structure to
the desired value.

The maximum number of BULK streams is currently hardcoded and limited to 8
via a define in usb_freebsd.h.

All USB drivers should be re-compiled after this change.

LibUSB will be updated next week to support streams mode. A new IOCTL to
setup BULK streams as already been implemented. The ugen device nodes
currently only supports stream ID zero.

The FreeBSD version has been bumped.

MFC after: 2 weeks

Add support for Multi-TT mode of modern USB HUBs.
This will give you more bandwidth for isochronous
FULL speed applications connected through a
High Speed HUB.

This patch has been tested with XHCI and EHCI.

MFC after: 1 week

Fix compiler warnings, mostly signed issues,
when USB modules are compiled with WARNS=9.

MFC after: 1 weeks

Bugfix: Make sure the XHCI driver doesn't clear
the route string field. Else USB 3.0 HUBs
won't work.

MFC after: 5 days

Correct use of USB 3.0 POWER bit in the port status register,
hence it was overlapping the USB 3.0 root HUB's speed bits.

Reported by: Kohji Okuno
MFC after: 1 week

- Try to fix support for USB 3.0 HUBs.
- Try to fix support for USB 3.0 suspend and resume.

MFC after: 1 week

Add missing change to XHCI driver similar to changes in r228483.

MFC after: 0 days

Make some XHCI command timeouts less strict.

Reported by: Jan Henrik Sylvester
MFC after: 1 week

Some brands of XHCI controllers needs more time to reset.

Reported by: Jan Henrik Sylvester
MFC after: 1 week

Fix size of USB 3.0 descriptor field.

MFC after: 3 days

Fix size of USB 3.0 descriptor field.

MFC after: 3 days

Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.

The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.

Fix suspend and resume of FULL and HIGH speed USB devices
in the generic XHCI driver. There appears to be some minor
logic missing for this feature to work.

MFC after: 3 days

- Add support for 64-byte contexts to XHCI driver.
- Remove some dead code.
- Fixed one instance of missing endian conversion.

Approved by: thompsa (mentor)

Remove unneeded includes of <sys/linker_set.h>. Other headers that use
it internally contain nested includes.

Reviewed by: bde

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Commit initial version of new XHCI driver which was written from
scratch. This driver adds support for USB3.0 devices. The XHCI
interface is also backwards compatible to USB2.0 and USB1.0 and will
evntually replace the OHCI/UHCI and EHCI drivers.

There will be follow-up commits during the coming week to link the
driver into the default kernel build and add missing USB3.0
functionality in the USB core. Currently only the driver files are
committed.

Approved by: thompsa (mentor)