xhci: Add support for 64-bit DMA in generic XHCI controller driver

The XHCI controller on 64-bit SoCs need to use 64-bit DMA.
Add a quirk to tell the generic XHCI driver that 32-bit DMA needs
to be

xhci: Add support for 64-bit DMA in generic XHCI controller driver

The XHCI controller on 64-bit SoCs need to use 64-bit DMA.
Add a quirk to tell the generic XHCI driver that 32-bit DMA needs
to be used, if there are any that may need to use 32-bit DMA only.

Reviewed by: andrew
Obtained from: Juniper Networks, Inc.

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

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): Add quirk for "TUSB73x0 USB3.0 xHCI Controller".

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

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

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

Let the xhci_hw_root structure span exactly XHCI_PAGE_SIZE bytes by increasing
the number of completion event TRBs. This avoids wasting memory.

MFC after: 1 week
Sponsored by: NVIDIA Networking

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

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

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 packe

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

show more ...

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r363739 through r363986.

Handle Raspberry Pi 4 xhci firmware loading.

The newer hardware revisions of the Raspberry Pi 4 removed the ability of
the VIA VL805 xhci controller to load its own firmware. Instead the
firmware mu

Handle Raspberry Pi 4 xhci firmware loading.

The newer hardware revisions of the Raspberry Pi 4 removed the ability of
the VIA VL805 xhci controller to load its own firmware. Instead the
firmware must be installed at the appropriate time by the VideoCore
coprocessor.

Submitted by: Robert Crowston <crowston_protonmail.com>
Differential Revision: https://reviews.freebsd.org/D25261

show more ...

Define the XHCI endpoint states.

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
endpoin

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

show more ...

xhci: Add support for 64-bit DMA in generic XHCI controller driver

The XHCI controller on 64-bit SoCs need to use 64-bit DMA.
Add a quirk to tell the generic XHCI driver that 32-bit DMA needs
to be

xhci: Add support for 64-bit DMA in generic XHCI controller driver

The XHCI controller on 64-bit SoCs need to use 64-bit DMA.
Add a quirk to tell the generic XHCI driver that 32-bit DMA needs
to be used, if there are any that may need to use 32-bit DMA only.

Reviewed by: andrew
Obtained from: Juniper Networks, Inc.

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

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): Add quirk for "TUSB73x0 USB3.0 xHCI Controller".

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

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

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

Let the xhci_hw_root structure span exactly XHCI_PAGE_SIZE bytes by increasing
the number of completion event TRBs. This avoids wasting memory.

MFC after: 1 week
Sponsored by: NVIDIA Networking

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