summaryrefslogtreecommitdiff
path: root/drivers/usb/host
AgeCommit message (Collapse)Author
7 daysusb: ohci-nxp: clean up probe error labelsJohan Hovold
Error labels should be named after what they do rather than after from where they are jumped to. Rename the probe error labels for consistency and to improve readability. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251218153519.19453-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7 daysusb: ohci-nxp: fix device leak on probe failureJohan Hovold
Make sure to drop the reference taken when looking up the PHY I2C device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: 73108aa90cbf ("USB: ohci-nxp: Use isp1301 driver") Cc: stable@vger.kernel.org # 3.5 Reported-by: Ma Ke <make24@iscas.ac.cn> Link: https://lore.kernel.org/lkml/20251117013428.21840-1-make24@iscas.ac.cn/ Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251218153519.19453-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
13 daysxhci: dbgtty: fix device unregister: fixupŁukasz Bartosik
This fixup replaces tty_vhangup() call with call to tty_port_tty_vhangup(). Both calls hangup tty device synchronously however tty_port_tty_vhangup() increases reference count during the hangup operation using scoped_guard(tty_port_tty). Cc: stable <stable@kernel.org> Fixes: 1f73b8b56cf3 ("xhci: dbgtty: fix device unregister") Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org> Link: https://patch.msgid.link/20251127111644.3161386-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-06Merge tag 'usb-6.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver updates for 6.19-rc1. Nothing major here, just lots of tiny updates for most of the common USB drivers. Included in here are: - more xhci driver updates and fixes - Thunderbolt driver cleanups - usb serial driver updates - typec driver updates - USB tracepoint additions - dwc3 driver updates, including support for Apple hardware - lots of other smaller driver updates and cleanups All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (161 commits) usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt USB: serial: option: move Telit 0x10c7 composition in the right place USB: serial: option: add Telit Cinterion FE910C04 new compositions usb: typec: ucsi: fix use-after-free caused by uec->work usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() usb: dwc3: core: Remove redundant comment in core init usb: phy: Initialize struct usb_phy list_head USB: serial: option: add Foxconn T99W760 usb: usb-storage: No additional quirks need to be added to the EL-R12 optical drive. usb: typec: hd3ss3220: Enable VBUS based on ID pin state dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state usb: typec: anx7411: add WQ_PERCPU to alloc_workqueue users USB: add WQ_PERCPU to alloc_workqueue users dt-bindings: usb: dwc3-xilinx: Describe the reset constraint for the versal platform drivers/usb/storage: use min() instead of min_t() usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE usb: ohci-da8xx: remove unused platform data usb: gadget: functionfs: use dma_buf_unmap_attachment_unlocked() helper usb: uas: reduce time under spinlock usb: dwc3: eic7700: Add EIC7700 USB driver ...
2025-12-02Merge tag 'pm-6.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "There are quite a few interesting things here, including new hardware support, new features, some bug fixes and documentation updates. In addition, there are a usual bunch of minor fixes and cleanups all over. In the new hardware support category, there are intel_pstate and intel_rapl driver updates to support new processors, Panther Lake, Wildcat Lake, Noval Lake, and Diamond Rapids in the OOB mode, OPP and bandwidth allocation support in the tegra186 cpufreq driver, and JH7110S SOC support in dt-platdev cpufreq. The new features are the PM QoS CPU latency limit for suspend-to-idle, the netlink support for the energy model management, support for terminating system suspend via a wakeup event during the sync of file systems, configurable number of hibernation compression threads, the runtime PM auto-cleanup macros, and the "poweroff" PM event that is expected to be used during system shutdown. Bugs are mostly fixed in cpuidle governors, but there are also fixes elsewhere, like in the amd-pstate cpufreq driver. Documentation updates include, but are not limited to, a new doc on debugging shutdown hangs, cross-referencing fixes and cleanups in the intel_pstate documentation, and updates of comments in the core hibernation code. Specifics: - Introduce and document a QoS limit on CPU exit latency during wakeup from suspend-to-idle (Ulf Hansson) - Add support for building libcpupower statically (Zuo An) - Add support for sending netlink notifications to user space on energy model updates (Changwoo Mini, Peng Fan) - Minor improvements to the Rust OPP interface (Tamir Duberstein) - Fixes to scope-based pointers in the OPP library (Viresh Kumar) - Use residency threshold in polling state override decisions in the menu cpuidle governor (Aboorva Devarajan) - Add sanity check for exit latency and target residency in the cpufreq core (Rafael Wysocki) - Use this_cpu_ptr() where possible in the teo governor (Christian Loehle) - Rework the handling of tick wakeups in the teo cpuidle governor to increase the likelihood of stopping the scheduler tick in the cases when tick wakeups can be counted as non-timer ones (Rafael Wysocki) - Fix a reverse condition in the teo cpuidle governor and drop a misguided target residency check from it (Rafael Wysocki) - Clean up multiple minor defects in the teo cpuidle governor (Rafael Wysocki) - Update header inclusion to make it follow the Include What You Use principle (Andy Shevchenko) - Enable MSR-based RAPL PMU support in the intel_rapl power capping driver and arrange for using it on the Panther Lake and Wildcat Lake processors (Kuppuswamy Sathyanarayanan) - Add support for Nova Lake and Wildcat Lake processors to the intel_rapl power capping driver (Kaushlendra Kumar, Srinivas Pandruvada) - Add OPP and bandwidth support for Tegra186 (Aaron Kling) - Optimizations for parameter array handling in the amd-pstate cpufreq driver (Mario Limonciello) - Fix for mode changes with offline CPUs in the amd-pstate cpufreq driver (Gautham Shenoy) - Preserve freq_table_sorted across suspend/hibernate in the cpufreq core (Zihuan Zhang) - Adjust energy model rules for Intel hybrid platforms in the intel_pstate cpufreq driver and improve printing of debug messages in it (Rafael Wysocki) - Replace deprecated strcpy() in cpufreq_unregister_governor() (Thorsten Blum) - Fix duplicate hyperlink target errors in the intel_pstate cpufreq driver documentation and use :ref: directive for internal linking in it (Swaraj Gaikwad, Bagas Sanjaya) - Add Diamond Rapids OOB mode support to the intel_pstate cpufreq driver (Kuppuswamy Sathyanarayanan) - Use mutex guard for driver locking in the intel_pstate driver and eliminate some code duplication from it (Rafael Wysocki) - Replace udelay() with usleep_range() in ACPI cpufreq (Kaushlendra Kumar) - Minor improvements to various cpufreq drivers (Christian Marangi, Hal Feng, Jie Zhan, Marco Crivellari, Miaoqian Lin, and Shuhao Fu) - Replace snprintf() with scnprintf() in show_trace_dev_match() (Kaushlendra Kumar) - Fix memory allocation error handling in pm_vt_switch_required() (Malaya Kumar Rout) - Introduce CALL_PM_OP() macro and use it to simplify code in generic PM operations (Kaushlendra Kumar) - Add module param to backtrace all CPUs in the device power management watchdog (Sergey Senozhatsky) - Rework message printing in swsusp_save() (Rafael Wysocki) - Make it possible to change the number of hibernation compression threads (Xueqin Luo) - Clarify that only cgroup1 freezer uses PM freezer (Tejun Heo) - Add document on debugging shutdown hangs to PM documentation and correct a mistaken configuration option in it (Mario Limonciello) - Shut down wakeup source timer before removing the wakeup source from the list (Kaushlendra Kumar, Rafael Wysocki) - Introduce new PMSG_POWEROFF event for system shutdown handling with the help of PM device callbacks (Mario Limonciello) - Make pm_test delay interruptible by wakeup events (Riwen Lu) - Clean up kernel-doc comment style usage in the core hibernation code and remove unuseful comments from it (Sunday Adelodun, Rafael Wysocki) - Add support for handling wakeup events and aborting the suspend process while it is syncing file systems (Samuel Wu, Rafael Wysocki) - Add WQ_UNBOUND to pm_wq workqueue (Marco Crivellari) - Add runtime PM wrapper macros for ACQUIRE()/ACQUIRE_ERR() and use them in the PCI core and the ACPI TAD driver (Rafael Wysocki) - Improve runtime PM in the ACPI TAD driver (Rafael Wysocki) - Update pm_runtime_allow/forbid() documentation (Rafael Wysocki) - Fix typos in runtime.c comments (Malaya Kumar Rout) - Move governor.h from devfreq under include/linux/ and rename to devfreq-governor.h to allow devfreq governor definitions in out of drivers/devfreq/ (Dmitry Baryshkov) - Use min() to improve readability in tegra30-devfreq.c (Thorsten Blum) - Fix potential use-after-free issue of OPP handling in hisi_uncore_freq.c (Pengjie Zhang) - Fix typo in DFSO_DOWNDIFFERENTIAL macro name in governor_simpleondemand.c in devfreq (Riwen Lu)" * tag 'pm-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (96 commits) PM / devfreq: Fix typo in DFSO_DOWNDIFFERENTIAL macro name cpuidle: Warn instead of bailing out if target residency check fails cpuidle: Update header inclusion Documentation: power/cpuidle: Document the CPU system wakeup latency QoS cpuidle: Respect the CPU system wakeup QoS limit for cpuidle sched: idle: Respect the CPU system wakeup QoS limit for s2idle pmdomain: Respect the CPU system wakeup QoS limit for cpuidle pmdomain: Respect the CPU system wakeup QoS limit for s2idle PM: QoS: Introduce a CPU system wakeup QoS limit cpuidle: governors: teo: Add missing space to the description PM: hibernate: Extra cleanup of comments in swap handling code PM / devfreq: tegra30: use min to simplify actmon_cpu_to_emc_rate PM / devfreq: hisi: Fix potential UAF in OPP handling PM / devfreq: Move governor.h to a public header location powercap: intel_rapl: Enable MSR-based RAPL PMU support powercap: intel_rapl: Prepare read_raw() interface for atomic-context callers cpufreq: qcom-nvmem: fix compilation warning for qcom_cpufreq_ipq806x_match_list PM: sleep: Call pm_sleep_fs_sync() instead of ksys_sync_helper() PM: sleep: Add support for wakeup during filesystem sync cpufreq: ACPI: Replace udelay() with usleep_range() ...
2025-11-21xhci: dbgtty: fix device unregisterŁukasz Bartosik
When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable@kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: ohci-da8xx: remove unused platform dataBartosz Golaszewski
We no longer support any board files for DaVinci in mainline and so struct da8xx_ohci_root_hub is no longer used. Remove it together with all the code it's used for. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20251114-davinci-usb-v1-1-737380353a74@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://patch.msgid.link/20251111095117.95023-1-sakari.ailus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: host: ohci-platform: Call reset assert/deassert on suspend/resumeClaudiu Beznea
The Renesas RZ/G3S SoC supports a power-saving mode in which power to most of the SoC components is turned off, including the USB blocks. On the resume path, the reset signal must be de-asserted before applying any settings to the USB registers. To handle this properly, call reset_control_assert() and reset_control_deassert() during suspend and resume, respectively. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251106143625.3050119-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: host: ehci-platform: Call reset assert/deassert on suspend/resumeClaudiu Beznea
The Renesas RZ/G3S SoC supports a power-saving mode in which power to most of the SoC components is turned off, including the USB blocks. On the resume path, the reset signal must be de-asserted before applying any settings to the USB registers. To handle this properly, call reset_control_assert() and reset_control_deassert() during suspend and resume, respectively. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20251106143625.3050119-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: host: Do not check priv->clks[clk]Claudiu Beznea
There is no need to check the entries in priv->clks[] array before passing it to clk_disable_unprepare() as the clk_disable_unprepare() already check if it receives a NULL or error pointer as argument. Remove this check. This makes the code simpler. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251106143625.3050119-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: Add debugfs support for xHCI Port Link Info (PORTLI) register.Rai, Amardeep
Each xHCI roothub port has a Port Link Info (PORTLI) register that is used by USB3 and eUSB2V2 ports. USB3 ports show link error count, rx lane count, and tx lane count. eUSB2V2 ports show Rx Data Rate (RDR) and Tx Data Rate (TDR). Rx/Tx Data Rate is a multiple of USB2 2.0 HS 480 Mb/s data rates, and is only valid if a eUSB2V2 device is connected (CCS=1). 0 = "USB 2.0 HS" normal HS 480 Mb/s, no eUSB2V2 in use 1 = "HS1" Assymetric eUSB2V2 where this direction runs normal 480Mb/s 2 = "HS2" 960Mb/s ... 10 = "HS10" 4.8 Gb/s, max eUSB2V2 rate PORTLI is Reserved and preserve "RsvdP" for normal USB2 ports Sample output of USB3 port PORTLI: cat /sys/kernel/debug/usb/xhci/0000:00:14.0/ports/port14/portli 0x00000000 LEC=0 RLC=0 TLC=0 Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-24-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: standardize single bit-field macrosNiklas Neronin
Convert single bit-field macros to simple masks. The change makes the masks more universal. Multi bit-field macros are changed in the next commit. After both changes, all masks in xhci-caps.h will follow the same format. I plan to introduce this change to all xhci macros. Bit shift operations on a 32-bit signed can be problematic on some architectures. Instead use BIT() macro, which returns a 64-bit unsigned value. This ensures that the shift operation is performed on an unsigned type, which is safer and more portable across different architectures. Using unsigned integers for bit shifts avoids issues related to sign bits and ensures consistent behavior. Switch from 32-bit to 64-bit? As far as I am aware, this does not cause any issues. Performing bitwise operations between 32 and 64 bit values, the smaller operand is promoted to match the size of the larger one, resulting in a 64-bit operation. This promotion extends the 32-bit value to 64 bits, by zero-padding (for unsigned). Will the change to 64-bit slow down the xhci driver? On a 64-bit architecture - No. On a 32-bit architecture, yes? but in my opinion the performance decrease does not outweigh the readability and other benefits of using BIT() macro. Why not use FIELD_GET() and FIELD_PREP()? While they can be used for single bit macros, I prefer to use simple bitwise operation directly. Because, it takes less space, is less overhead and is as clear as if using FIELD_GET() and FIELD_PREP(). Why not use test_bit() macro? Same reason as with FIELD_GET() and FIELD_PREP(). Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-23-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: drop xhci-caps.h dependence on xhci-ext-caps.hNiklas Neronin
Drop the dependency of xhci-caps.h on xhci-ext-caps.h by eliminating 2 instances where macros in xhci-caps.h were redefined from xhci-ext-caps.h. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-22-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: simplify Max Scratchpad buffer macrosNiklas Neronin
Max Scratchpad Buffers consist of two bit-fields: bits 25:21 - Max Scratchpad Buffers High, 5 Most significant bits bits 27:31 - Max Scratchpad Buffers Low, 5 Least significant bits Combined they create the Max Scratchpad Buffers value. Add two new macros, 'HCS_MAX_SP_HI' and 'HCS_MAX_SP_LO', to separately extract the high and low parts of the Max Scratchpad Buffers. These are then combined using 'HCS_MAX_SCRATCHPAD' macro. This change simplifies the code and makes it similar to other split value register macros in the xhci driver. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-21-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: simplify Isochronous Scheduling Threshold handlingNiklas Neronin
The IST is represented by bits 2:0, with bit 3 indicating the unit of measurement, Frames or Microframes. Introduce xhci_ist_microframes(), which returns the IST value in Microframes, simplifying the code and reducing duplication. Improve documentation in xhci-caps.h to clarify the IST register specifics, including the unit conversion details. These change removes the need to explain it each time the IST values is retrieved. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-20-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: improve xhci-caps.h commentsNiklas Neronin
No functional changes. This patch updates comments in xhci-caps.h for better readability and consistency. Each Capability Register bit field now includes a brief description of its name and valid range, following a uniform comment format across the file. These updates are based on the xHCI specification, revision 1.2. Bit field comment format: /* <bit range> - <Field name>,<noteworthy information if any> */ Why print the bit range? The bit range aids in identifying missing macros and reserved bit ranges. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-19-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: limit number of interrupts to 128Niklas Neronin
The xHCI driver defines only 128 interrupter register slots, yet allows up to 2047 interrupters. According to the xHCI specification, the maximum valid number of interrupters is 1024. These mismatches can lead to out-of-range accesses and excessive memory use. The Number of Interrupters (MaxIntrs) field occupies bits 18:8 of the HCSPARAMS1 register, which can yield a value up to 2047, although the specification limits it to 1024. Cap the value using the 'MAX_HC_INTRS' macro. Set 'xhci->max_intrs' to the minimum of the value reported by the HCSPARAMS1 register and 'MAX_HC_INTRS'. The interrupter register slot array is defined for 1024 entries, serving only as a structural template and not increasing memory usage. Although the xHCI specification allows up to 1024 interrupters, raising 'MAX_HC_INTRS' above 128 provides no practical benefit. The driver only uses the primary interrupter (0), and secondary interrupters (1+) are rarely, if ever, used in practice. No reports exist of usage beyond 128. Therefore, I have limited it to 128. Summary: * Interrupter allocations are now limited to 128 from 2047. * Interrupter Register template slots are set to 1024 from 128. * Macro 'MAX_HC_INTRS' can be modified to set the interrupter limit. ==== Detailed interrupter explanation ==== There are two relevant components: Interrupter array: This holds the software interrupter structures and is allocated by the xhci driver. The number of interrupters allocated is determined by the HCSPARAMS1 register field, which specifies the supported interrupter count. Interrupter register slots: This is a template struct used to access the hardware's runtime registers. It is not allocated by the driver, the hardware defines and owns this memory region, and the driver only maps it for MMIO access. Each entry in the interrupter array points to its corresponding interrupter register slot in the hardware region once that interrupter is enabled. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: limit number of ports to 127Niklas Neronin
The xHCI driver allocates various port-related structures based on the maximum number of ports reported by the controller. The Number of Ports (MaxPorts) field occupies bits 31:24 of the HCSPARAMS1 register and can represent values up to 255. However, the 'HCS_MAX_PORTS()' macro currently reads bits 30:24, effectively limiting the maximum to 127. Fixing the macro increases the reported port limit to 255, which in turn increases memory usage regardless of how many ports are actually used. To maintain compatibility and control memory consumption, set 'xhci->max_ports' to the minimum of the value read from 'HCS_MAX_PORTS()' and 127 (MAX_HC_PORTS). This preserves the existing limit while making the restriction explicit and easier to adjust in the future. Summary: * Port allocations are now limited to 127. * HC max ports macro now correctly reads the MaxPorts value. * Macro 'MAX_HC_PORTS' can be modified to set the port limit. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: simplify handling of Structural Parameters 1 valuesNiklas Neronin
The 32-bit read-only HCSPARAMS1 register contains the following fields: Bits 7:0 - Number of Device Slots (MaxSlots) Bits 18:8 - Number of Interrupters (MaxIntrs) Bits 23:19 - Reserved Bits 31:24 - Number of Ports (MaxPorts) Since the register value is constant for the lifetime of the controller, it is cached in 'xhci->hcs_params1'. However, platform drivers may override the number of interrupters through a separate variable, 'xhci->max_interrupters', leaving only the maximum slots and ports values still derived from the cached register. To simplify the code and improve readability, replace 'xhci->hcs_params1' with two dedicated 'u8' fields: 'xhci->max_slots' and 'xhci->max_ports'. These values are initialized once and used directly instead of calling 'HCS_MAX_SLOTS()' and 'HCS_MAX_PORTS()' macros. This change reduces code clutter without increasing memory usage. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: use cached HCSPARAMS1 valueNiklas Neronin
The Structural Parameters 1 (HCSPARAMS1) register is read and cached in 'xhci->hcs_params1' during host controller initialization. Since this register is read-only and its value remains constant for the lifetime of the controller, re-reading it later is unnecessary. Replace subsequent register reads with the cached 'xhci->hcs_params1' value to avoid redundant MMIO access. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: remove unused trace operation and argumentNiklas Neronin
Remove endpoint number 'ep_num' argument and memory operation from xhci_log_ctx() trace function. These changes were added in commit 1d27fabec068 ("xhci: add xhci_address_ctx trace event") on Aug 14, 2013 and have never been used. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: remove deprecated TODO commentNiklas Neronin
The Device Context Base Address Array (DCBAA) contains pointers to device contexts. These fields are 64-bit registers, capable of holding 64-bit addresses. When struct 'xhci_device_context_array' was introduced in commit [1], the entries were represented as pairs of 'u32', requiring a custom helper function to set 64-bit addresses. This was later made redundant by commit [2], which changed the representation to a single 'u64', allowing direct assignment. The associated TODO comment referencing the old 32-bit representation is no longer relevant and is removed. Link: https://git.kernel.org/torvalds/c/a74588f94655 [1] Link: https://git.kernel.org/torvalds/c/8e595a5d30a5 [2] Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Switch to using system_percpu_wq because system_wq is going away as part of a workqueue restructuring. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: Don't unchain link TRBs on quirky HCsMichal Pecio
Some old HCs ignore transfer ring link TRBs whose chain bit is unset. This breaks endpoint operation and sometimes makes it execute other ring's TDs, which may corrupt their buffers or cause unwanted device action. We avoid this by chaining all link TRBs on affected rings. Fix an omission which allows them to be unchained by cancelling TDs. The patch was tested by reproducing this condition on an isochronous endpoint (non-power-of-two TDs are sometimes split not to cross 64K) and printing link TRBs in trb_to_noop() on good and buggy HCs. Actual hardware malfunction is rare since it requires Missed Service Error shortly before the unchained link TRB, at least on NEC and AMD. I have never seen it after commit bb0ba4cb1065 ("usb: xhci: Apply the link chain quirk on NEC isoc endpoints"), but it's Russian roulette and I can't test all affected hosts and workloads. Fairly often MSEs happen after cancellation because the endpoint was stopped. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: Assume that endpoints halt as specifiedMichal Pecio
xHCI 4.8.3 recommends that software should simply assume endpoints to halt after certain events, without looking at the Endpoint Context for confirmation, because HCs may be slow to update that. While no cases of such "slowness" appear to be known, different problem exists on AMD Promontory chipsets: they may halt and generate a transfer event, but fail to ever update the Endpoint Context at all, at least not until some command is queued and fails with Context State Error. This is easily triggered by disconnecting D- of a full speed serial device. Possibly similar bug in non-AMD hardware has been reported to linux-usb. In such case, failed TD is given back without erasing from the ring and endpoint isn't reset. If some URB is unlinked later, Stop Endpoint fails and its handler resets the endpoint. On next submission it will restart on the stale TD. Outcome is UAF on success, or another halt on error and then Dequeue doesn't move and URBs are stuck. Unlinking and resubmitting the URBs causes unlimited ring expansion if the situation repeats. This can be solved by ignoring Endpoint Context State and trusting that endpoints halt when required, except one known case in ancient hardware. The check for "Already resolving halted ep" becomes redundant, because for these completion codes we now jump to xhci_handle_halted_endpoint() which deals with pending EP_HALTED internally. Link: https://lore.kernel.org/linux-usb/20250311234139.0e73e138@foxbook/ Link: https://lore.kernel.org/linux-usb/20250918055527.4157212-1-zhangjinpeng@kylinos.cn/ Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: implement USB Port Register Set structNiklas Neronin
Previously, each port's 'addr' field pointed to the base of the Host Controller USB Port Register Set, and specific registers were accessed using macros such as (port->addr + PORTPMSC). This patch replaces the raw '__le32 __iomem *addr' pointer with a typed 'struct xhci_port_regs __iomem *port_reg' pointer. With this change, individual registers can be accessed directly through the structure fields: Before: port->addr port->addr + PORTPMSC port->addr + PORTLI port->addr + PORTHLPMC After: port->port_reg->portsc port->port_reg->portpmsc port->port_reg->portli port->port_reg->porthlpmc This improves code readability and makes register access more intuitive by using named struct members instead of pointer arithmetic and macros. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add USB Port Register Set structNiklas Neronin
Introduce a new struct for the Host Controller USB Port Register Set to enhance readability and maintainability. The Host Controller Operational Registers (struct 'xhci_op_regs') span from offset 0x0 to 0x3FF and consist of fixed fields. Following these fixed fields are the Host Controller USB Port Register Sets, which are dynamic and repeat from 1 to MaxPorts, as defined by HCSPARAMS1. Currently, the struct 'xhci_op_regs' includes: __le32 port_status_base; The first PORTSC __le32 port_power_base; The first PORTPMSC __le32 port_link_base; The first PORTLI __le32 reserved5; The first PORTHLPMC, not reserved __le32 reserved6[NUM_PORT_REGS*254]; Port registers 2 to MaxPorts Replace this with the simpler: struct xhci_port_regs port_regs[]; Port registers 1 to MaxPorts Host Controller USB Port Register Set: | Offset | Mnemonic | Register Name -------------------------------------------------------------------------- | 0x0 | PORTSC | Port Status and Control | 0x4 | PORTPMSC | Port Power Management Status and Control | 0x8 | PORTLI | Port Link Info | 0xC | PORTHLPMC | Port Hardware LPM Control Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add helper to read PORTSC registerNiklas Neronin
Add a dedicated helper function to read the USB Port Status and Control (PORTSC) register. This complements xhci_portsc_writel() and improves code clarity by providing a clear counterpart for reading the register. Suggested-by: Peter Chen <peter.chen@kernel.org> Reviewed-by: Peter Chen <peter.chen@kerne.org> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: add tracing for PORTSC register writesNiklas Neronin
Introduce a dedicated write function for the USB Port Register Set (PORTSC) that includes tracing capabilities for values written to the PORTSC register. This enhancement minimizes code duplication and improves debugging. The PORTSC register is part of the Host Controller USB Port Register Set, comprising 4 x 32-bit registers. As the first register, PORTSC is accessed directly via 'port->addr'. Future commits will introduce a dedicated Port register struct to further streamline access. By adding the xhci_portsc_writel() function prior to these changes, we significantly reduce the number of same line modifications required. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: rework xhci_decode_portsc()Niklas Neronin
Rework xhci_decode_portsc(), which is used for PORTSC tracing, to make the output more compact and general. The function now first prints the multi-bit fields (port speed and link state), followed by the abbreviated names of each individual bit as defined in the xHCI specification. This reduces message length and makes the output easier to read. This change prepares for upcoming patches that will trace all PORTSC writes, requiring the same decoding logic to handle both reads and writes. This is particularly important for Read-Write-1-to-Clear (RW1C) bits, where the semantics differ between read and write operations. For example, when reading the Port Enabled bit, a set bit means the port is enabled; when writing, a set bit indicates the port is being disabled. The decoder now also includes the following fields: Port Link State Write Strobe (LWS) Device Removable (DR) Warm Port Reset (WPR) ==== Examples Traces ==== Before: 0x00201201 Powered Connected Disabled Link:U0 PortSpeed:4 Change: PRC Wake: 0x0a0002a0 Powered Not-connected Disabled Link:RxDetect PortSpeed:0 \ Change: Wake: WCE WOE After: 0x00201201 Speed=4 Link=U0 CCS PP PRC 0x0a0002a0 Speed=0 Link=RxDetect PP WCE WOE Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21xhci: simplify and rework trb_in_td()Mathias Nyman
The trb_in_td() checking is quite complex, especially when checking for TRBs in ranges that can span several segments. Simplify the search by creating a position index for each TRB on the ring, and just compare the position indexes. Add a more generic dma_in_range() helper that checks if a trb dma address is in the range between a start and end trb and call it from trb_in_td() Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21xhci: Add helper to find trb from its dma addressMathias Nyman
Add a xhci_dma_to_trb() helper, and use it to find the transfer TRB early in handle_tx_event() based on the dma address found in the event TRB. With this helper we can avoid using 'ep_seg' transfer TRB segment variable as both a a boolean to indicate if the transfer TRB is part of the next queued TD, and to actually find the transfer TRB based on ep_seg and ep_trb_dma. This is a first step in reworking and cleaning up trb_in_td() and handle_tx_event() Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci: limit run_graceperiod for only usb 3.0 devicesHongyu Xie
run_graceperiod blocks usb 2.0 devices from auto suspending after xhci_start for 500ms. Log shows: [ 13.387170] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.387177] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.387182] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.387188] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.387191] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.387193] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.387296] hub_event:5779: hub 3-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.393343] handle_port_status:2034: xhci-hcd PNP0D10:02: handle_port_status: starting usb5 port polling. [ 13.393353] xhci_hub_control:1271: xhci-hcd PNP0D10:02: Get port status 5-1 read: 0x206e1, return 0x10101 [ 13.400047] hub_suspend:3903: hub 3-0:1.0: hub_suspend [ 13.403077] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.403080] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.403085] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.403087] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.403090] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.403093] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.403095] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.405002] handle_port_status:1913: xhci-hcd PNP0D10:04: Port change event, 9-1, id 1, portsc: 0x6e1 [ 13.405016] hub_activate:1169: usb usb5-port1: status 0101 change 0001 [ 13.405026] xhci_clear_port_change_bit:658: xhci-hcd PNP0D10:02: clear port1 connect change, portsc: 0x6e1 [ 13.413275] hcd_bus_suspend:2250: usb usb3: bus auto-suspend, wakeup 1 [ 13.419081] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.419086] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.419095] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.419100] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.419106] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.419110] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.419112] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.420455] handle_port_status:2034: xhci-hcd PNP0D10:04: handle_port_status: starting usb9 port polling. [ 13.420493] handle_port_status:1913: xhci-hcd PNP0D10:05: Port change event, 10-1, id 1, portsc: 0x6e1 [ 13.425332] hcd_bus_suspend:2279: usb usb3: suspend raced with wakeup event [ 13.431931] handle_port_status:2034: xhci-hcd PNP0D10:05: handle_port_status: starting usb10 port polling. [ 13.435080] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.435084] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.435092] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.435096] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.435102] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.435106] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event usb7 and other usb 2.0 root hub were rapidly toggling between suspend and resume states. More, "suspend raced with wakeup event" confuses people. So, limit run_graceperiod for only usb 3.0 devices Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-21usb: xhci-mtk: correct most kernel-doc problems in xhci-mtk.hRandy Dunlap
Correct the kernel-doc notation in xhck-mtk.h to avoid most kernel-doc warnings. Summary of changes: - don't use /** to begin comments that are not in kernel-doc format - add missing "struct mu3h_sch_tt" kernel-doc line - convert several "struct mu3h_...:" to using " - " to separate the struct name from its short description - add a missing @speed: struct member description Warning messages that are fixed: xhci-mtk.h:25: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * To simplify scheduler algorithm, set a upper limit for ESIT, xhci-mtk.h:25: warning: missing initial short description on line: * To simplify scheduler algorithm, set a upper limit for ESIT, Warning: drivers/usb/host/xhci-mtk.h:36 Cannot find identifier on line: * @fs_bus_bw_out: save bandwidth used by FS/LS OUT eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:37 Cannot find identifier on line: * @fs_bus_bw_in: save bandwidth used by FS/LS IN eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:38 Cannot find identifier on line: * @ls_bus_bw: save bandwidth used by LS eps in each uframes Warning: drivers/usb/host/xhci-mtk.h:39 Cannot find identifier on line: * @fs_frame_bw: save bandwidth used by FS/LS eps in each FS frames Warning: drivers/usb/host/xhci-mtk.h:40 Cannot find identifier on line: * @in_ss_cnt: the count of Start-Split for IN eps Warning: drivers/usb/host/xhci-mtk.h:41 Cannot find identifier on line: * @ep_list: Endpoints using this TT Warning: drivers/usb/host/xhci-mtk.h:42 Cannot find identifier on line: */ Warning: drivers/usb/host/xhci-mtk.h:43 Cannot find identifier on line: struct mu3h_sch_tt { Warning: drivers/usb/host/xhci-mtk.h:44 Cannot find identifier on line: u16 fs_bus_bw_out[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:45 Cannot find identifier on line: u16 fs_bus_bw_in[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:46 Cannot find identifier on line: u8 ls_bus_bw[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:47 Cannot find identifier on line: u16 fs_frame_bw[XHCI_MTK_FRAMES_CNT]; Warning: drivers/usb/host/xhci-mtk.h:48 Cannot find identifier on line: u8 in_ss_cnt[XHCI_MTK_MAX_ESIT]; Warning: drivers/usb/host/xhci-mtk.h:49 Cannot find identifier on line: struct list_head ep_list; Warning: drivers/usb/host/xhci-mtk.h:50 Cannot find identifier on line: }; Warning: drivers/usb/host/xhci-mtk.h:51 Cannot find identifier on line: Warning: drivers/usb/host/xhci-mtk.h:52 Cannot find identifier on line: /** Warning: drivers/usb/host/xhci-mtk.h:121 struct member 'speed' not described in 'mu3h_sch_ep_info' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251104070216.907540-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-17Merge back earlier material related to system sleep for 6.19Rafael J. Wysocki
2025-11-14usb: sl811-hcd: Add PM_EVENT_POWEROFF into suspend callbacksMario Limonciello (AMD)
When the PM core uses hibernation callbacks for shutdown drivers will receive PM_EVENT_POWEROFF and should handle it the same as PM_EVENT_HIBERNATE would have been used. Tested-by: Eric Naim <dnaim@cachyos.org> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> [ rjw: Changelog adjustment ] Link: https://patch.msgid.link/20251112224025.2051702-4-superm1@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-09xhci: sideband: Fix race condition in sideband unregisterMathias Nyman
Uttkarsh Aggarwal observed a kernel panic during sideband un-register and found it was caused by a race condition between sideband unregister, and creating sideband interrupters. The issue occurrs when thread T1 runs uaudio_disconnect() and released sb->xhci via sideband_unregister, while thread T2 simultaneously accessed the now-NULL sb->xhci in xhci_sideband_create_interrupter() resulting in a crash. Ensure new endpoints or interrupter can't be added to a sidenband after xhci_sideband_unregister() cleared the existing ones, and unlocked the sideband mutex. Reorganize code so that mutex is only taken and released once in xhci_sideband_unregister(), and clear sb->vdev while mutex is taken. Use mutex guards to reduce human unlock errors in code Refuse to add endpoints or interrupter if sb->vdev is not set. sb->vdev is set when sideband is created and registered. Reported-by: Uttkarsh Aggarwal <uttkarsh.aggarwal@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-usb/20251028080043.27760-1-uttkarsh.aggarwal@oss.qualcomm.com Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-09xhci: dbgtty: Fix data corruption when transmitting data form DbC to hostMathias Nyman
Data read from a DbC device may be corrupted due to a race between ongoing write and write request completion handler both queuing new transfer blocks (TRBs) if there are remining data in the kfifo. TRBs may be in incorrct order compared to the data in the kfifo. Driver fails to keep lock between reading data from kfifo into a dbc request buffer, and queuing the request to the transfer ring. This allows completed request to re-queue itself in the middle of an ongoing transfer loop, forcing itself between a kfifo read and request TRB write of another request cpu0 cpu1 (re-queue completed req2) lock(port_lock) dbc_start_tx() kfifo_out(fifo, req1->buffer) unlock(port_lock) lock(port_lock) dbc_write_complete(req2) dbc_start_tx() kfifo_out(fifo, req2->buffer) unlock(port_lock) lock(port_lock) req2->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) lock(port_lock) req1->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) In the above scenario a kfifo containing "12345678" would read "1234" to req1 and "5678" to req2, but req2 is queued before req1 leading to data being transmitted as "56781234" Solve this by adding a flag that prevents starting a new tx if we are already mid dbc_start_tx() during the unlocked part. The already running dbc_do_start_tx() will make sure the newly completed request gets re-queued as it is added to the request write_pool while holding the lock. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-09xhci: fix stale flag preventig URBs after link state error is clearedMathias Nyman
A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-28xen/usb: Constify struct hc_driverChristophe JAILLET
'struct hc_driver' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 52065 23176 256 75497 126e9 drivers/usb/host/xen-hcd.o After: ===== text data bss dec hex filename 52897 22344 256 75497 126e9 drivers/usb/host/xen-hcd.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/63241c9e857646d895ce615b998d41ee4829f9e3.1761475831.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-27Merge 6.18-rc3 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22usb: uhci: Work around bogus clang shift overflow warning from DMA_BIT_MASK(64)Nathan Chancellor
After commit 18a9ec886d32 ("usb: uhci: Add Aspeed AST2700 support"), clang incorrectly warns: In file included from drivers/usb/host/uhci-hcd.c:855: drivers/usb/host/uhci-platform.c:69:32: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 69 | static const u64 dma_mask_64 = DMA_BIT_MASK(64); | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:93:54: note: expanded from macro 'DMA_BIT_MASK' 93 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~ clang has a long outstanding and complicated problem [1] with generating a proper control flow graph at global scope, resulting in it being unable to understand that this shift can never happen due to the 'n == 64' check. Restructure the code to only use DMA_BIT_MASK() within uhci_hcd_platform_probe() (i.e., function scope) to avoid this global scope issue, similar to the approach of commit 274f2232a94f ("usb: ehci: Add Aspeed AST2700 support"). Closes: https://github.com/ClangBuiltLinux/linux/issues/2136 Link: https://github.com/ClangBuiltLinux/linux/issues/92 [1] Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Ryan Chen <ryan_chen@aspeedtech.com> Link: https://patch.msgid.link/20251015-usb-uhci-avoid-bogus-clang-shift-warning-v2-1-68532d2f6114@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-14xhci: dbc: enable back DbC in resume if it was enabled before suspendMathias Nyman
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 <stable@kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-14xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall eventMathias Nyman
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 <stable@kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-14usb: xhci-pci: Fix USB2-only root hub registrationMichal Pecio
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 <arisa.snowbell@gmail.com> Closes: https://lore.kernel.org/linux-usb/CABpa4MA9unucCoKtSdzJyOLjHNVy+Cwgz5AnAxPkKw6vuox1Nw@mail.gmail.com/ Reported-by: Michal Kubecek <mkubecek@suse.cz> 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 <arisa.snowbell@gmail.com> Tested-by: Michal Kubecek <mkubecek@suse.cz> Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-13usb: ehci: Add Aspeed AST2700 supportRyan Chen
Unlike earlier Aspeed SoCs (AST2400/2500/2600) which are limited to 32-bit DMA addressing, the EHCI controller in AST2700 supports 64-bit DMA. Update the EHCI platform driver to make use of this capability by selecting a 64-bit DMA mask when the "aspeed,ast2700-ehci" compatible is present in device tree. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250928032407.27764-3-ryan_chen@aspeedtech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-13usb: uhci: Add Aspeed AST2700 supportRyan Chen
Unlike earlier Aspeed SoCs (AST2400/2500/2600) which are limited to 32-bit DMA addressing, the UHCI controller in AST2700 supports 64-bit DMA. Update the platform UHCI driver to select the appropriate DMA mask based on the device tree compatible string. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250922052045.2421480-5-ryan_chen@aspeedtech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-13usb: uhci: Add reset control supportRyan Chen
Some SoCs, such as the Aspeed AST2700, require the UHCI controller to be taken out of reset before it can operate. Add optional reset control support to the UHCI platform driver. The driver now acquires an optional reset line from device tree, deasserts it during probe, and asserts it again in the error path and shutdown. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250922052045.2421480-3-ryan_chen@aspeedtech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18usb: xhci: align PORTSC trace with one-based port numberingNiklas Neronin
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 <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-12-30 15:35:47 +0000