summaryrefslogtreecommitdiff
path: root/drivers/usb/host
AgeCommit message (Collapse)Author
20 hoursMerge branch 'usb-next' of ↵Mark Brown
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
23 hoursMerge branch 'soc_fsl' of ↵Mark Brown
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/chleroy/linux.git
6 daysusb: ohci-st: disable controller wakeup on removalMyeonghun Pak
Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: d115837259ad ("usb: host: ohci-st: Add OHCI driver support for ST STB devices") Cc: stable <stable@kernel.org> Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260915012011.61874-5-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 daysusb: ohci-spear: disable controller wakeup on removalMyeonghun Pak
Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable <stable@kernel.org> Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260915012011.61874-4-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 daysusb: ohci-s3c2410: disable controller wakeup on removalMyeonghun Pak
Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable <stable@kernel.org> Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260915012011.61874-3-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 daysusb: ohci-da8xx: disable controller wakeup on cleanupMyeonghun Pak
The OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Probe enables wakeup, but neither removal nor a later notifier registration failure disables it, leaving the wakeup source attached. Disable controller wakeup after removing the HCD on both paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable <stable@kernel.org> Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260915012011.61874-2-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: octeon-hcd: sleep on an hrtimer for far-off periodic transfersOrgad Shaneh
cvmx_usb_schedule() enables the SOF interrupt whenever any pipe has next_tx_frame in the future, and leaves it enabled until the transfer is due. An interrupt endpoint keeps such a deadline pending permanently, so a single attached hub (status pipe polled every 256ms) costs an interrupt on every SOF - 8000/s in high-speed mode, forever. On a 300MHz CN5020 that is measurably ~20% of one core spent counting frames. The frame counter is resynchronized from HFNUM at the top of every poll, so the driver does not actually need to see every SOF to know when a deadline arrives. Sleep on an hrtimer when the nearest deadline is more than a few frames away (one high-speed frame is 125us) and keep SOF interrupts only for deadlines that are imminent - or far enough away to risk the 16383-frame HFNUM wrap, where the interrupt path still tracks the counter extension. Measured on a CN5020 board with one 4-port hub attached and idle: 8200 -> 4 USB interrupts/s, with no change in enumeration or transfer behavior. Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh <orgads@gmail.com> Link: https://patch.msgid.link/20260901193100.1352110-3-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: octeon-hcd: fail the probe when the USB core does not respondOrgad Shaneh
If the USBN clock/PHY setup did not actually bring the core up (wrong board reference-clock configuration, for instance), every USBC CSR reads as all-ones and initialization marches on programming garbage, ending in timeouts or a wedge deep in the FIFO flush. Read GHWCFG3 - a hardwired configuration register that can be neither 0 nor all-ones on a live core - right before core initialization, and give up cleanly if the core is not answering. Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh <orgads@gmail.com> Link: https://patch.msgid.link/20260901193100.1352110-2-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: octeon-hcd: fix the FIFO-flush timeout computationOrgad Shaneh
cvmx_wait_tx_rx() computes its 100us deadline from (u64)octeon_get_clock_rate - the address of the function, not its return value; the parentheses have been missing since the CVMX_WAIT_FOR_FIELD32 macro became a function. The cast makes it compile silently, and the resulting deadline is effectively infinite. On a healthy controller the flush bit clears on the first read and nothing is noticed. On a controller whose PHY did not come up (for example when the reference-clock configuration is wrong for the board), txfflsh/rxfflsh never clear and probe spins forever in __delay() - observed as a hard hang with a soft-lockup splat on a CN5020 board, where the board watchdog then resets the system with no console output. Call the function, restoring the 100us timeout the code always intended. Fixes: 3e195a80e096 ("Staging: octeon-usb: Replaces CVMX_WAIT_FOR_FIELD32 macro with a function") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh <orgads@gmail.com> Link: https://patch.msgid.link/20260901193100.1352110-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 dayssoc: fsl: qe: drop GPIOD_FLAGS_BIT_NONEXCLUSIVEBartosz Golaszewski
The GPIOD_FLAGS_BIT_NONEXCLUSIVE flag for gpiod_get() is deprecated. For actually shared GPIOs, it should be replaced by using the functionality provided by gpio-shared-proxy. The Freescale QUICC Engine GPIO driver uses it as a workaround to access the GPIO descriptor already requested by the caller of qe_pin_request() in order to access the private GPIO chip data. As the existing comment itself states, the user already requested this GPIO and the only user in tree is the FHCI USB driver which does in fact request it, we can safely modify the function to take the *exclusive* GPIO descriptor as argument and stop using the deprecated flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20260908-usb-fhci-drop-gpio-nonexclusive-v1-1-8e405dc67874@oss.qualcomm.com Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
12 daysusb: ehci: support additional controller quirksLinus Walleij
Some EHCI implementations omit CONFIGFLAG and USBMODE, or have an integrated transaction translator that cannot schedule siTDs. Add quirks to skip CONFIGFLAG and TDI mode accesses and to reject full- and low-speed isochronous transfers. Standard controllers retain their current behavior. Suggested-by: Daniel Palmer <daniel@thingy.jp> Assisted-by: LLM Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-4-dd92ecf5675b@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: ehci: add port speed hookLinus Walleij
Some EHCI implementations report device speed in implementation-defined registers. Add an optional hook for port speed reporting. Move the common integrated-TT speed decoding into the hub code, preserving the PORTSC and HOSTPC paths when no hook is supplied. Gate the callback behind the hidden USB_EHCI_PORT_SPEED_HOOK option so controllers using standard speed reporting incur no extra state or runtime checks. The hook is only meaningful for controllers with an integrated root hub transaction translator, so make the option depend on USB_EHCI_ROOT_HUB_TT. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Daniel Palmer <daniel@thingy.jp> Assisted-by: LLM Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-3-dd92ecf5675b@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: ehci: add port reset hooksLinus Walleij
Some EHCI implementations need controller-specific sequencing around port reset. Add optional hooks for reset preparation and completion. Controllers without the hooks retain the existing behavior. Gate the callbacks behind the hidden USB_EHCI_PORT_RESET_HOOKS option so controllers using standard reset sequencing incur no extra state or runtime checks. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Daniel Palmer <daniel@thingy.jp> Assisted-by: LLM Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-2-dd92ecf5675b@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: ehci: support non-standard port status registersLinus Walleij
Some EHCI implementations place the port status registers outside the standard operational register layout. Add a per-controller port status base and use a helper for all PORTSC accesses, while preserving the standard location by default. Gate the alternate member and lookup behind the hidden USB_EHCI_DEVIANT_PORT_STATUS_REG option. This avoids growing struct ehci_hcd or adding a runtime branch on systems using the standard port status register location. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Daniel Palmer <daniel@thingy.jp> Assisted-by: LLM Signed-off-by: Linus Walleij <linusw@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-1-dd92ecf5675b@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysUSB: pci-quirks: Release EHCI device referenceYuho Choi
for_each_pci_dev() holds a reference to the current device. The Intel EHCI lookup breaks as soon as it finds a match, so the iterator does not get a chance to drop that reference on its next iteration. Release the reference before leaving the loop. Fixes: 26b76798e050 ("Intel xhci: refactor EHCI/xHCI port switching") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260807024304.928708-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysUSB: OHCI: drop unneeded semicolonJulia Lawall
When a function-like macro expands to an expression, that expression doesn't need a semicolon after it. All uses have been verified to have their own semicolons. This was found using the following Coccinelle semantic patch: @r@ identifier i : script:ocaml() { String.lowercase_ascii i = i }; expression e; @@ *#define i(...) e; Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260801191002.1383835-1-Julia.Lawall@inria.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: ohci-ppc-of: use platform for irq and ioremapRosen Penev
Replace the open-coded of_address_to_resource() plus devm_ioremap_resource() sequence with devm_platform_get_and_ioremap_resource(), which looks up the resource and maps it in one call. The helper returns a pointer to the resource, so update rsrc_start / rsrc_len to dereference it and assign the mapped address to hcd->regs. Use a separate on-stack resource (ehci_res) for the unrelated ibm,usb-ehci-440epx erratum lookup rather than aliasing the returned resource pointer. Switch IRQ acquisition from irq_of_parse_and_map() to platform_get_irq(), which only retrieves the interrupt the OF/platform core has already set up rather than transferring mapping ownership to the driver. Drop the now unneeded irq_dispose_mapping() calls (probe error path and ohci_hcd_ppc_of_remove()) and the now-unused of_irq.h include, keeping linux/of_address.h for the erratum block's of_address_to_resource(). Behaviorally equivalent with respect to region reservation: the prior code used devm_ioremap_resource(), which already reserved the region. Built for PowerPC (ppc44x_defconfig + CONFIG_USB_OHCI_HCD_PPC_OF) with LLVM=1; drivers/usb/host/ohci-hcd.o (which includes ohci-ppc-of.c) compiles cleanly. Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260713231604.1090044-1-rosenp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysusb: ehci-ppc-of: use platform for irq and ioremapRosen Penev
Replace the open-coded of_address_to_resource() plus devm_ioremap_resource() sequence with devm_platform_get_and_ioremap_resource(), which looks up the resource and maps it in one call. The helper returns a pointer to the resource, so update rsrc_start / rsrc_len to dereference it, assign the mapped address to hcd->regs, and use a separate on-stack resource (ohci_res) for the unrelated ibm,usb-ohci-440epx erratum lookup rather than aliasing the returned resource pointer. Switch IRQ acquisition from irq_of_parse_and_map() to platform_get_irq(), which only retrieves the interrupt the OF/platform core has already set up rather than transferring mapping ownership to the driver. Drop the now unneeded irq_dispose_mapping() calls (probe error path and ehci_hcd_ppc_of_remove()) and the now-unused of_irq.h and of_platform.h includes, keeping linux/of_address.h for the erratum block's of_address_to_resource(). Behaviorally equivalent with respect to region reservation: the prior code used devm_ioremap_resource(), which already reserved the region. Built for PowerPC (ppc44x_defconfig + CONFIG_USB_EHCI_HCD_PPC_OF) with LLVM=1; drivers/usb/host/ehci-hcd.o (which includes ehci-ppc-of.c) compiles cleanly. Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260713231302.1076740-1-rosenp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-09-07Merge 7.3-rc2 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-09-01usb: host: xhci-tegra: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Link: https://patch.msgid.link/20260731035448.252289-7-panchuang@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-31xhci: fix lost bounce buffers on TDs spanning several ring segmentsArthur Gautier
When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Arthur Gautier <baloo@superbaloo.net> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-31usb: xhci: Fix isochronous scheduling regressionMichal Pecio
An isoc URB without URB_ISO_ASAP should be scheduled immediately after the previous one, unless it's the first submission or prior URBs have completed without resubmitting and the endpoint became idle. An HCD_BH driver must consider URBs pending completion in the BH queue in addition to its own queue. Regrettably, core doesn't provide much information, we can only know if we are being called by completion now. This issue is as old as HCD_BH, affects ehci-hcd too and has no known reproducible impact, as drivers generally resubmit from completion. A recent patch tried to address it by looking at xHCI HW state instead. Obviously, HW has no knowledge of the BH giveback queue either, and the whole solution amounts to testing whether prior URBs have been unlinked instead of completing normally - then a new stream is assumed. This leads to false negatives when a driver simply allows the endpoint to empty out and begins a new stream. New URBs are scheduled into the past and promptly fail with -EXDEV status, causing data loss and worse, because drivers get confused by premature completion, particularly when multiple endpoints are started at once and required to stay in sync. snd-usb-audio underruns the OUT endpoint when userspace fails to supply playback data in time. If this is detected in duplex mode, IN URBs are unlinked and both streams restarted. OUT underruns again before IN even begins, another recovery is attempted and the cycle repeats. Fix this by using the best criteria we can muster, taken from ehci-hcd. This brings false negative rate back to zero and false positive rate to less than ever before in xhci-hcd. Traditional logic was equivalent to: if (list_empty(&ep_ring->td_list) || GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING) // consider this URB a new stream While free of false negatives, it had easily avoidable false positives: * no check for completion in progress when the list is empty * the ep_ctx check doesn't make up for it at all, but it adds a race - EP state can remain "stopped" for a while after the first submission [mn: add debug message in possible false positive case where driver might incorrectly assume new stream starts mid stream just because td list is empty (URB enqueue is late), and workqueue isn't processing URB completions for this endpoint at the moment] Link: https://lore.kernel.org/linux-usb/20260813005635.34750f8c.michal.pecio@gmail.com/ Fixes: add8469b3e00 ("xhci: fix frame id calculation and checks for isoc URBs") Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260831090448.95644-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-31usb: xhci: Fix HCS_ERST_MAX conversionChen-Yu Tsai
This fixes one broken line in commit 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros") included in 7.3-rc1 kernel HCS_ERST_MAX holds power of 2 value for maximum number of segments. In the culprit commit, this was incorrectly converted to "shift up 2". On hardware where this field is zero, this results in xhci_alloc_erst() calling dma_alloc_coherent() with size = 0, leading to a horrible splat and non-usable XHCI. Revert the shift-up-2 to the BIT() macro. Fixes: 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros") Cc: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Tested-by: Pierre-David Belanger <pierredavidbelanger@gmail.com> Link: https://patch.msgid.link/20260831090448.95644-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-25Merge tag 'usb-7.3-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 7.3-rc1. Lots of driver work for new devices and systems, and many other minor fixes and updates. Included in here are: - Thunderbolt subsystem driver updates and additions - typec driver updates and additions - usb gadget fixes all over the place, seems like people are finally paying attention to these drivers for some reason - xhci driver updates and fixes based on lots of reports - usb-serial driver updates and additions - new device ids - other minor USB driver updates and fixes All of these have been in linux-next for a while with no reported issues" * tag 'usb-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (163 commits) usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() usb: typec: hd3ss3220: fix VBUS regulator error message usb: usbfs: fix use-after-free of usb_device in usbdev_release() usb: gadget: u_audio: Fix use-after-free on sound card disconnect usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due to race condition usb: gadget: f_tcm: keep port count until LUN teardown completes usb: usbtest: disable dynamic ID support usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive() USB: c67x00: fix use-after-free in c67x00_add_iso_urb() usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion usb: gadget: snps_udc_plat: clean up PHY on probe deferral usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usb: dwc2: gadget: Exit partial power down state when changing USB pull-up usb: gadget: f_fs: Fix Use-After-Free in AIO error path usb: gadget: f_fs: Prevent deadlock during ep0 read loop usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed usb: gadget: midi2: remove default configfs groups on teardown usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init() usb: typec: thunderbolt: Disable work before freeing tbt on remove usb: xhci: Handle bogus TRB pointers in Missed Service Error events ...
2026-08-18Merge tag 'soc-drivers-7.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "The SoC driver changes once more consist of many small fixes and cleanups, that are to a large part the result of automated testing. On platform specific drivers, this includes SoC specific code for xilinx, freescale/nxp, qualcomm, TI, aspeed, omap, tegra, samsung, rockchip, renesas, ixp4xx. In firmware drivers, we see a similar picture for SCMI and qcomtee. Aside from these, we see actual new hardware support in a few areas: - The Apple platform gets a new driver for low power states - Updates to Qualcomm platform drivers add several new hardware specific features and additional SoCs. - Amlogic SoC support for A1 and T7 is added - The Mediatek MMSYS driver is refactored as a cleanup" * tag 'soc-drivers-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (157 commits) soc: qcom: make QCOM_PDR_MSG selectable soc: qcom: ubwc: Fix missing include soc: qcom: ubwc: Fix link error when QCOM_SMEM=n media: iris: Guard the QCOM_UBWC_CONFIG select with QCOM_SMEM drm/msm: Guard the QCOM_UBWC_CONFIG select with QCOM_SMEM dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDM 850 firmware: xilinx: Clear firmware notifiers across kexec transitions firmware: xilinx: Release all peripheral devices from firmware firmware: xilinx: Add support to clear EL3 PM state firmware: xilinx: Propagate actual error from feature check firmware: xilinx: Use TF-A feature check for TF-A-specific APIs bus: fsl-mc: drop unused assignment of acpi_device_id::driver_data soc: fsl: qe: check platform_driver_register() in qe_ic_of_init() phy: lynx-10g: use RCW override procedure for dynamic protocol change soc: fsl: guts: implement the RCW override procedure dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region soc: fsl: guts: make fsl_soc_data available after fsl_guts_init() soc: fsl: guts: make it easier to determine on which SoC we are running soc: fsl: guts: add a central fsl_guts_read() function soc: fsl: guts: add a global structure to hold state ...
2026-08-14usb: xhci: Handle bogus TRB pointers in Missed Service Error eventsMichal Pecio
xHCI 1.0 allowed these pointers to be zero. Some Intel chipsets from the era usually set it to zero, but sometimes (apparently) to the next TRB after the one referenced by the previous transfer event on the endpoint. Usually that's indeed the missed TD, but it may also be the last TRB of a two-TRB TD already completed with Short Packet on its first TRB. Then the driver skips all pending TDs, failing to find a match. When handling Missed Service Error, scan TD list twice and only really skip TDs in the second pass if the first pass found a match. This won't catch bogus pointers to wrong TDs, but such a bug would be practically impossible to detect automatically and isn't known to exist. Reported-by: Bart Nagel <bart@tremby.net> Closes: https://lore.kernel.org/linux-usb/al_hchyOdPoPWKEo@spiral/ Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Fixes: d0b619599e52 ("usb: xhci: Expedite skipping missed isoch TDs on modern HCs") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: Handle USB3 port events when there is one roothubSemih Baskan
handle_port_status() drops every USB3 port event when xhci->shared_hcd is NULL. The check dates from a time when xhci-plat always created a shared hcd, so a NULL one could only mean the hcd had been removed. Since commit 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") that is no longer true. A controller whose USB2 root hub has no ports gets a single roothub, the USB3 rhub is served by the main hcd, and shared_hcd stays NULL for the lifetime of the device. Every SuperSpeed port event is then thrown away as bogus behind a debug message, so devices never enumerate even though the port sees the device and its change bits stay set: 0x006a1203 Powered Connected Enabled Link:U0 PortSpeed:4 Change: CSC WRC PRC PLC Broadcom Northstar is such a controller. USB3 works there up to 5.15 and stops working from 5.19 onwards. Ask xhci_get_usb3_hcd() instead. It returns the shared hcd when there is one, the main hcd when the USB2 root hub has no ports, and NULL once the shared hcd is gone, which keeps the original meaning of the check. Tested on an Asus RT-N18U (BCM47081), which has a single roothub. Before the change nothing enumerates on the USB3 port; after it SuperSpeed devices enumerate normally over repeated connect and disconnect cycles, the change bits shown above clear, and USB2 is unaffected on both ports. Fixes: 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") Cc: stable@vger.kernel.org Signed-off-by: Semih Baskan <strst.gs@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: replace Unicode quotes with ASCII apostrophesNiklas Neronin
Non-ASCII characters trigger git send-email to prompt for encoding on each modification near them, which is unnecessary and annoying. Using plain ASCII avoids these prompts and does not change its meaning. This change only affects comments and has no functional impact. 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/20260806142113.2436238-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: remove redundant 'xhci' pointer from endpoint structNiklas Neronin
The 'xhci_virt_ep' struct currently contains a pointer to its parent 'xhci_hcd' struct. Since all endpoint-related structs are contained within 'xhci_hcd', this pointer is redundant. Remove the 'xhci' pointer from 'xhci_virt_ep' and instead pass it explicitly to functions that require it, as some already do it. This change reduces unnecessary complexity and aligns the code with the rest of the xhci driver. Memory impact: For each device connected a struct 'xhci_virt_device' is allocated, this struct conatains a 31 slot array of struct 'xhci_virt_ep'. A USB hub consumes 1 slot, but every downstream device consumes another slot. This means that the total memory saved buy this patch is: Devices * 31 * 8 bytes 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/20260806142113.2436238-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: remove redundant function wrapperNiklas Neronin
The function ring_doorbell_for_active_rings() rings the doorbell for any rings with pending URBs. It has a trivial wrapper, xhci_ring_doorbell_for_active_rings(), which takes the same arguments and simply calls the former. Since the wrapper adds no functionality, remove it and rename ring_doorbell_for_active_rings() to xhci_ring_doorbell_for_active_rings(). 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/20260806142113.2436238-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: use 64-bit Addressing Capability macroNiklas Neronin
Simplify by replace BIT(0) call with its relevant macro. 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/20260806142113.2436238-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: standardize multi bit-field macrosNiklas Neronin
This patch aims to unify the format of register macros and masks within the xHCI driver. Currently, register macros have inconsistent bit-field masks, get macros, and set macros, with varying naming conventions and functionalities. ==================== Proposal ==================== * Introduce a standardized approach by using only mask macros for each bit field, leveraging GENMASK() for enhanced clarity. #define HCC_MAX_PSA GENMASK(15, 12) * Utilize FIELD_GET() and FIELD_PREP() macros directly in the C code for getting and setting values, ensuring consistency and readability. u32 psa = FIELD_GET(HCC_MAX_PSA, reg); * Maintain exceptions for macros that perform custom operations. #define CTX_SIZE(_hcc) (_hcc & HCC_64BYTE_CONTEXT ? 64 : 32) * Note, while FIELD_*() macros are beneficial, I am not suggesting that they should always be used. Instead, use them where they simplify the code and eliminate the necessity for custom get/set macros. In the example below, additional FIELD_PREP() or FIELD_MODIFY() is not beneficial. #define HCS_MAX_SCRATCHPAD(p) (FIELD_GET(HCS_MAX_SP_HI, (p)) << 5 | \ FIELD_GET(HCS_MAX_SP_LO, (p))) ==================== Improvements ==================== Simplified Macros: By reducing custom macros, the code becomes more straightforward. Macros FIELD_GET() and FIELD_PREP() are commonly used, which contributes to the code readability and consistency. $ git grep -n 'FIELD_GET' | wc -l 9027 $ git grep -n 'FIELD_PREP' | wc -l 15407 Consistent Return Type: All bit macros will return unsigned 64-bit values, mitigating potential cross-architecture issues. Unified Bit Range Definition: The mask macro will define bit ranges, eliminating separate definitions for get/set macros. Because, FIELD_GET() & FIELD_PREP() use mask macro. Cleaner header file with less macros: Fewer macros result in a cleaner and more manageable header file. 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/20260806142113.2436238-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: bail out of setup if the controller is inaccessibleBreno Leitao
xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Drop extra call to idr_destroy()Lucas De Marchi
idr_destroy() is already called on error paths in dbc_tty_init(). Do not call it again on exit. For symmetry with the init side, also use IS_ERR_OR_NULL() to gate the exit steps. Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Fix unregister on tty_alloc_driver() failureLucas De Marchi
Make sure to set dbc_tty_driver to NULL to match the check in dbc_tty_exit(). For that, make detached error handling path common to the other branch in the same function. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable@vger.kernel.org # v5.10 Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Fix unregister on tty_register_driver() failureLucas De Marchi
If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable@vger.kernel.org # v5.10 Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: move dequeue to next valid td instead of past cancelled oneMathias Nyman
If a ring stops on a TD that is about to be cancelled then the xHC ring hardware dequeue pointer needs to move past the TD to flush TRBs from xHC cache. The TRB after the cancelled TD might be a no-op TRB, or a link TRB. Moving the dequeue to a link TRB has caused isses on some hosts, and moving it to a no-op TRB can be an issue for control endpoints as xhci specification 4.8.3 'Endpoint Context State" states that The Default Control Endpoint shall return to the Running state when the Doorbell is rung for the next Setup Stage TD sent to the endpoint. Solve this by always moving the dequeue pointer to the next valid TD. If ring is empty and there are no queued TDs then move the dequeue pointer to the enqueue pointer. If enqueue points to a link TRB on a empty ring then propagate enqueue to next segment before pointing dequeue to it. Note that this patch ended up almost identical to a simplifiaction patch done earlier by Michal Pecio, see link. That patch was not added due to a potential, somewhat theoretical issue of moving dequeue backwards. Turns out improving cancelled control transfers end up with the same code, and is now worth taking. Code is very likely subconsciously based the patch by Michal Pecio. Link: https://lore.kernel.org/linux-usb/20250225125939.7a248e38@foxbook/ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: avoid xHC endpoint changes after disconnect or link error.Mathias Nyman
Avoid all extra endpoint state changes after the roothub link is lost due to disconnect or link error, and endpoint is known to be in a non-running state. Rapid endpoint state changes involving endpoint reset, restart, and stopping the endpoint have caused xHC failures to complete stop endpoint command. xhci driver sees this as a fatal flaw and tears down xhci. These endpoint state changes are normally part of recovery from transaction errors or URB cancel. In this case recovery is not needed. Add an endpoint state called EP_DROP_PENDING. Set ep->ep_state |= EP_DROP_PENDING when an endpoint is found in a halted or stopped non-running state, and the roothub link is lost. Prevent endpoint from restarting. URB cancel doesn't need to stop the endpoint if EP_DROP_PENDONG is set. URBs can be given back directly. Endpoint is, and will remain stopped until it's dropped. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: prevent endpoint recovery after roothub disconnectMathias Nyman
Prevent transfer retry and endpoint recovery if the device or its parent disconnected from the roothub. Just like link error case. There is a suspicion some xHC controllers may stop processing endpoint related commands after the last USB device disconnects from the host. Disconnect often causes transaction errors, xhci driver tries to (soft) reset and restart the endpoint to recover it. Hub driver again will cancel all pending URBs once disconnect is detected, stopping the endpoint right after (soft) reset restarted it. xHC controller sometimes fail to complete the stop endpoint command, leading to driver timing out, and tearing down xhci Prevent extra endpoint (soft) reset after xhci driver is aware of the parent roothub port disconnect. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: include all root port children in recovery prevention on link errorMathias Nyman
Driver already prevents useless transfer retry and endpoint recovery for devices directly connected to a root port with link errors. These devices are either disconnecting or will be reset. Link is gone. Move the flag indicating link error from the xhci device structure to the root port strucure, allowing all child devices behind hubs to easily check for root port link errors, avoiding useless transfer retries and endpoint recovery. This extends the previous endpoint recovery prevention in commit b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Only root port link errors can be detected early by xhci driver, not link errors between external hubs and their children. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: Set frame ID field of isoc TRB when starting an isoch streamMathias Nyman
The frame id field can be set for the first TD of the first isoc URB to schedule the start of an isoc stream even in host doesn't support CFC (Contiguous Frame ID Capability) Set the frame ID TRB field of the first isoc TD unless URB has the schedule immediately 'URB_ISO_ASAP' transfer flag set. cc: Dylan Robinson <dylan_robinson@motu.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: fix frame id calculation and checks for isoc URBsMathias Nyman
Check if the expected frame IDs for a isochronous URB submitted mid stream is within the valid frame time window that xHC controller is capable of queuing TDs. The range only needs to be checked once per URB as the isoc TDs of an URB are queued in one go with spinlock held and interrupts disabled. Calculate the valid frame window start and end frame id in frames instead of microframes to better match how xhci specification section 4.11.2.5 does it. Don't add frame id gaps or change scheduling to SIA mid stream if the start frame is outside the valid frame winow. Only print a debug message. Some devices can't handle gaps in isochronous transfers. Calculate a valid start frame for the first URB of a stream, and align it to a full frame, or to interval start if interval is longer than a frame Set urb->start_frame value for every URB cc: Dylan Robinson <dylan_robinson@motu.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14Merge 7.2-rc7 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>
2026-08-10Merge tag 'soc_fsl-7.3-1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux into soc/drivers FSL SOC Changes for 7.3 Freescale QUICC Engine: - Use generic I/O helpers in interrupt controller for IO Ports - Move CONFIG_QE_GPIO out of powerpc - Fix DT scan for GPIO nodes - Convert IO ports interrupt controller to generic IRQ chip - Add support of IRQs in GPIO controller - Implement get_direction() in GPIO controller - Check platform_driver_register() in interrupt controller for IO Ports Data Path I/O: - Replace maintainer - Remove redundant dev_err() - Fix kernel-doc typos Freescale Management Complex: - Use strscpy() to copy strings into arrays - Remove redundant dev_err() - Drop unused assignment of acpi_device_id::driver_data Other changes: - Add kernel and device tree binding support for RCW override, completing the SerDes PHY driver functionality - Fix kernel-doc warnings and typos in DPAA header * tag 'soc_fsl-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux: (31 commits) bus: fsl-mc: drop unused assignment of acpi_device_id::driver_data soc: fsl: qe: check platform_driver_register() in qe_ic_of_init() phy: lynx-10g: use RCW override procedure for dynamic protocol change soc: fsl: guts: implement the RCW override procedure dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region soc: fsl: guts: make fsl_soc_data available after fsl_guts_init() soc: fsl: guts: make it easier to determine on which SoC we are running soc: fsl: guts: add a central fsl_guts_read() function soc: fsl: guts: add a global structure to hold state soc: fsl: guts: use a macro to encode the DCFG CCSR space soc: fsl: guts: perform fsl_guts_init() error teardown in reverse order of setup soc: fsl: dpio: fix kernel-doc typos soc: fsl: fix kernel-doc warnings and typos bus: fsl-mc: Remove redundant dev_err() soc: fsl: qe: Add support of IRQs in QE GPIO soc: fsl: qe: Rename irq variable to parent_irq soc: fsl: qe: Convert to generic IRQ chip soc: fsl: qe: Handle spurious interrupts soc: fsl: qe: Iterate over all pending interrupts in cascade handler soc: fsl: qe: Use generic_handle_domain_irq() ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-04usb: xhci: use BIT_ULL for CRCR bits to fix incorrect 64bit maskLachlan Hodges
xhci is unusable on some systems after driver switched to BIT() macro. Upper 32bits of 64bit CRCR command register are unintentionally cleared. Seen on a raspberry pi 4B compiled for arm32. The main symptoms were the following log message: [ 0.549897] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-02-25T12:11:39 [ 0.626859] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.626889] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 [ 0.812619] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000200000000890 [ 0.813188] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.813203] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2 [ 0.813219] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed [ 0.813602] hub 1-0:1.0: USB hub found [ 0.814052] hub 2-0:1.0: USB hub found [ 0.952714] xhci_hcd 0000:01:00.0: ERROR mismatched command completion event Additionally running lsusb just hangs. Running the same kernel compiled for aarch64 worked fine. Bisected to the commit in the Fixes line. Additionally a USB device plugged in to the USB3.0 (or 2.0) did not enumerate. Once this patch is applied the USB device enumerates properly. The CRCR register is 64 bits wide - commit abe93f27cdd7 ("xhci: use BIT macro") changed the flag definitions from (1 << n), a signed int, to BIT(n), an unsigned long. Within xhci_set_cmd_ring_deq(), the following operation is performed on the CRCR register: ... crcr &= ~CMD_RING_PTR_MASK; crcr |= deq_dma; crcr &= ~CMD_RING_CYCLE; crcr |= xhci->cmd_ring->cycle_state; ... Previously, ~CMD_RING_CYCLE was ~(int)1, a negative signed value (0xFFFFFFFE with the sign bit set). Widening a negative signed int to u64 sign-extends it to 0xFFFFFFFFFFFFFFFE, correctly clearing only bit 0 and preserving the 64-bit pointer written two lines above. After the change when running on 32 bit kernels, ~CMD_RING_CYCLE is ~(unsigned long)1UL. On a 32-bit host this is an unsigned 32-bit value (0xFFFFFFFE, no sign bit). Widening an unsigned value to u64 zero-extends it instead (0x00000000FFFFFFFE), so the subsequent AND silently clears bits 63:32 of crcr, truncating the command ring pointer that was just written before the value reaches hardware. To fix, similar to how CMD_RING_PTR_MASK is defined, make sure we use the BIT_ULL variant when defining the CRCR bits. [Mathias: use BIT_ULL() for ERST_EHB and EP_CTX_CYCLE_MASK as suggested by Michal Pecio, also include raspberry case in commit message] Fixes: abe93f27cdd7 ("xhci: use BIT macro") Cc: stable <stable@kernel.org> Assisted-by: Claude:claude-sonnet-5 cc: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260804083639.2148950-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-29powerpc: Move CONFIG_QE_GPIO to SoCChristophe Leroy (CS GROUP)
Commit 7aa1aa6ecec2 ("QE: Move QE from arch/powerpc to drivers/soc") moved QE into drivers/soc including gpio.c but left CONFIG_QE_GPIO in powerpc's Kconfig. Move it to SoC as well as it is the only place it is used: drivers/soc/fsl/qe/Makefile:obj-$(CONFIG_QE_GPIO) += gpio.o qe_ports_ic.o include/soc/fsl/qe/qe.h:#ifdef CONFIG_QE_GPIO include/soc/fsl/qe/qe.h:#endif /* CONFIG_QE_GPIO */ There is also a dependency in USB subsystem for CONFIG_USB_FHCI_HCD: drivers/usb/host/Kconfig: depends on QE_GPIO && QUICC_ENGINE Because that USB driver selects CONFIG_FSL_GTM which is specific to powerpc, it has to depend on CONFIG_PPC. Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://lore.kernel.org/r/9a7131d15a94e2017877e628f0e97f9aa2e0aae9.1785140877.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
2026-07-27Merge 7.2-rc5 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-13usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bitsXincheng Zhang
The VIA VL805/806 xHCI controller advertises AC64, but fails to handle DMA addresses at or above 0x1000000000. On systems with large amounts of RAM, this can cause USB device failures when the controller is given DMA addresses beyond its usable address width. Do not use XHCI_NO_64BIT_SUPPORT for this controller. That quirk clears the cached AC64 capability and limits DMA to 32 bits, causing unnecessary bouncing for addresses between 4GiB and 64GiB and hiding the controller's real AC64 capability from code that may need to distinguish register access width from usable DMA address width. Track the usable DMA address width separately from the AC64 capability. Initialize the generic xhci->dma_mask_bits field to 64 and let PCI quirks reduce it for controllers with narrower DMA support. Set VIA VL805/806 to 36 bits so the DMA API only hands it addresses in the range it can handle while keeping HCCPARAMS1.AC64 visible. Cc: stable <stable@kernel.org> Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Link: https://patch.msgid.link/20260630-xhci-via-dma-fix-v3-1-690dcb8cf75a@ultrarisc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-13Merge 7.2-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>
2026-07-10usb: fsl-mph-dr-of: add regulator supportRosen Penev
Some devices have a GPIO that controls power to the USB bus. Add support for a vbus regulator to have the kernel control it automatically instead of having to rely on userspace. Acquire the regulator in the common probe path so that it works for all fsl-usb2-dr compatible controllers, not just MPC5121. Tested on a TP-LINK WDR4900v1 by adding roughly the following reg_power_usb: regulator { compatible = "regulator-fixed"; regulator-name = "power_usb"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>; enable-active-high; regulator-boot-on; }; uhubctl and rmmod both turn USB power off. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260630195144.88122-1-rosenp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-22 08:29:56 +0000