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

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

show more ...

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

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

show more ...

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 quirk

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

show more ...

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

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

show more ...

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

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

show more ...

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 wit

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

show more ...

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 con

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

show more ...

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 Network

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

show more ...

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 b

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

show more ...

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 a

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

show more ...

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: Me

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

show more ...

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

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

show more ...

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 fir

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

show more ...