lwn.git/drivers/usb/host/xhci-mem.c, branch docs-6.8

xhci: split free interrupter into separate remove and free parts

2023-10-21T10:38:54+00:00

The current function that both removes and frees an interrupter isn't optimal when using several interrupters. The array of interrupters need to be protected with a lock while removing interrupters, but the default xhci spin lock can't be used while freeing the interrupters event ring segment table as dma_free_coherent() should be called with IRQs enabled. There is no need to free the interrupter under the lock, so split this code into separate unlocked free part, and a lock protected remove part. Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Clean up xhci_{alloc,free}_erst() declarations

2023-10-21T10:38:54+00:00

xhci_alloc_erst() has global scope even though it's only used in xhci-mem.c. Declare it static. xhci_free_erst() was removed by commit b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support."), but a declaration in xhci.h still remains. Drop it. Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Clean up ERST_PTR_MASK inversion

2023-10-21T10:38:53+00:00

Mathias notes that the ERST_PTR_MASK macro is named as if it's masking the Event Ring Dequeue Pointer in the ERDP register, but in actuality it's masking the inverse. Invert the macro's value for clarity. Migrate it to the modern GENMASK_ULL() syntax to avoid u64 casts. Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Update last segment pointer after Event Ring expansion

2023-10-21T10:38:53+00:00

When expanding a ring at its "end", ring->last_seg needs to be updated for Event Rings as well, not just for all the other ring types. This is not a fix because ring expansion currently isn't done on the Event Ring. It's just in preparation for when it's added. Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Adjust segment numbers after ring expansion

2023-10-21T10:38:53+00:00

Initial xhci_ring allocation has just been amended to assign a monotonically increasing number to each ring segment. However rings may be expanded after initial allocation. So number newly inserted segments starting from the preceding segment in the ring and renumber all segments succeeding the newly inserted ones. This is not a fix because ring expansion currently isn't done on the Event Ring and that's the only ring type using the segment number. It's just in preparation for when either Event Ring expansion is added or when other ring types start making use of the segment number. Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Use more than one Event Ring segment

2023-10-21T10:38:53+00:00

Users have reported log spam created by "Event Ring Full" xHC event TRBs. These are caused by interrupt latency in conjunction with a very busy set of devices on the bus. The errors are benign, but throughput will suffer as the xHC will pause processing of transfers until the Event Ring is drained by the kernel. Commit dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose") mitigated the issue by advancing the Event Ring Dequeue Pointer already after half a segment has been processed. Nevertheless, providing a larger Event Ring would be useful to cope with load peaks. Expand the number of event TRB slots available by increasing the number of Event Ring segments in the ERST. Controllers have a hardware-defined limit as to the number of ERST entries they can process, but with up to 32k it can be excessively high (sec 5.3.4). So cap the actual number at 2 (configurable through the ERST_MAX_SEGS macro), which seems like a reasonable quantity. It is supported by any xHC because the limit in the HCSPARAMS2 register is defined as a power of 2. Renesas uPD720201 and VIA VL805 controllers do not support more than 2 ERST entries. An alternative to increasing the number of Event Ring segments would be an increase of the segment size. But that requires allocating multiple contiguous pages, which may be impossible if memory is fragmented. Signed-off-by: Jonathan Bell Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Set DESI bits in ERDP register correctly

2023-10-21T10:38:53+00:00

When using more than one Event Ring segment (ERSTSZ > 1), software shall set the DESI bits in the ERDP register to the number of the segment to which the upper ERDP bits are pointing. The xHC may use the DESI bits as a shortcut to determine whether it needs to check for an Event Ring Full condition: If it's enqueueing events in a different segment, it need not compare its internal Enqueue Pointer with the Dequeue Pointer in the upper bits of the ERDP register (sec 5.5.2.3.3). Not setting the DESI bits correctly can result in the xHC enqueueing events past the Dequeue Pointer. On Renesas uPD720201 host controllers, incorrect DESI bits cause an interrupt storm. For comparison, VIA VL805 host controllers do not exhibit such problems. Perhaps they do not take advantage of the optimization afforded by the DESI bits. To fix the issue, assign the segment number to each struct xhci_segment in xhci_segment_alloc(). When advancing the Dequeue Pointer in xhci_update_erst_dequeue(), write the segment number to the DESI bits. On driver probe, set the DESI bits to zero in xhci_set_hc_event_deq() as processing starts in segment 0. Likewise on driver teardown, clear the DESI bits to zero in xhci_free_interrupter() when clearing the upper bits of the ERDP register. Previously those functions (incorrectly) treated the DESI bits as if they're declared RsvdP. Signed-off-by: Lukas Wunner Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20231019102924.2797346-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: Preserve RsvdP bits in ERSTBA register correctly

2023-10-02T14:33:46+00:00

xhci_add_interrupter() erroneously preserves only the lowest 4 bits when writing the ERSTBA register, not the lowest 6 bits. Fix it. Migrate the ERST_BASE_RSVDP macro to the modern GENMASK_ULL() syntax to avoid a u64 cast. This was previously fixed by commit 8c1cbec9db1a ("xhci: fix event ring segment table related masks and variables in header"), but immediately undone by commit b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support."). Fixes: b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support.") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20230915143108.1532163-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

USB: Remove remnants of Wireless USB and UWB

2023-08-09T12:17:06+00:00

Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

xhci: Show ZHAOXIN xHCI root hub speed correctly

2023-06-13T09:34:50+00:00

Some ZHAOXIN xHCI controllers follow usb3.1 spec, but only support gen1 speed 5Gbps. While in Linux kernel, if xHCI suspport usb3.1, root hub speed will show on 10Gbps. To fix this issue of ZHAOXIN xHCI platforms, read usb speed ID supported by xHCI to determine root hub speed. And add a quirk XHCI_ZHAOXIN_HOST for this issue. [fix warning about uninitialized symbol -Mathias] Suggested-by: Mathias Nyman Cc: stable@vger.kernel.org Signed-off-by: Weitao Wang Signed-off-by: Mathias Nyman Message-ID: <20230602144009.1225632-11-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman