An error occurred fetching the project authors.
- 17 Feb, 2024 1 commit
-
-
Mathias Nyman authored
Each interrupter has an interrupt pending (IP) bit that should be cleared in the interrupt handler. This is done automatically for systems using MSI/MSI-X interrupts. Secondary interrupters used by audio offload may not actually trigger MSI/MSI-X messages, so driver may need to clear the IP bit manually for these, even if the primary interrupter IP is cleared automatically. Add an ip_autoclear flag to each interrupter that driver can configure when requesting an interrupt for that xHC interrupter, and move the interrupt pending clearing code to its own helper function. Use this ip_autoclear flag instead of the current hcd->msi_enabled to check if IP flag is cleared by software. [Moved ip_autoclear into xhci and set based on msi_enabled -wcheng] Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20240217001017.29969-2-quic_wcheng@quicinc.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 Jan, 2024 2 commits
-
-
Frank Li authored
Split the PORT and CAPs macro definitions into a separate file to facilitate sharing with other files without the need to include the entire xhci.h. Signed-off-by:
Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240124152525.3910311-2-Frank.Li@nxp.comSigned-off-by:
-
Mathias Nyman authored
The last TRB of a isoc TD might not trigger an event if there was an error event for a TRB mid TD. This is seen on a NEC Corporation uPD720200 USB 3.0 Host After an error mid a multi-TRB TD the xHC should according to xhci 4.9.1 generate events for passed TRBs with IOC flag set if it proceeds to the next TD. This event is either a copy of the original error, or a "success" transfer event. If that event is missing then the driver and xHC host get out of sync as the driver is still expecting a transfer event for that first TD, while xHC host is already sending events for the next TD in the list. This leads to "Transfer event TRB DMA ptr not part of current TD" messages. As a solution we tag the isoc TDs that get error events mid TD. If an event doesn't match the first TD, then check if the tag is set, and event points to the next TD. In that case give back the fist TD and process the next TD normally Make sure TD status and transferred length stay valid in both cases with and without final TD completion event. Reported-by:
Michał Pecio <michal.pecio@gmail.com> Closes: https://lore.kernel.org/linux-usb/20240112235205.1259f60c@foxbook/Tested-by:
-
- 04 Jan, 2024 1 commit
-
-
Mathias Nyman authored
Modify the XHCI drivers to accommodate for handling multiple event rings in case there are multiple interrupters. Add the required APIs so clients are able to allocate/request for an interrupter ring, and pass this information back to the client driver. This allows for users to handle the resource accordingly, such as passing the event ring base address to an audio DSP. There is no actual support for multiple MSI/MSI-X vectors. [export xhci_initialize_ring_info() -wcheng] Signed-off-by:
-
- 04 Dec, 2023 1 commit
-
-
Niklas Neronin authored
Instead of variable 'msix_count' containing the number of MSI-X vectors, now it can contains MSI or MSI-X vector amount. Because both interrupt methods allow several vectors. Thus, 'msix_count' is renamed to 'nvecs'. Additionally, instead of storing the maximum possible vector amount, now it stores the amount of successfully allocated vectors, or negative integer on allocation failure. Signed-off-by:
Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by:
-
- 23 Nov, 2023 1 commit
-
-
Hardik Gajjar authored
- The HCD address_device callback now accepts a user-defined timeout value in milliseconds, providing better control over command execution times. - The default timeout value for the address_device command has been set to 5000 ms, aligning with the USB 3.2 specification. However, this timeout can be adjusted as needed. - The xhci_setup_device function has been updated to accept the timeout value, allowing it to specify the maximum wait time for the command operation to complete. - The hub driver has also been updated to accommodate the newly added timeout parameter during the SET_ADDRESS request. Signed-off-by:
Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by:
-
- 21 Oct, 2023 6 commits
-
-
Udipto Goswami authored
In some situations where xhci removal happens parallel to xhci_handshake, we encounter a scenario where the xhci_handshake can't succeed, and it polls until timeout. If xhci_handshake runs until timeout it can on some platforms result in a long wait which might lead to a watchdog timeout. Add a helper that checks xhci status during the handshake, and exits if set state is entered. Use this helper in places where xhci_handshake is called unlocked and has a long timeout. For example xhci command timeout and xhci reset. [commit message and code comment rewording -Mathias] Signed-off-by:
Udipto Goswami <quic_ugoswami@quicinc.com> Signed-off-by:
-
Lukas Wunner authored
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 b17a57f8 ("xhci: Refactor interrupter code for initial multi interrupter support."), but a declaration in xhci.h still remains. Drop it. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Lukas Wunner authored
Commit ebd88cf5 ("xhci: Remove unused defines for ERST_SIZE and ERST_ENTRIES") removed the ERST_SIZE macro but retained a code comment explaining the quantity chosen in the macro. Remove the code comment as well. Signed-off-by:
-
Lukas Wunner authored
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:
-
Jonathan Bell authored
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 dc0ffbea ("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 <jonathan@raspberrypi.com> Signed-off-by:
-
Lukas Wunner authored
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:
-
- 02 Oct, 2023 3 commits
-
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct urb_priv. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20230915195812.never.371-kees@kernel.orgSigned-off-by:
Kees Cook <keescook@chromium.org>
-
Lukas Wunner authored
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 8c1cbec9 ("xhci: fix event ring segment table related masks and variables in header"), but immediately undone by commit b17a57f8 ("xhci: Refactor interrupter code for initial multi interrupter support."). Fixes: b17a57f8 ("xhci: Refactor interrupter code for initial multi interrupter support.") Signed-off-by:
-
Krishna Kurapati authored
DWC3 driver needs access to XHCI Extended Capabilities registers to read number of usb2 ports and usb3 ports present on multiport controller. Since the extcaps header is sufficient to parse this info, move port_count related macros and structure from xhci.h to xhci-ext-caps.h. Signed-off-by:
Krishna Kurapati <quic_kriskura@quicinc.com> Link: https://lore.kernel.org/r/20230828133033.11988-4-quic_kriskura@quicinc.comAcked-by:
-
- 13 Jun, 2023 4 commits
-
-
Weitao Wang authored
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:
Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by:
-
Weitao Wang authored
On some ZHAOXIN hosts, xHCI will prefetch TRB for performance improvement. However this TRB prefetch mechanism may cross page boundary, which may access memory not allocated by xHCI driver. In order to fix this issue, two pages was allocated for a segment and only the first page will be used. And add a quirk XHCI_ZHAOXIN_TRB_FETCH for this issue. Cc: stable@vger.kernel.org Signed-off-by:
-
Mathias Nyman authored
Trying to keep track of free trbs in a ring by adding and subtracting deltas each time a enqueue or dequeue is increased or moved has proven to be buggy and complicated, especially over long periods of time. Recently a bug in counting free trbs was fixed, now taking into account cancelled URBs that were turned into no-ops, preventing free_trbs to slowly wander off causing unnecessary ring expansion. See commit fe82f16a ("xhci: Fix incorrect tracking of free space on transfer rings") Turns out its a lot easier to just calculate the numer of free TRB based on ring size and the current enqueue and dequeue pointer values. This is currently only needed for the command ring as multi segment transfer rings already ensures there is enough room the ring during the ring expansion check. We could get rid of the ring->num_trbs_free entry completely, but as the xhci DbC code also uses it we don't clean that up in this patch. Reported-by:
Miller Hunter <MillerH@hearthnhome.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217242Tested-by:
-
Mathias Nyman authored
The XHCI_PLAT quirk was only needed to ensure non-PCI xHC host avoided setting up MSI interrupts in generic xhci codepaths. The MSI setup code is now moved to PCI specific xhci-pci.c file so the quirk is no longer needed. Remove setting the XHCI_PLAT quirk for HiSilocon SoC xHC, NVIDIA Tegra xHC, MediaTek xHC, the generic xhci-plat driver, and the checks for XHCI_PLAT in xhci-pci.c MSI setup code. Signed-off-by:
-
- 16 May, 2023 1 commit
-
-
Mario Limonciello authored
Donghun reports that a notebook that has an AMD Ryzen 5700U but supports S3 has problems with USB after resuming from suspend. The issue was bisected down to commit d1658268 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir"). As this issue only happens on S3, narrow the broken D3cold quirk to only run in s2idle. Fixes: d1658268 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir") Reported-and-tested-by:
Donghun Yoon <donghun.yoon@lge.com> Cc: stable@vger.kernel.org Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
- 13 May, 2023 1 commit
-
-
Basavaraj Natikar authored
Currently, the pci_resume method has only a flag indicating whether the system is resuming from hibernation. In order to handle all PM events like AUTO_RESUME (runtime resume from device in D3), RESUME (system resume from s2idle, S3 or S4 states) etc change the pci_resume method to handle all PM events. Signed-off-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
-
- 23 Mar, 2023 4 commits
-
-
Josue David Hernandez Gutierrez authored
Move function to cleanup MSI from xhci.c to xhci-pci.c This is to decouple PCI specific code from generic xhci code. No functional changes, function is an exact copy Signed-off-by:
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by:
-
Josue David Hernandez Gutierrez authored
Call the PCI specific MSI/MSIX interrupt freeing code from the xhci-pci callbacks instead of generic xhci code, decoupling PCI parts from generic xhci functions. Adds xhci_pci_stop() that overrides xhci_stop() for PCI xHC controllers. This will free MSIX interrupts a bit later in the hc_driver stop callback, but is still earlier than usb core frees "legacy" interrupts, or interrupts for other hosts. Signed-off-by:
-
Josue David Hernandez Gutierrez authored
Move functions to setup msi from xhci.c to xhci-pci.c to decouple PCI specific code from generic xhci code. No functional changes, functions are an exact copy [commit message rewording -Mathias] Signed-off-by:
-
Josue David Hernandez Gutierrez authored
xhci MSI setup is currently done at the same time as xHC host is started in xhci_run(). This couples the generic xhci code with PCI, and will reconfigure MSI/MSIX interrupts every time xHC is started. Decouple MSI/MSIX configuration from generic xhci code by moving MSI/MSIX part to a PCI specific xhci_pci_run() function overriding xhci_run(). This allows us to remove unnecessay MSI/MSIX reconfiguration done every time PCI xhci resumes from suspend. i.e. remove the xhci_cleanup_msix() call from xhci_resume() and the xhci_try_enale_msi() call in xhci_run() called a bit later by xhci_resume() [minor changes and commit message rewrite -Mathias] Signed-off-by:
-
- 02 Feb, 2023 4 commits
-
-
Mathias Nyman authored
resume_done is just a timestamp, avoid confusing it with completions related to port state transitions that are named *_done Signed-off-by:
-
Mathias Nyman authored
Now that we have a port structure for each port it makes sense to move per port variables, timestamps and completions there. Get rid of storing bitfileds and arrays of port specific items per bus. Move unsigned long resume_done; insigned long rexit_ports struct completion rexit_done; struct completion u3exit_done; Rename rexit_ports to rexit_active, and remove a redundant hcd speed check while checking if rexit_active is set. Signed-off-by:
-
Mathias Nyman authored
xHC supports several interrupters, each with its own mmio register set, event ring and MSI/MSI-X vector. Transfers can be assigned different interrupters when queued. See xhci 4.17 for details. Current driver only supports one interrupter. Create a xhci_interrupter structure containing an event ring, pointer to mmio registers for this interrupter, variables to store registers over s3 suspend, erst, etc. Add functions to create and free an interrupter, and pass an interrupter pointer to functions that deal with events. Secondary interrupters are also useful without having an interrupt vector. One use case is the xHCI audio sideband offloading where a DSP can take care of specific audio endpoints. When all transfer events of an offloaded endpoint can be mapped to a separate interrupter event ring the DSP can poll this ring, and we can mask these events preventing waking up the CPU. Only minor functional changes such as clearing some of the interrupter registers when freeing the interrupter. Still create only one primary interrupter. Signed-off-by:
-
Mathias Nyman authored
xHC controller can supports up to 1024 interrupters. To fit these change the max_interrupters varable from u8 to u16. Add a separate mask for the reserve and preserve bits [5:0] in the erst base register and use it instead of the ERST_PRT_MASK. ERSR_PTR_MASK [3:0] is intended for masking bits in the event ring dequeue pointer register. Signed-off-by:
-
- 17 Jan, 2023 3 commits
-
-
Jim Lin authored
Add a hub_control() callback to the xhci_driver_overrides structure to allow host drivers to override the default hub_control function. This is required for Tegra which requires device specific actions for power management to be executed during USB state transitions. Signed-off-by:
Jim Lin <jilin@nvidia.com> Reviewed-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Mathias Nyman authored
One USB3 roothub port may support link power management, while another root port on the same xHC can't due to different retimers used for the ports. This is the case with Intel Alder Lake, and possible future platforms where retimers used for USB4 ports cause too long exit latecy to enable native USB3 lpm U1 and U2 states. Add a flag in the xhci port structure to indicate if the port is lpm_incapable, and check it while calculating exit latency. Cc: stable@vger.kernel.org Signed-off-by:
-
Mathias Nyman authored
Allow PCI hosts to check and tune roothub and port settings before the hub is up and running. This override is needed to turn off U1 and U2 LPM for some ports based on per port ACPI _DSM, _UPC, or possibly vendor specific mmio values for Intel xHC hosts. Usb core calls the host update_hub_device once it creates a hub. Entering U1 or U2 link power save state on ports with this limitation will cause link to fail, turning the usb device unusable in that setup. Cc: stable@vger.kernel.org Signed-off-by:
-
- 30 Nov, 2022 1 commit
-
-
Mathias Nyman authored
Make sure to also limit the amount of soft reset retries for transaction errors on streams in cases where the transaction error event doesn't point to any specific TRB. In these cases we don't know the TRB or stream ring, but we do know which endpoint had the error. To keep error counting simple and functional, move the current err_count from ring structure to endpoint structure. Cc: stable@vger.kernel.org Signed-off-by:
-
- 25 Oct, 2022 1 commit
-
-
Mathias Nyman authored
Systems based on Alder Lake P see significant boot time delay if boot firmware tries to control usb ports in unexpected link states. This is seen with self-powered usb devices that survive in U3 link suspended state over S5. A more generic solution to power off ports at shutdown was attempted in commit 83810f84 ("xhci: turn off port power in shutdown") but it caused regression. Add host specific XHCI_RESET_TO_DEFAULT quirk which will reset host and ports back to default state in shutdown. Cc: stable@vger.kernel.org Signed-off-by:
-
- 22 Sep, 2022 2 commits
-
-
Mathias Nyman authored
xhci used to test if link power management (LPM) capable USB2 devices really could enter and exit L1 state link state. Failed devices were added to a lpm_failed_dev list. This feature was removed 9 years ago in commit de68bab4 ("usb: Don't enable USB 2.0 Link PM by default.") but lpm_failed_dev member was still left. Remove it now. Signed-off-by:
-
Mathias Nyman authored
The u32 command was added to struct xhci_hcd over 10 years ago in commit 9777e3ce ("USB: xHCI: bus power management implementation") It wasn't even used back then, so remove it. Signed-off-by:
-
- 05 Sep, 2022 1 commit
-
-
Greg Kroah-Hartman authored
This is only called in the xhci.c file, so make the symbol static. Cc: Mathias Nyman <mathias.nyman@intel.com> Link: https://lore.kernel.org/r/20220901134744.2039891-1-gregkh@linuxfoundation.orgSigned-off-by:
-
- 31 Aug, 2022 1 commit
-
-
Justin Chen authored
Introduce XHCI_SUSPEND_RESUME_CLKS quirk as a means to suspend and resume clocks if the hardware is capable of doing so. We assume that clocks will be needed if the device may wake. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Justin Chen <justinpopo6@gmail.com> Link: https://lore.kernel.org/r/1660170455-15781-2-git-send-email-justinpopo6@gmail.comSigned-off-by:
-
- 25 Aug, 2022 2 commits
-
-
Mathias Nyman authored
This reverts commit 83810f84. Turning off port power in shutdown did cause issues such as a laptop not proprly powering off, and some specific usb devies failing to enumerate the subsequent boot after a warm reset. So revert this. Fixes: 83810f84 ("xhci: turn off port power in shutdown") Signed-off-by:
-
Mathias Nyman authored
After xHC controller is started, either in probe or resume, it can take a while before any of the connected usb devices are visible to the roothub due to link training. It's possible xhci driver loads, sees no acivity and suspends the host before the USB device is visible. In one testcase with a hotplugged xHC controller the host finally detected the connected USB device and generated a wake 500ms after host initial start. If hosts didn't suspend the device duringe training it probablty wouldn't take up to 500ms to detect it, but looking at specs reveal USB3 link training has a couple long timeout values, such as 120ms RxDetectQuietTimeout, and 360ms PollingLFPSTimeout. So Add a 500ms grace period that keeps polling the roothub for 500ms after start, preventing runtime suspend until USB devices are detected. Cc: stable@vger.kernel.org Signed-off-by:
-
