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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
