wireguard-linux/drivers/usb/host, branch stable

xhci: dbc: enable back DbC in resume if it was enabled before suspend

2025-10-14T07:59:06Z

DbC is currently only enabled back if it's in configured state during suspend. If system is suspended after DbC is enabled, but before the device is properly enumerated by the host, then DbC would not be enabled back in resume. Always enable DbC back in resume if it's suspended in enabled, connected, or configured state Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event

2025-10-14T07:59:00Z

DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci-pci: Fix USB2-only root hub registration

2025-10-14T07:58:51Z

A recent change to hide USB3 root hubs of USB2-only controllers broke registration of USB2 root hubs - allow_single_roothub is set too late, and by this time xhci_run() has already deferred root hub registration until after the shared HCD is added, which will never happen. This makes such controllers unusable, but testers didn't notice since they were only bothered by warnings about empty USB3 root hubs. The bug causes problems to other people who actually use such HCs and I was able to confirm it on an ordinary HC by patching to ignore USB3 ports. Setting allow_single_roothub during early setup fixes things. Reported-by: Arisa Snowbell Closes: https://lore.kernel.org/linux-usb/CABpa4MA9unucCoKtSdzJyOLjHNVy+Cwgz5AnAxPkKw6vuox1Nw@mail.gmail.com/ Reported-by: Michal Kubecek Closes: https://lore.kernel.org/linux-usb/lnb5bum7dnzkn3fc7gq6hwigslebo7o4ccflcvsc3lvdgnu7el@fvqpobbdoapl/ Fixes: 719de070f764 ("usb: xhci-pci: add support for hosts with zero USB3 ports") Tested-by: Arisa Snowbell Tested-by: Michal Kubecek Suggested-by: Mathias Nyman Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: align PORTSC trace with one-based port numbering

2025-09-18T07:53:11Z

In the xHCI driver, port numbers are typically described using a one-based index. However, tracing currently uses a zero-based index. To ensure consistency between tracing and dynamic debugging, update the trace port number to use a one-based index. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: correct indentation for PORTSC tracing function

2025-09-18T07:53:11Z

Correct the indentation in USB Port Register Set (PORTSC) tracing. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: improve TR Dequeue Pointer mask

2025-09-18T07:53:11Z

Address the naming and usage of the TR Dequeue Pointer mask in the xhci driver. The Endpoint Context Field at offset 0x08 is defined as follows: Bit 0 Dequeue Cycle State (DCS) Bits 3:1 RsvdZ (Reserved and Zero) Bits 63:4 TR Dequeue Pointer When extracting the TR Dequeue Pointer for an Endpoint without Streams, in xhci_handle_cmd_set_deq(), the inverted Dequeue Cycle State mask (~EP_CTX_CYCLE_MASK) is used, inadvertently including the Reserved bits. Although bits 3:1 are typically zero, using the incorrect mask could cause issues. The existing mask, named "SCTX_DEQ_MASK," is misleading because "SCTX" implies exclusivity to Stream Contexts, whereas the TR Dequeue Pointer is applicable to both Stream and non-Stream Contexts. Rename the mask to "TR_DEQ_PTR_MASK", utilize GENMASK_ULL() macro and use the mask when handling the TR Dequeue Pointer field. Function xhci_get_hw_deq() returns the Endpoint Context Field 0x08, either directly from the Endpoint context or a Stream. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci-pci: add support for hosts with zero USB3 ports

2025-09-18T07:53:11Z

Add xhci support for PCI hosts that have zero USB3 ports. Avoid creating a shared Host Controller Driver (HCD) when there is only one root hub. Additionally, all references to 'xhci->shared_hcd' are now checked before use. Only xhci-pci.c requires modification to accommodate this change, as the xhci core already supports configurations with zero USB3 ports. This capability was introduced when xHCI Platform and MediaTek added support for zero USB3 ports. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181 Tested-by: Nick Nielsen Tested-by: grm1 Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: Update a comment about Stop Endpoint retries

2025-09-18T07:53:11Z

Retries are no longer gated by a quirk, so remove that part. Add a brief explanation of the timeout. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running"

2025-09-18T07:53:11Z

This reverts commit 28a76fcc4c85dd39633fb96edb643c91820133e3. No actual HW bugs are known where Endpoint Context shows Running state but Stop Endpoint fails repeatedly with Context State Error and leaves the endpoint state unchanged. Stop Endpoint retries on Running EPs have been performed since early 2021 with no such issues reported so far. Trying to handle this hypothetical case brings a more realistic danger: if Stop Endpoint fails on an endpoint which hasn't yet started after a doorbell ring and enough latency occurs before this completion event is handled, the driver may time out and begin removing cancelled TDs from a running endpoint, even though one more retry would stop it reliably. Such high latency is rare but not impossible, and removing TDs from a running endpoint can cause more damage than not giving back a cancelled URB (which wasn't happening anyway). So err on the side of caution and revert to the old policy of always retrying if the EP appears running. [Remove stable tag as we are dealing with theoretical cases -Mathias] Fixes: 28a76fcc4c85d ("usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running") Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-rcar: Add Renesas RZ/G3E USB3 Host driver support

2025-09-17T10:43:18Z

The USB3.2 Gen2 Host controller (a.k.a USB3HOST), IP found on the RZ/G3E SoC is similar to R-Car XHCI, but it doesn't require any firmware. Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20250916150255.4231-7-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman