summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)Author
2025-09-17usb: host: xhci-plat: Add .post_resume_quirk for struct xhci_plat_privBiju Das
Some SoCs (eg Renesas RZ/G3E SoC) have special sequence after xhci_resume, add .post_resume_quick for it. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250916150255.4231-6-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17usb: host: xhci-rcar: Move R-Car reg definitionsBiju Das
Move xhci-rcar reg definitions to a header file for the preparation of adding support for RZ/G3E XHCI that has different register definitions. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250916150255.4231-5-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17usb: gadget: f_fs: Fix epfile null pointer access after ep enable.Owen Gu
A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues Signed-off-by: Owen Gu <guhuinan@xiaomi.com> Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBsForest Crossman
The usbmon binary interface currently truncates captures of large transfers from higher-speed USB devices. Because a single event capture is limited to one-fifth of the total buffer size, the current maximum size of a captured URB is around 240 KiB. This is insufficient when capturing traffic from modern devices that use transfers of several hundred kilobytes or more, as truncated URBs can make it impossible for user-space USB analysis tools like Wireshark to properly defragment and reassemble higher-level protocol packets in the captured data. The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has not been changed since the binary interface was introduced in 2006. To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The original comment for BUFF_MAX based the limit's calculation on a saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2 Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the buffer should be at least 50 MB. The new limit of 64 MiB covers that, plus a little extra for any overhead. With this change, both users and developers should now be able to debug and reverse engineer modern USB devices even when running unmodified distro kernels. Please note that this change does not affect the default buffer size. A larger buffer is only allocated when a user explicitly requests it via the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size should not unduly increase memory usage for users that don't deliberately request a larger buffer. Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com Signed-off-by: Forest Crossman <cyrozap@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/CAO3ALPxU5RzcoueC454L=WZ1qGMfAcnxm+T+p+9D8O9mcrUbCQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17usb: xhci: plat: Facilitate using autosuspend for xhci plat devicesKrishna Kurapati
Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs, when in host mode, it is intended that the controller goes to suspend state to save power and wait for interrupts from connected peripheral to wake it up. This is particularly used in cases where a HID or Audio device is connected. In such scenarios, the usb controller can enter auto suspend and resume action after getting interrupts from the connected device. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916120436.3617598-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17Merge patch series "Add SpacemiT K1 USB3.0 host controller support"Greg Kroah-Hartman
Ze Huang <huang.ze@linux.dev> says: The USB 3.0 controller found in the SpacemiT K1 SoC[1] supports both USB3.0 Host and USB2.0 Dual-Role Device (DRD). This controller is compatible with DesignWare Core USB 3 (DWC3) driver. However, constraints in the `snps,dwc3` bindings limit the ability to describe hardware-specific features in a clean and maintainable way. While `dwc3-of-simple` still serves as a glue layer for many platforms, it requires a split device tree node structure, which is less desirable in newer platforms. To promote a transition toward a flattened `dwc` node structure, this series introduces `dwc3-generic-plat`, building upon prior efforts that exposed the DWC3 core driver [2]. The device tree support for SpacemiT K1 will be submitted separately when the associated PHY driver is ready. Link: https://developer.spacemit.com/documentation?token=AjHDwrW78igAAEkiHracBI9HnTb [1] Link: https://lore.kernel.org/all/20250414-dwc3-refactor-v7-3-f015b358722d@oss.qualcomm.com [2] Link: https://lore.kernel.org/r/20250913-dwc3_generic-v8-0-b50f81f05f95@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-17usb: dwc3: add generic driver to support flattenedZe Huang
To support flattened dwc3 dt model and drop the glue layer, introduce the `dwc3-generic` driver. This enables direct binding of the DWC3 core driver and offers an alternative to the existing glue driver `dwc3-of-simple`. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Ze Huang <huang.ze@linux.dev> Link: https://lore.kernel.org/r/20250913-dwc3_generic-v8-2-b50f81f05f95@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250913-dwc3_generic-v8-2-b50f81f05f95@linux.dev
2025-09-15fs: rename generic_delete_inode() and generic_drop_inode()Mateusz Guzik
generic_delete_inode() is rather misleading for what the routine is doing. inode_just_drop() should be much clearer. The new naming is inconsistent with generic_drop_inode(), so rename that one as well with inode_ as the suffix. No functional changes. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-15Merge 6.17-rc6 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Handle mode transitions for CD321xHector Martin
On Apple Silicon machines there is no control over which alt mode is chosen. The CD321x' firmware negotiates the target mode on its own and only lets the main CPU know after the mode has already been chosen. Especially after plugging a new cable in this can result to quick mode changes from e.g. power only -> USB3 only -> USB3+DisplayPort in a short time. It is not possile to influence this in any way and we also do not get direct access to the PDOs or VDOs exchanged via USB PD. Additionally, mode changes must be tightly synchronized between DWC3 and the Type C PHY and most mode changes require a full reset of DWC3 to make the port work correctly. This is all done synchronously from the role switch handler inside the DWC3 glue driver on these machines to avoid tripping any failsafes or watchdogs inside the Type-C PHY that may, in the worst case, reset the entire SoC. To be able to control all this we trigger the entire process in the correct order directly from the TIPD driver and de-bounce any mode changes to avoid tearing down and re-setting DWC3 back up multiple times any time a new connection is made. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Co-developed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org> Reviewed-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-11-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Read data status in probe and cache its valueHector Martin
Just like for power status we also need to keep track of data status to be able to detect mode changes once we introduce de-bouncing for CD321x. Read it during probe and keep a cached copy of its value. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-10-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Use read_power_status function in probeHector Martin
We need the initial power status to be able to reliably detect connector changes once we introduce de-bouncing for CD321x next. read_power_status takes care of this and also forwards the status to the trace subsystem so let's use that instead of open-coding it inside probe. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-9-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Update partner identity when power status was updatedHector Martin
Whenever the power status is changed make sure to also update the partner identity to be able to detect changes once de-bouncing and mode changes are added for CD321x. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-8-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Register DisplayPort and Thunderbolt altmodes for cd321xSven Peter
Ports equipped with a CD321x are only found on Apple Silicon machines and always support DisplayPort, Thunderbolt and USB4. Register these port modes unconditionally. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-7-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321xSven Peter
CD321x supports various alternate modes and stores information once these are entered into separate status registers. Read those when they are active when reading TPS_DATA_STATUS to prepare supporting these. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-6-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Add cd321x struct with separate sizeSven Peter
We're about to add more fields to struct tps6598x which are only relevant for Apple's CD321x and to ensure that we don't waste memory everywhere for those add a separate struct for cd321x and prepare to allocate more space inside probe. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-5-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Trace data status for CD321x correctlySven Peter
Some bits inside the CD321x TPS_DATA_STATUS register have a different function compared to the original tipd chip. Add these and introduce a separate trace function to show them correctly. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-4-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Move switch_power_state to tipd_dataSven Peter
When support for CD321x was originally added no other hardware variant was supported and there was no need for struct tipd_data. Now that it exists move the special case in there so that we can drop the of_device_is_compatible_check entirely. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-3-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Move initial irq mask to tipd_dataSven Peter
Since the irq mask was originally added more tipd variants have been introduced and there's now struct tipd_data. Move the initial mask in there. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-2-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Clear interrupts firstSven Peter
Right now the interrupt handler first reads all updated status registers and only then clears the interrupts. It's possible that a duplicate interrupt for a changed register or plug state comes in after the interrupts have been processed but before they have been cleared: * plug is inserted, TPS_REG_INT_PLUG_EVENT is set * TPS_REG_INT_EVENT1 is read * tps6598x_handle_plug_event() has run and registered the plug * plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again) * TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared We then have no plug connected and no pending interrupt but the tipd core still thinks there is a plug. It's possible to trigger this with e.g. a slightly broken Type-C to USB A converter. Fix this by first clearing the interrupts and only then reading the updated registers. Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X") Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable@kernel.org Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-1-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12Merge patch series "Support system sleep with offloaded usb transfers" into ↵Greg Kroah-Hartman
usb-next Guan-Yu Lin <guanyulin@google.com> says: Wesley Cheng and Mathias Nyman's USB offload design enables a co-processor to handle some USB transfers, potentially allowing the system to sleep (suspend-to-RAM) and save power. However, Linux's System Sleep model halts the USB host controller when the main system isn't managing any USB transfers. To address this, the proposal modifies the system to recognize offloaded USB transfers and manage power accordingly. This way, offloaded USB transfers could still happen during system sleep (Suspend-to-RAM). This involves two key steps: 1. Transfer Status Tracking: Propose offload_usage and corresponding apis drivers could track USB transfers on the co-processor, ensuring the system is aware of any ongoing activity. 2. Power Management Adjustment: Modifications to the USB driver stack (xhci host controller driver, and USB device drivers) allow the system to sleep (Suspend-to-RAM) without disrupting co-processor managed USB transfers. This involves adding conditional checks to bypass some power management operations in the System Sleep model. Link: https://lore.kernel.org/r/20250911142051.90822-1-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: host: enable USB offload during system sleepGuan-Yu Lin
Sharing a USB controller with another entity via xhci-sideband driver creates power management complexities. To prevent the USB controller from being inadvertently deactivated while in use by the other entity, a usage-count based mechanism is implemented. This allows the system to manage power effectively, ensuring the controller remains available whenever needed. In order to maintain full functionality of an offloaded USB devices, several changes are made within the suspend flow of such devices: - skip usb_suspend_device() so that the port/hub are still active for USB transfers via offloaded path. - not suspending the endpoints which are used by USB interfaces marked with needs_remote_wakeup. Namely, skip usb_suspend_interface() and usb_hcd_flush_endpoint() on associated USB interfaces. This reserves a pending interrupt urb during system suspend for handling the interrupt transfer, which is necessary since remote wakeup doesn't apply in the offloaded USB devices when controller is still active. - not flushing the endpoints of actively offloaded USB devices. Given that the USB devices is used by another entity, unilaterally flush the endpoint might lead to unexpected behavior on another entity. - not suspending the xhci controller. This is done by skipping the suspend/resume callbacks in the xhci platform driver. Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Link: https://lore.kernel.org/r/20250911142051.90822-5-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250911142051.90822-5-guanyulin@google.com
2025-09-12xhci: sideband: add api to trace sideband usageGuan-Yu Lin
The existing sideband driver only registers sidebands without tracking their active usage. To address this, sideband will now record its active usage when it creates/removes interrupters. In addition, a new api is introduced to provide a means for other dirvers to fetch sideband activity information on a USB host controller. Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Link: https://lore.kernel.org/r/20250911142051.90822-4-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250911142051.90822-4-guanyulin@google.com
2025-09-12usb: offload: add apis for offload usage trackingGuan-Yu Lin
Introduce offload_usage and corresponding apis to track offload usage on each USB device. Offload denotes that there is another co-processor accessing the USB device via the same USB host controller. To optimize power usage, it's essential to monitor whether the USB device is actively used by other co-processor. This information is vital when determining if a USB device can be safely suspended during system power state transitions. Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Link: https://lore.kernel.org/r/20250911142051.90822-3-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250911142051.90822-3-guanyulin@google.com
2025-09-12usb: xhci-plat: separate dev_pm_ops for each pm_eventGuan-Yu Lin
Separate dev_pm_ops for different power events such as suspend, thaw, and hibernation. This is crucial when xhci-plat driver needs to adapt its behavior based on different power state changes. Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Link: https://lore.kernel.org/r/20250911142051.90822-2-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250911142051.90822-2-guanyulin@google.com
2025-09-12usb: misc: Add Intel USBIO bridge driverIsrael Cepeda
Add a driver for the Intel USBIO USB IO-expander used by the MIPI cameras on various new (Meteor Lake and later) Intel laptops. This is an USB bridge driver which adds auxbus child devices for the GPIO, I2C and SPI functions of the USBIO chip and which exports IO-functions for the drivers for the auxbus child devices to communicate with the USBIO device's firmware. Co-developed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Israel Cepeda <israel.a.cepeda.lopez@intel.com> Link: https://lore.kernel.org/r/20250911181343.77398-2-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: dwc3: qcom: Implement glue callbacks to facilitate runtime suspendKrishna Kurapati
On Qualcomm DWC3 dual-role controllers, the conndone/disconnect events in device mode are generated by controller when software writes to QSCRATCH registers in Qualcomm Glue layer rather than the vbus line being routed to dwc3 core IP for it to recognize and generate these events. UTMI_OTG_VBUS_VALID bit of QSCRATCH_HS_PHY_CTRL register needs to be set to generate a connection done event and to be cleared for the controller to generate a disconnect event during cable removal. When the disconnect is not generated upon cable removal, the "connected" flag of dwc3 is left marked as "true" and it blocks suspend routines and for that to happen upon cable removal, the cable disconnect notification coming in via set_role call need to be provided to the Qualcomm glue layer as well. Currently, the way DWC3 core and Qualcomm legacy glue driver are designed, there is no mechanism through which the DWC3 core can notify the Qualcomm glue layer of any role changes which it receives via role switch. To register these glue callbacks at probe time, for enabling core to notify glue layer, the legacy Qualcomm driver has no way to find out when the child driver probe was successful since it does not check for the same during of_platform_populate. Hence implement the following glue callbacks for flattened Qualcomm glue driver: 1. set_role: To pass role switching information from drd layer to glue. This information is needed to identify NONE/DEVICE mode switch and modify QSCRATCH to generate connect-done event on device mode entry and disconnect event on cable removal in device mode. 2. run_stop: When booting up in device mode, if autouspend is enabled and userspace doesn't write UDC on boot, controller enters autosuspend. After this, if the userspace writes to UDC in the future, run_stop notifier is required to enable UTMI_OTG_VBUS_VALID of QSCRATCH so that connect done event is generated after run_stop(1) is done to finish enumeration. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250907181412.2174616-3-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: dwc3: core: Introduce glue callbacks for flattened implementationsKrishna Kurapati
In certain situations like role switching, the glue layers need to be informed of these events, so that they can take any necessary action. But in non-flattened implementations, the glue drivers have no data on when the core driver probe was successful post invoking of_platform_ populate. Now that the core driver supports flattened implementations as well, introduce vendor callbacks that can be passed on from glue to core before invoking dwc3_core_probe. Introduce callbacks to notify glue layer of role_switch and run_stop changes. These can be used by flattened implementation of Qualcomm glue layer to generate connect/disconnect events in controller during cable connect and run stop modifications by udc in device mode. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250907181412.2174616-2-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: xhci: tegra: Support USB wakeup function for Tegra234Haotien Hsu
When the system is suspended, USB hot-plugging/unplugging can trigger wake events of the Tegra USB host controller. Enable support for USB wake-up events by parsing device-tree to see if the interrupts for the wake-up events are present and if so configure those interrupts. Note that if wake-up events are not present, still allow the USB host controller to probe as normal. Signed-off-by: Haotien Hsu <haotienh@nvidia.com> Link: https://lore.kernel.org/r/20250811074558.1062048-5-haotienh@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: udc: Add trace event for usb_gadget_set_stateKuen-Han Tsai
While the userspace program can be notified of gadget state changes, timing issue can lead to missed transitions when reading the state value. Introduce a trace event for usb_gadget_set_state to reliably track state transitions. Signed-off-by: Kuen-Han Tsai <khtsai@google.com> Link: https://lore.kernel.org/r/20250818082722.2952867-1-khtsai@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: dwc2: Add support for 'maximum-speed' propertyHerve Codina
The DWC2 IP can be properly integrated in a SoC to work at high-speed USB speed but some board issues, EMC constraints or any other reasons can lead to the need to limit this USB speed at board level. The device-tree 'maximum-speed' property already exists for this purpose but is not handled by the DWC2 driver. Fill this lack adding support for 'maximum-speed' property and so allow to limit the USB speed in device-tree (board description). Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20250910160730.585303-1-herve.codina@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12usb: typec: tcpci: add wakeup supportXu Yang
Add wakeup support for tcpci. If the user enables the wakeup file, call enable_irq_wake() during system suspend and disable_irq_wake() during system resume. Since this driver supports shared interrupts, mask the chip interrupt by default when wakeup is disabled to avoid affecting other IRQ users. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250910105042.695146-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12USB: core: remove the move buf actionEdward Adam Davis
The buffer size of sysfs is fixed at PAGE_SIZE, and the page offset of the buf parameter of sysfs_emit_at() must be 0, there is no need to manually manage the buf pointer offset. Fixes: 711d41ab4a0e ("usb: core: Use sysfs_emit_at() when showing dynamic IDs") Reported-by: syzbot+b6445765657b5855e869@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6445765657b5855e869 Tested-by: syzbot+b6445765657b5855e869@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://lore.kernel.org/r/tencent_B32D6D8C9450EBFEEE5ACC2C7B0E6C402D0A@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-12Merge tag 'usb-serial-6.17-rc6' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial device ids for 6.17-rc6 Here are some new modem device ids. Everything has been in linux-next with no reported issues. * tag 'usb-serial-6.17-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions USB: serial: option: add Telit Cinterion FN990A w/audio compositions
2025-09-06usb: gadget: tegra-xudc: Remove redundant ternary operatorsLiao Yuanhong
For ternary operators in the form of "a ? true : false", if 'a' itself returns a boolean result, the ternary operator can be omitted. Remove redundant ternary operators to clean up the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250902132613.84876-1-liaoyuanhong@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06usb: gadget: midi2: Fix MIDI2 IN EP max packet sizeTakashi Iwai
The EP-IN of MIDI2 (altset 1) wasn't initialized in f_midi2_create_usb_configs() as it's an INT EP unlike others BULK EPs. But this leaves rather the max packet size unchanged no matter which speed is used, resulting in the very slow access. And the wMaxPacketSize values set there look legit for INT EPs, so let's initialize the MIDI2 EP-IN there for achieving the equivalent speed as well. Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20250905133240.20966-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06usb: gadget: midi2: Fix missing UMP group attributes initializationTakashi Iwai
The gadget card driver forgot to call snd_ump_update_group_attrs() after adding FBs, and this leaves the UMP group attributes uninitialized. As a result, -ENODEV error is returned at opening a legacy rawmidi device as an inactive group. This patch adds the missing call to address the behavior above. Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20250904153932.13589-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06usb: typec: tcpm: properly deliver cable vdms to altmode driversRD Babiera
tcpm_handle_vdm_request delivers messages to the partner altmode or the cable altmode depending on the SVDM response type, which is incorrect. The partner or cable should be chosen based on the received message type instead. Also add this filter to ADEV_NOTIFY_USB_AND_QUEUE_VDM, which is used when the Enter Mode command is responded to by a NAK on SOP or SOP' and when the Exit Mode command is responded to by an ACK on SOP. Fixes: 7e7877c55eb1 ("usb: typec: tcpm: add alt mode enter/exit/vdm support for sop'") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250821203759.1720841-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernelsAlan Stern
Yunseong Kim and the syzbot fuzzer both reported a problem in RT-enabled kernels caused by the way dummy-hcd mixes interrupt management and spin-locking. The pattern was: local_irq_save(flags); spin_lock(&dum->lock); ... spin_unlock(&dum->lock); ... // calls usb_gadget_giveback_request() local_irq_restore(flags); The code was written this way because usb_gadget_giveback_request() needs to be called with interrupts disabled and the private lock not held. While this pattern works fine in non-RT kernels, it's not good when RT is enabled. RT kernels handle spinlocks much like mutexes; in particular, spin_lock() may sleep. But sleeping is not allowed while local interrupts are disabled. To fix the problem, rewrite the code to conform to the pattern used elsewhere in dummy-hcd and other UDC drivers: spin_lock_irqsave(&dum->lock, flags); ... spin_unlock(&dum->lock); usb_gadget_giveback_request(...); spin_lock(&dum->lock); ... spin_unlock_irqrestore(&dum->lock, flags); This approach satisfies the RT requirements. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Fixes: b4dbda1a22d2 ("USB: dummy-hcd: disable interrupts during req->complete") Reported-by: Yunseong Kim <ysk@kzalloc.com> Closes: <https://lore.kernel.org/linux-usb/5b337389-73b9-4ee4-a83e-7e82bf5af87a@kzalloc.com/> Reported-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com Closes: <https://lore.kernel.org/linux-usb/68ac2411.050a0220.37038e.0087.GAE@google.com/> Tested-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de> CC: stable@vger.kernel.org Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/bb192ae2-4eee-48ee-981f-3efdbbd0d8f0@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06xhci: fix memory leak regression when freeing xhci vdev devices depth firstMathias Nyman
Suspend-resume cycle test revealed a memory leak in 6.17-rc3 Turns out the slot_id race fix changes accidentally ends up calling xhci_free_virt_device() with an incorrect vdev parameter. The vdev variable was reused for temporary purposes right before calling xhci_free_virt_device(). Fix this by passing the correct vdev parameter. The slot_id race fix that caused this regression was targeted for stable, so this needs to be applied there as well. Fixes: 2eb03376151b ("usb: xhci: Fix slot_id resource race conflict") Reported-by: David Wang <00107082@163.com> Closes: https://lore.kernel.org/linux-usb/20250829181354.4450-1-00107082@163.com Suggested-by: Michal Pecio <michal.pecio@gmail.com> Suggested-by: David Wang <00107082@163.com> Cc: stable@vger.kernel.org Tested-by: David Wang <00107082@163.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250902105306.877476-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06xhci: dbc: Fix full DbC transfer ring after several reconnectsMathias Nyman
Pending requests will be flushed on disconnect, and the corresponding TRBs will be turned into No-op TRBs, which are ignored by the xHC controller once it starts processing the ring. If the USB debug cable repeatedly disconnects before ring is started then the ring will eventually be filled with No-op TRBs. No new transfers can be queued when the ring is full, and driver will print the following error message: "xhci_hcd 0000:00:14.0: failed to queue trbs" This is a normal case for 'in' transfers where TRBs are always enqueued in advance, ready to take on incoming data. If no data arrives, and device is disconnected, then ring dequeue will remain at beginning of the ring while enqueue points to first free TRB after last cancelled No-op TRB. s Solve this by reinitializing the rings when the debug cable disconnects and DbC is leaving the configured state. Clear the whole ring buffer and set enqueue and dequeue to the beginning of ring, and set cycle bit to its initial state. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250902105306.877476-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06xhci: dbc: decouple endpoint allocation from initializationMathias Nyman
Decouple allocation of endpoint ring buffer from initialization of the buffer, and initialization of endpoint context parts from from the rest of the contexts. It allows driver to clear up and reinitialize endpoint rings after disconnect without reallocating everything. This is a prerequisite for the next patch that prevents the transfer ring from filling up with cancelled (no-op) TRBs if a debug cable is reconnected several times without transferring anything. Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250902105306.877476-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06Merge patch series "eUSB2 Double Isochronous IN Bandwidth support"Greg Kroah-Hartman
Sakari Ailus <sakari.ailus@linux.intel.com> says: This series enables support for eUSB2 Double Isochronous IN Bandwidth UVC devices specified in 'USB 2.0 Double Isochronous IN Bandwidth' ECN. In short, it adds support for new integrated USB2 webcams that can send twice the data compared to conventional USB2 webcams. These devices are identified by the device descriptor bcdUSB 0x0220 value. They have an additional eUSB2 Isochronous Endpoint Companion Descriptor, and a zero max packet size in regular isoc endpoint descriptor. Support for parsing that new descriptor was added in commit c749f058b437 ("USB: core: Add eUSB2 descriptor and parsing in USB core") This series adds support to UVC, USB core, and xHCI to identify eUSB2 double isoc devices, and allow and set proper max packet, iso frame desc sizes, bytes per interval, and other values in URBs and xHCI endpoint contexts needed to support the double data rates for eUSB2 double isoc devices. since v4: https://lore.kernel.org/linux-usb/20250812132445.3185026-1-sakari.ailus@linux.intel.com - New patch: use le16_to_cpu() to access endpoint descriptor's wMaxPacketSize field, which is an __le16. This isn't a bugfix as the value was compared to 0. - New patch: add USB device speed check for eUSB2 isochronous endpoint companion parsing. The check is then removed from sites checking the existence of the companion (through companion's bDescriptorType field, which is non-zero for valid descriptors). - New patch: do not parse eUSB2 isoc double BW companion descriptor on interrupt or OUT endpoints. It is not supposed to be found there, according to the ECN. - Rename usb_endpoint_max_isoc_bpi() as usb_endpoint_max_periodic_payload() and move it right after usb_maxpacket(). - Fixed @ep reference in kernel-doc documentation for usb_endpoint_max_periodic_payload(). - In usb_endpoint_max_periodic_payload(), call struct usb_device pointer argument "udev" instead of "dev", to align with naming elsewhere. - Add support for interrupt endpoints in usb_endpoint_max_periodic_payload(); eUSB2 double isoc BW is still limited to isochronous endpoints though. - In usb_endpoint_max_periodic_payload(), remove the separate case for USB_SPEED_HIGH as the check is already done in parsing the eUSB isoc double BW companion, which is checked for. - New patch: use usb_endpoint_max_periodic_payload() in xHCI driver, replacing xhci_get_max_esit_payload(). - Check non-zero bDescriptorType field of ep->eusb2_isoc_ep_comp instead of dwBytesPerInterval value exceeding 3072, where xhci_eusb2_is_isoc_bw_double() was used. This aligns the checks of eUSB2 isochronous double bandwidth support for an endpoint. - New patch: introduce usb_endpoint_is_hs_isoc_double() to figure out whether an endpoint uses isochronous double bandwidth and use the function in the xHCI driver and the usb core. xhci_eusb2_is_isoc_bw_double() is dropped, as well as the MAX_ISOC_XFER_SIZE_HS macro. usb_endpoint_is_hs_isoc_double() also includes check for bcdUSB == 0x220, to anticipate adding support for eUSB2V2. - Merge condition for checking eUSB2 isoc double bw support for xHCI/endpoint in xhci_get_endpoint_mult(). - Improve comment regarding maximum packet size bits 12:11 in xhci_get_endpoint_max_burst(). - Aligned subject prefixes with the recent patches to the same files. since v3: https://lore.kernel.org/linux-usb/20250807055355.1257029-1-sakari.ailus@linux.intel.com/ - Use spaces in aligning macro body for HCC2_EUSB2_DIC() (1st patch). - Move usb_endpoint_max_isoc_bpi() to drivers/usb/core/usb.c (3rd patch). since v2: https://lore.kernel.org/linux-usb/20250711083413.1552423-1-sakari.ailus@linux.intel.com - Use ep->eusb2_isoc_ep_comp.bDescriptorType to determined whether the eUSB2 isochronous endpoint companion descriptor exists. - Clean up eUSB2 double isoc bw maxp calculation. - Drop le16_to_cpu(udev->descriptor.bcdUSB) == 0x220 check from xhci_eusb2_is_isoc_bw_double() -- it's redundant as ep->eusb2_isoc_ep_comp.dwBytesPerInterval will be zero otherwise. - Add kernel-doc documentation for usb_endpoint_max_isoc_bpi(). - Check the endpoint has IN direction in usb_endpoint_max_isoc_bpi() and usb_submit_urb() as a condition for eUSB2 isoc double bw. since v1: https://lore.kernel.org/linux-usb/20250616093730.2569328-2-mathias.nyman@linux.intel.com - Introduce uvc_endpoint_max_isoc_bpi() to obtain maximum bytes per interval value for an endpoint, in a new patch (3rd). This code has been slightly reworked from the instance in the UVC driver, including support for SuperSpeedPlus Isochronous Endpoint Companion. - Use usb_endpoint_max_isoc_bpi() in the UVC driver instead of open-coding eUSB2 support there, also drop now-redundant uvc_endpoint_max_bpi(). - Use u32 for maximum bpi and related information in the UVC driver -- the value could be larger than a 16-bit type can hold. - Assume max in usb_submit_urb() is a natural number as usb_endpoint_maxp() returns only natural numbers (2nd patch). Link: https://lore.kernel.org/r/20250820143824.551777-1-sakari.ailus@linux.intel.com Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06usb: core: support eUSB2 double bandwidth large isoc URB framesRai, Amardeep
eUSB2 double isochronous in bandwidth devices support up to 6 transactions per microframe, and thus doubles the total bytes possible to receive per microframe. Support larger URB isoc frame sizes for eUSB2 double isoc in endpoints. Also usb_endpoint_maxp() returns a natural number so there's no need to assume it could be < 0. Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-9-sakari.ailus@linux.intel.com
2025-09-06usb: xhci: Add host support for eUSB2 double isochronous bandwidth devicesRai, Amardeep
Detect eUSB2 double isoc bw capable hosts and devices, and set the proper xhci endpoint context values such as 'Mult', 'Max Burst Size', and 'Max ESIT Payload' to enable the double isochronous bandwidth endpoints. Intel xHC uses the endpoint context 'Mult' field for eUSB2 isoc endpoints even if hosts supporting Large ESIT Payload Capability should normally ignore the mult field. Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com> Co-developed-by: Kannappan R <r.kannappan@intel.com> Signed-off-by: Kannappan R <r.kannappan@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-8-sakari.ailus@linux.intel.com
2025-09-06usb: core: Introduce usb_endpoint_is_hs_isoc_double()Sakari Ailus
Introduce usb_endpoint_is_hs_isoc_double() tell whether an endpoint conforms to USB 2.0 Isochronous Double IN Bandwidth ECN. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-7-sakari.ailus@linux.intel.com
2025-09-06usb: xhci: Use usb_endpoint_max_periodic_payload()Sakari Ailus
Use the newly added usb_endpoint_max_periodic_payload() to obtain the maximum number of bytes to transfer during a service interval for isochronous and interrupt endpoints. This will replace the xhci-specific xhci_get_max_esit_payload() which is removed as redundant. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-6-sakari.ailus@linux.intel.com
2025-09-06usb: core: Add a function to get USB version independent periodic payloadRai, Amardeep
Add usb_endpoint_max_periodic_payload() to obtain maximum payload bytes in a service interval for isochronous and interrupt endpoints in a USB version independent way. Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-5-sakari.ailus@linux.intel.com
2025-09-06usb: core: eUSB2 companion descriptor is for isoc IN endpoints onlySakari Ailus
The eUSB2 isochronous double bandwidth endpoint descriptor is allowed for the isochronous IN endpoints, according to the ECN. Do not parse these descriptors if they are found in interrupt or OUT endpoints. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-4-sakari.ailus@linux.intel.com
2025-09-06usb: core: Parse eUSB2 companion descriptors for high speed devices onlySakari Ailus
Check that a device is a high-speed one before proceeding to parse the eUSB2 isochronous endpoint companion descriptors. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250820143824.551777-3-sakari.ailus@linux.intel.com