summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)Author
2025-03-04usb: dwc3: Set SUSPENDENABLE soon after phy initThinh Nguyen
After phy initialization, some phy operations can only be executed while in lower P states. Ensure GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY are set soon after initialization to avoid blocking phy ops. Previously the SUSPENDENABLE bits are only set after the controller initialization, which may not happen right away if there's no gadget driver or xhci driver bound. Revise this to clear SUSPENDENABLE bits only when there's mode switching (change in GCTL.PRTCAPDIR). Fixes: 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init") Cc: stable <stable@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/633aef0afee7d56d2316f7cc3e1b2a6d518a8cc9.1738280911.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: dwc3: exynos: add support for exynos7870Kaustabh Chakraborty
Exynos7870 devices have a DWC3 compatible USB 2.0 controller. Add support in the driver by: - Adding its own compatible string, "samsung,exynos7870-dwusb3". - Adding three USBDRD clocks named "bus_early", "ref", and "ctrl", to be controlled by the driver. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250301-exynos7870-usb-v3-2-f01697165d19@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: shuttle_usbat: Use const for constant arrayJonathan Neuschäfer
This array is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-9-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: sddr55: Use const for constant arraysJonathan Neuschäfer
These arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-8-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: sddr09: Use const for constant arraysJonathan Neuschäfer
The nand_flash_ids, inquiry_response, and mode_page_01 arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-7-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: realtek_cr: Use const for constant arraysJonathan Neuschäfer
These arrays are only read, never modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-6-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: initializers: Use const for constant arrayJonathan Neuschäfer
init_string is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-5-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: datafab: Use const for constant arraysJonathan Neuschäfer
These arrays are only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-4-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: alauda: Use const for card ID arrayJonathan Neuschäfer
The alauda_card_ids array is only read, and not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-3-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: transport: Use const for constant arrayJonathan Neuschäfer
This array is only read, not modified. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-2-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: storage: jumpshot: Use const for constant arraysJonathan Neuschäfer
These arrays are not modified. Make them const. Declaring data as const makes it easier to see what's going on, and can prevent unintended writes through placement in a read-only section. Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250228-misc-const-v3-1-09b417ded9c4@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03ucsi_ccg: Don't show non-functional attributesMario Limonciello
If no fw_build is recognized for the controller there is no point to exposing the `do_flash` attribute. Add an is_visible callback to the attribute group and check for that fw_build member to hide when not applicable. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250221054137.1631765-3-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03ucsi_ccg: Don't show failed to get FW build information errorMario Limonciello
The error `failed to get FW build information` is added for what looks to be for misdetection of the device property firmware-name. If the property is missing (such as on non-nvidia HW) this error shows up. Move the error into the scope of the property parser for "firmware-name" to avoid showing errors on systems without the firmware-name property. Fixes: 5c9ae5a87573d ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250221054137.1631765-2-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: chipidea: imx: fix some typoXu Yang
bootlader -> bootloader set_wakeup failed -> hsic_set_clk failed Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20250225062843.3930041-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: ulpi: Remove unused otg_ulpi_createDr. David Alan Gilbert
otg_ulpi_create() has been unused since 2022's commit 8ca79aaad8be ("ARM: pxa: remove unused pxa3xx-ulpi") Remove it. The devm_ variant is still used. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250223160602.91916-1-linux@treblig.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: core: replace usb_sndaddr0pipe macro with usb_sndctrlpipeStefan Eichenberger
The usb_sndaddr0pipe macro is only used in the hub_set_address function. Replace it with usb_sndctrlpipe which provides the same functionality but would also consider the endpoint device number. If the device has not been initialised, it is safe to use usb_sndctrlpipe in this context because udev->devnum is set to 0. Therefore, this change does not affect behaviour, but reduces code complexity by reusing the existing macro. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250219083745.10406-1-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: hub: lack of clearing xHC resourcesPawel Laszczak
The xHC resources allocated for USB devices are not released in correct order after resuming in case when while suspend device was reconnected. This issue has been detected during the fallowing scenario: - connect hub HS to root port - connect LS/FS device to hub port - wait for enumeration to finish - force host to suspend - reconnect hub attached to root port - wake host For this scenario during enumeration of USB LS/FS device the Cadence xHC reports completion error code for xHC commands because the xHC resources used for devices has not been properly released. XHCI specification doesn't mention that device can be reset in any order so, we should not treat this issue as Cadence xHC controller bug. Similar as during disconnecting in this case the device resources should be cleared starting form the last usb device in tree toward the root hub. To fix this issue usbcore driver should call hcd->driver->reset_device for all USB devices connected to hub which was reconnected while suspending. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable@kernel.org> Signed-off-by: Pawel Laszczak <pawell@cadence.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/PH7PR07MB953841E38C088678ACDCF6EEDDCC2@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: renesas_usbhs: Flush the notify_hotplug_workClaudiu Beznea
When performing continuous unbind/bind operations on the USB drivers available on the Renesas RZ/G2L SoC, a kernel crash with the message "Unable to handle kernel NULL pointer dereference at virtual address" may occur. This issue points to the usbhsc_notify_hotplug() function. Flush the delayed work to avoid its execution when driver resources are unavailable. Fixes: bc57381e6347 ("usb: renesas_usbhs: use delayed_work instead of work_struct") Cc: stable <stable@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250225110248.870417-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: renesas_usbhs: Use devm_usb_get_phy()Claudiu Beznea
The gpriv->transceiver is retrieved in probe() through usb_get_phy() but never released. Use devm_usb_get_phy() to handle this scenario. This issue was identified through code investigation. No issue was found without this change. Fixes: b5a2875605ca ("usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS") Cc: stable <stable@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250225110248.870417-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: renesas_usbhs: Call clk_put()Claudiu Beznea
Clocks acquired with of_clk_get() need to be freed with clk_put(). Call clk_put() on priv->clks[0] on error path. Fixes: 3df0e240caba ("usb: renesas_usbhs: Add multiple clocks management") Cc: stable <stable@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250225110248.870417-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: dwc3: gadget: Prevent irq storm when TH re-executesBadhri Jagan Sridharan
While commit d325a1de49d6 ("usb: dwc3: gadget: Prevent losing events in event cache") makes sure that top half(TH) does not end up overwriting the cached events before processing them when the TH gets invoked more than one time, returning IRQ_HANDLED results in occasional irq storm where the TH hogs the CPU. The irq storm can be prevented by the flag before event handler busy is cleared. Default enable interrupt moderation in all versions which support them. ftrace event stub during dwc3 irq storm: irq/504_dwc3-1111 ( 1111) [000] .... 70.000866: irq_handler_exit: irq=14 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000872: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000874: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000881: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000883: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000889: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000892: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000898: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000901: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000907: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000909: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000915: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000918: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000924: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000927: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000933: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000935: irq_handler_exit: irq=504 ret=handled .... Cc: stable <stable@kernel.org> Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Fixes: d325a1de49d6 ("usb: dwc3: gadget: Prevent losing events in event cache") Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250216223003.3568039-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: gadget: Check bmAttributes only if configuration is validPrashanth K
If the USB configuration is not valid, then avoid checking for bmAttributes to prevent null pointer deference. Cc: stable <stable@kernel.org> Fixes: 40e89ff5750f ("usb: gadget: Set self-powered based on MaxPower and bmAttributes") Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250224085604.417327-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hostsMarc Zyngier
When adding support for USB3-over-USB4 tunnelling detection, a check for an Intel-specific capability was added. This capability, which goes by ID 206, is used without any check that we are actually dealing with an Intel host. As it turns out, the Cadence XHCI controller *also* exposes an extended capability numbered 206 (for unknown purposes), but of course doesn't have the Intel-specific registers that the tunnelling code is trying to access. Fun follows. The core of the problems is that the tunnelling code blindly uses vendor-specific capabilities without any check (the Intel-provided documentation I have at hand indicates that 192-255 are indeed vendor-specific). Restrict the detection code to Intel HW for real, preventing any further explosion on my (non-Intel) HW. Cc: stable <stable@kernel.org> Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts") Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250227194529.2288718-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-27usb: xhci: Enable the TRB overfetch quirk on VIA VL805Michal Pecio
Raspberry Pi is a major user of those chips and they discovered a bug - when the end of a transfer ring segment is reached, up to four TRBs can be prefetched from the next page even if the segment ends with link TRB and on page boundary (the chip claims to support standard 4KB pages). It also appears that if the prefetched TRBs belong to a different ring whose doorbell is later rung, they may be used without refreshing from system RAM and the endpoint will stay idle if their cycle bit is stale. Other users complain about IOMMU faults on x86 systems, unsurprisingly. Deal with it by using existing quirk which allocates a dummy page after each transfer ring segment. This was seen to resolve both problems. RPi came up with a more efficient solution, shortening each segment by four TRBs, but it complicated the driver and they ditched it for this quirk. Also rename the quirk and add VL805 device ID macro. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Link: https://github.com/raspberrypi/linux/issues/4685 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215906 CC: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250225095927.2512358-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-21USB: core: Add eUSB2 descriptor and parsing in USB coreKannappan R
Add support for the 'eUSB2 Isochronous Endpoint Companion Descriptor' introduced in the recent USB 2.0 specification 'USB 2.0 Double Isochronous IN Bandwidth' ECN. It allows embedded USB2 (eUSB2) devices to report and use higher bandwidths for isochronous IN transfers in order to support higher camera resolutions on the lid of laptops and tablets with minimal change to the USB2 protocol. The motivation for expanding USB 2.0 is further clarified in an additional Embedded USB2 version 2.0 (eUSB2v2) supplement to the USB 2.0 specification. It points out this is optimized for performance, power and cost by using the USB 2.0 low-voltage, power efficient PHY and half-duplex link for the asymmetric camera bandwidth needs, avoiding the costly and complex full-duplex USB 3.x symmetric link and gigabit receivers. eUSB2 devices that support the higher isochronous IN bandwidth and the new descriptor can be identified by their device descriptor bcdUSB value of 0x0220 Co-developed-by: Amardeep Rai <amardeep.rai@intel.com> Signed-off-by: Amardeep Rai <amardeep.rai@intel.com> Signed-off-by: Kannappan R <r.kannappan@intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250220141339.1939448-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-20usb: gadget: Fix setting self-powered state on suspendMarek Szyprowski
cdev->config might be NULL, so check it before dereferencing. CC: stable <stable@kernel.org> Fixes: 40e89ff5750f ("usb: gadget: Set self-powered based on MaxPower and bmAttributes") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20250220120314.3614330-1-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ucsi: increase timeout for PPM reset operationsFedor Pchelkin
It is observed that on some systems an initial PPM reset during the boot phase can trigger a timeout: [ 6.482546] ucsi_acpi USBC000:00: failed to reset PPM! [ 6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Still, increasing the timeout value, albeit being the most straightforward solution, eliminates the problem: the initial PPM reset may take up to ~8000-10000ms on some Lenovo laptops. When it is reset after the above period of time (or even if ucsi_reset_ppm() is not called overall), UCSI works as expected. Moreover, if the ucsi_acpi module is loaded/unloaded manually after the system has booted, reading the CCI values and resetting the PPM works perfectly, without any timeout. Thus it's only a boot-time issue. The reason for this behavior is not clear but it may be the consequence of some tricks that the firmware performs or be an actual firmware bug. As a workaround, increase the timeout to avoid failing the UCSI initialization prematurely. Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value") Cc: stable <stable@kernel.org> Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250217105442.113486-3-boddah8794@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19acpi: typec: ucsi: Introduce a ->poll_cci methodChristian A. Ehrhardt
For the ACPI backend of UCSI the UCSI "registers" are just a memory copy of the register values in an opregion. The ACPI implementation in the BIOS ensures that the opregion contents are synced to the embedded controller and it ensures that the registers (in particular CCI) are synced back to the opregion on notifications. While there is an ACPI call that syncs the actual registers to the opregion there is rarely a need to do this and on some ACPI implementations it actually breaks in various interesting ways. The only reason to force a sync from the embedded controller is to poll CCI while notifications are disabled. Only the ucsi core knows if this is the case and guessing based on the current command is suboptimal, i.e. leading to the following spurious assertion splat: WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1 Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023 Workqueue: events_long ucsi_init_work [typec_ucsi] RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] Call Trace: <TASK> ucsi_init_work+0x3c/0xac0 [typec_ucsi] process_one_work+0x179/0x330 worker_thread+0x252/0x390 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Thus introduce a ->poll_cci() method that works like ->read_cci() with an additional forced sync and document that this should be used when polling with notifications disabled. For all other backends that presumably don't have this issue use the same implementation for both methods. Fixes: fa48d7e81624 ("usb: typec: ucsi: Do not call ACPI _DSM method for UCSI read operations") Cc: stable <stable@kernel.org> Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Tested-by: Fedor Pchelkin <boddah8794@gmail.com> Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250217105442.113486-2-boddah8794@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix functionalityAngeloGioacchino Del Regno
During probe, the TCPC alert interrupts are getting masked to avoid unwanted interrupts during chip setup: this is ok to do but there is no unmasking happening at any later time, which means that the chip will not raise any interrupt, essentially making it not functional as, while internally it does perform all of the intended functions, it won't signal anything to the outside. Unmask the alert interrupts to fix functionality. Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver") Cc: stable <stable@kernel.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250219114700.41700-1-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: gadget: Set self-powered based on MaxPower and bmAttributesPrashanth K
Currently the USB gadget will be set as bus-powered based solely on whether its bMaxPower is greater than 100mA, but this may miss devices that may legitimately draw less than 100mA but still want to report as bus-powered. Similarly during suspend & resume, USB gadget is incorrectly marked as bus/self powered without checking the bmAttributes field. Fix these by configuring the USB gadget as self or bus powered based on bmAttributes, and explicitly set it as bus-powered if it draws more than 100mA. Cc: stable <stable@kernel.org> Fixes: 5e5caf4fa8d3 ("usb: gadget: composite: Inform controller driver of self-powered") Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250217120328.2446639-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: gadget: u_ether: Set is_suspend flag if remote wakeup failsPrashanth K
Currently while UDC suspends, u_ether attempts to remote wakeup the host if there are any pending transfers. However, if remote wakeup fails, the UDC remains suspended but the is_suspend flag is not set. And since is_suspend flag isn't set, the subsequent eth_start_xmit() would queue USB requests to suspended UDC. To fix this, bail out from gether_suspend() only if remote wakeup operation is successful. Cc: stable <stable@kernel.org> Fixes: 0a1af6dfa077 ("usb: gadget: f_ecm: Add suspend/resume and remote wakeup support") Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250212100840.3812153-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: atm: cxacru: fix a flaw in existing endpoint checksNikita Zhandarovich
Syzbot once again identified a flaw in usb endpoint checking, see [1]. This time the issue stems from a commit authored by me (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")). While using usb_find_common_endpoints() may usually be enough to discard devices with wrong endpoints, in this case one needs more than just finding and identifying the sufficient number of endpoints of correct types - one needs to check the endpoint's address as well. Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind, switch the endpoint verification approach to usb_check_XXX_endpoints() instead to fix incomplete ep testing. [1] Syzbot report: usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ... Reported-and-tested-by: syzbot+ccbbc229a024fa3e13b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ccbbc229a024fa3e13b5 Fixes: 2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()") Cc: stable@kernel.org Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://lore.kernel.org/r/20250213122259.730772-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix configuration error handlingJohan Hovold
Propagate errors to the consumers when configuring the retimer so that they can act on any failures as intended, for example: ps883x_retimer 2-0008: failed to write conn_status_0: -5 pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to setup retimer to DP: -5 Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-4-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix missing accessibility checkJohan Hovold
Make sure that the retimer is accessible before registering to avoid having later consumer calls fail to configure it, something which, for example, can lead to a hotplugged display not being recognised: [drm:msm_dp_panel_read_sink_caps [msm]] *ERROR* read dpcd failed -110 Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-3-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix registration raceJohan Hovold
Make sure that the retimer is fully setup before registering it to avoid having consumers try to access it while it is being reset. Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218152933.22992-2-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: typec: ps883x: fix probe error handlingJohan Hovold
Fix the probe error handling to avoid unbalanced clock disable or leaving regulators on after probe failure. Note that the active-low reset pin should also be asserted to avoid leaking current after disabling the regulators. Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250218082243.9318-1-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: Implement recovery after PM domain offStefan Wahren
According to the dt-bindings there are some platforms, which have a dedicated USB power domain for DWC2 IP core supply. If the power domain is switched off during system suspend then all USB register will lose their settings. Use GUSBCFG_TOUTCAL as a canary to detect that the power domain has been powered off during suspend. Since the GOTGCTL_CURMODE_HOST doesn't match on all platform with the current mode, additionally backup GINTSTS. This works reliable to decide which registers should be restored. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250217134132.36786-4-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: Refactor backup/restore of registersStefan Wahren
The DWC2 runtime PM code reuses similar patterns to backup and restore the registers. So consolidate them in USB mode specific variants. This also has the advantage it is reusable for further PM improvements. Special care is taken for DCFG register during device mode restore. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250217134132.36786-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: dwc2: gadget: Introduce register restore flagsStefan Wahren
dwc2_restore_device_registers() use a single boolean to decide about the register restoring behavior. So replace this with a flags parameter, which can be extended later. No functional change intended. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250217134132.36786-2-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-19usb: misc: onboard_dev: add vdda support for Microchip USB2514Catalin Popescu
This hub is powered by digital and analog 3V3 power rails, so provide the possibility to use different regulators for digital (vdd) and analog (vdda) power rails. Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Link: https://lore.kernel.org/r/20250213094338.1611389-3-catalin.popescu@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-18usb: typec: tcpm: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/7fd2a1f72b3833e1fb36f56f2b28a08c1e64f47e.1738746904.git.namcao@linutronix.de
2025-02-18usb: musb: cppi41: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/80d59a56c76c76ace982417e4dc8ddd37a5441d7.1738746904.git.namcao@linutronix.de
2025-02-18usb: ehci: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/d703731ba61d1901c97758a60ccc3c209d21de0e.1738746904.git.namcao@linutronix.de
2025-02-18usb: gadget: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/7239d6211ffb0dff6351d0549d065277f2562793.1738746904.git.namcao@linutronix.de
2025-02-18usb: fotg210-hcd: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/eeabb788995d7566017ebcff6cc2daa8da35432d.1738746904.git.namcao@linutronix.de
2025-02-18usb: dwc2: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/ab5762d4fd512ac318e7962109d80547d38419cd.1738746904.git.namcao@linutronix.de
2025-02-18USB: chipidea: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/a6e43ac5a90f975343e1cef2d8346b4697ec0473.1738746904.git.namcao@linutronix.de
2025-02-17USB: serial: mos7840: drop unused definesJohan Hovold
Drop some defines that have never (really) been used, some of which are duplicates (the read and write requests) and others which are just bogus (the ioctl). Signed-off-by: Johan Hovold <johan@kernel.org>
2025-02-17Merge 6.14-rc3 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-14usb: typec: Add support for Parade PS8830 Type-C RetimerAbel Vesa
The Parade PS8830 is a USB4, DisplayPort and Thunderbolt 4 retimer, controlled over I2C. It usually sits between a USB/DisplayPort PHY and the Type-C connector, and provides orientation and altmode handling. The boards that use this retimer are the ones featuring the Qualcomm Snapdragon X Elite SoCs. Add a driver with support for the following modes: - DisplayPort 4-lanes - DisplayPort 2-lanes + USB3 - USB3 There is another variant of this retimer which is called PS8833. It seems to be really similar to the PS8830, so future-proof this driver by naming it ps883x. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250206-x1e80100-ps8830-v6-2-60b1e49cfa8d@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-07-15 17:44:45 +0000