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>
When a USB device with active stream endpoints is disconnected,
xhci_free_streams() is called from the hub_event workqueue to
free the stream resources. It calls xhci_free_stream_info()
while holding xhci->lock with irqs disabled.
xhci_free_stream_info() invokes xhci_free_stream_ctx(), which
calls dma_free_coherent() for large stream context arrays.
dma_free_coherent() can sleep (e.g. via vunmap), triggering
a BUG when called from atomic context.
Call trace:
dma_free_attrs+0x174/0x220
xhci_free_stream_info+0xd0/0x11c
xhci_free_streams+0x278/0x37c
usb_free_streams+0x98/0xc0
usb_unbind_interface+0x1b8/0x2f8
device_release_driver_internal+0x1d4/0x2cc
device_release_driver+0x18/0x28
bus_remove_device+0x160/0x1a4
device_del+0x1ec/0x350
usb_disable_device+0x98/0x214
usb_disconnect+0xf0/0x35c
hub_event+0xab4/0x19ec
process_one_work+0x278/0x63c
Fix this by saving the stream_info pointers and clearing the
ep references under the lock, then calling xhci_free_stream_info()
outside the lock where sleeping is allowed.
Fixes: 8df75f42f8 ("USB: xhci: Add memory allocation for USB3 bulk streams.")
Cc: stable <stable@kernel.org>
Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260703144033.483286-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci_ring_to_sgtable() allocates a temporary pages array and
uses it to build the returned sg_table with
sg_alloc_table_from_pages().
The error paths free the pages array, but the success path
returns the sg_table without freeing it. This leaks the temporary
array every time a sideband client gets an endpoint or event ring
buffer.
Free the pages array after sg_alloc_table_from_pages() succeeds.
The returned sg_table has its own scatterlist entries and does not
depend on the temporary array after construction.
Fixes: de66754e9f ("xhci: sideband: add initial api to register a secondary interrupter entity")
Cc: stable <stable@kernel.org>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260703144033.483286-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sl811h_probe() enables the HCD controller device as a wakeup source after
usb_add_hcd() succeeds, but sl811h_remove() removes the HCD and releases
the driver resources without disabling that wakeup source.
Disable controller wakeup after usb_remove_hcd() and before usb_put_hcd()
so the wakeup source object is detached while the controller device pointer
is still available.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 3c9740a117 ("usb: hcd: move controller wakeup setting initialization to individual driver")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/20260701121625.96815-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EHCI and FOTG210 isochronous submits build an ehci_iso_sched before
linking the URB to the endpoint queue, and keep the staged schedule in
urb->hcpriv until iso_stream_schedule() and the link helpers consume it.
If the controller is no longer accessible, or usb_hcd_link_urb_to_ep()
fails, submit jumps to done_not_linked before that handoff happens and
leaks the staged schedule still attached to urb->hcpriv.
Free the staged schedule from done_not_linked when submit fails before
the URB is linked and clear urb->hcpriv after the free.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
EHCI host controller with a USB isochronous device to test with, no
runtime testing was able to be performed.
Fixes: 8de9840265 ("[PATCH] USB: Fix USB suspend/resume crasher (#2)")
Fixes: e9df41c5c5 ("USB: make HCDs responsible for managing endpoint queues")
Fixes: 7d50195f6c ("usb: host: Faraday fotg210-hcd driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260630071419.349161-1-dawei.feng@seu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allow xHC to runtime suspend if DbC is in 'enabled' state for over
15 seconds without a connect.
Idea is that every time we go to 'enabled' state we make sure DbC runtime
pm usage is '1' and save a timestamp. if the event loop still finds DbC in
enabled state 15 seconds later then it decrease DbC runtime pm usage by
calling pm_runtime_put().
Enabled state is reached either when DbC is enabled by userspace or a
connected/configured DbC is disconnected.
When a connect is detected we make sure DbC usage count is 1.
If DbC has been in 'enabled' state for 15 seconds and DbC usage is
decreased to 0 by pm_runtime_put, then the whole xHC controller may
runtime suspends to PCI D3 state if no other devices are using it
DbC sysfs file will show 'suspended' when xHC is suspended and will wake up
and enable DbC at cable connect, or when user writes 'enable' to the file.
This patch was originally part of a larger DbC series, but dropped before
the series was submitted to 7.2-rc1. The series has a locking issue in
commit 520058b73b ("xhci: dbc: serialize enabling and disabling dbc")
which is also resolved by this patch
Fixes: 520058b73b ("xhci: dbc: serialize enabling and disabling dbc")
Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Closes: https://lore.kernel.org/linux-usb/9ce24ff5-efab-4089-92d7-709862d68e6d@intel.com
Tested-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260616100916.2234205-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull USB and Thunderbolt driver updates from Greg KH:
"Here is the big set of USB and Thunderbolt driver changes for 7.2-rc1.
Lots of little stuff in here, major highlights include:
- USB4STREAM support for Thunderbolt devices. A new way to send "raw"
data very quickly over a USB4 connection to another system directly
- Other thunderbolt updates and changes to make the stream code work
- xhci driver updates and additions
- typec driver updates and additions
- usb gadget driver updates and fixes for reported issues
- zh_CN documentation translation of the USB documentation
- usb-serial driver updates
- dts cleanups for some USB platforms
- other minor USB driver updates and tweaks
All of these have been in linux-next for over a week with no reported
issues, most of them for many many weeks"
* tag 'usb-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (131 commits)
usb: ucsi: huawei_gaokun: support mode switching
thunderbolt: debugfs: Fix sideband write size check
thunderbolt: debugfs: Fix margining error counter buffer leak
usb: host: xhci-rcar: Split R-Car Gen2 and Gen3 .plat_start() handling
usb: host: xhci-rcar: Remove SET_XHCI_PLAT_PRIV_FOR_RCAR() macro
usb: xhci: allocate internal DCBAA mirror dynamically
usb: xhci: allocate DCBAA based on host controller max slots
usb: xhci: refactor DCBAA struct
xhci: Prevent queuing new commands if xhci is inaccessible
xhci: dbc: detect and recover hung DbC during enumeraton
xhci: dbc: add timestamps to DbC state changes in a new helper.
xhci: dbc: add helper to set and clear DbC DCE enable bit
xhci: dbc: serialize enabling and disabling dbc
xhci: dbc: Fix sysfs ABI Documentation for xhci dbc states
usb: xhci: Improve Soft Retries after short transfers
usb: xhci: Remove isochronous URB_SHORT_NOT_OK handling
usb: xhci: Remove skip_isoc_td()
usb: xhci: Simplify xhci_quiesce()
usb: xhci: remove legacy 'num_trbs_free' tracking
usb: xhci: fix typo in xhci_set_port_power() comment
...
Pull SoC driver updates from Arnd Bergmann:
"There are a few added drivers, but mostly the normal maintenance to
drivers for firmware, memory controller and other soc specific
hardware:
- The NXP QuickEngine gets modern MSI support, which allows some
cleanups to the GICv3 irqchip chip driver
- A new SoC specific driver for the Renesas R-Car MFIS unit is added,
encapsulating support for the on-chip mailbox and hwspinlock
implementations that are not easily separated into individual
drivers
- The Qualcomm SoC drivers add support for additional SoC
implementations, and flexibility around power management for the
serial-engine driver as well as probing the LLCC driver using
custom hardware descriptions inside of the device itself.
- Added support for the Samsung thermal management unit
- A cleanup to the Tegra 'PMC' driver interfaces to remove legacy
APIs and allow multiple PMC instances everywhere.
- Updates to the TI SCI and KNAS drivers to improve suspend/resume
support.
- Minor driver changes for mediatek, xilinx, allwinner, aspeed,
tegra, broadcom, amd, microchip and starfive specific drivers
- Memory controller updates for Tegra and Renesas for additional SoC
types and other improvements.
- Firmware driver updates for Arm FF-A, SMCCC and SCMI interfaces, to
update driver probing, object lifetimes and address minor bugs"
* tag 'soc-drivers-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (189 commits)
Revert "firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface"
Revert "Documentation: ABI: add sysfs interface for ZynqMP CSU registers"
memory: tegra234: drop dead NULL check in tegra234_mc_icc_aggregate()
memory: tegra264: drop redundant tegra264_mc_icc_aggregate()
memory: tegra186-emc: stop borrowing MC aggregate hook for EMC
soc: aspeed: cleanup dead default for ASPEED_SOCINFO
firmware: tegra: bpmp: Add support for multi-socket platforms
firmware: tegra: bpmp: Propagate debugfs errors
soc/tegra: pmc: Add Tegra238 support
soc/tegra: pmc: Restrict power-off handler to Nexus 7
soc/tegra: pmc: Populate powergate debugfs only when needed
soc/tegra: pmc: Move legacy code behind CONFIG_ARM guard
soc/tegra: pmc: Remove unused legacy functions
soc/tegra: pmc: Create PMC context dynamically
firmware: samsung: acpm: remove compile-testing stubs
firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
firmware: samsung: acpm: Add TMU protocol support
firmware: samsung: acpm: Make acpm_ops const and access via pointer
firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
...
Currently, R-Car Gen2 and Gen3 share the same .plat_start() callback.
However, this single callback performs different operations, after
checking the XHCI's controller compatible value.
Avoid repeated checking of compatible values and reduce kernel size by
splitting this method in two separate functions. Update
xhci_rcar_resume_quirk() to dispatch to the correct method by calling it
through the .plat_start() function pointer, too.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/d1ee4e1bb9106f8251b061b52948434d560b4675.1780499433.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allocate the internal virtual device array dynamically based on the
maximum number of slots reported by the host controller. Previously,
the array was always allocated to the absolute maximum of 255 entries.
Repurpose the 'MAX_HC_SLOTS' macro to limit the number of enabled slots.
This mirrors how the maximum number of ports and interrupters are handled.
The allocation now uses kcalloc_node(), which zeroes the memory
automatically, making the explicit memset() call unnecessary.
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/20260603091132.1110849-16-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allocate the Device Context Base Address Array (DCBAA) according to the
maximum number of device slots supported by the host controller, instead
of always allocating the absolute maximum of 255 entries.
The xHCI specification defines the DCBAA size as (MaxSlotsEnabled + 1)
entries. In the xhci driver there is currently no distinction between
MaxSlots and MaxSlotsEnabled, as all available slots are enabled during
initialization. As a result, 'max_slots' effectively represents both
values.
This change allows the xHCI driver to respect custom slot limits, reduces
unnecessary memory usage, and removes the obsolete "TODO" comment.
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/20260603091132.1110849-15-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Embed the 'xhci_device_context_array' structure directly within 'xhci_hcd'
instead of allocating it as a separate block. Only the array of device
context addresses is now allocated separately.
Since the device context addresses are no longer part of an array
structure, rename 'dev_context_ptrs' to 'ctx_array' for clearer access
semantics.
Also remove the redundant comment next to the 'ctx_array' allocation;
using dma_alloc_coherent() for 64-bit * N allocations guarantees both
physically contiguous and properly aligned for 64-byte boundaries.
The xHCI section (5.4.6) refers to DCBAAP instead of DCBAA (6.1).
This change does not modify the number of host controller slots but
simplifies memory management and prepares the driver for a variable number
of HC slots in the future.
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/20260603091132.1110849-14-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a timeout between the detection of the debug host connection and
the DbC Run transition to ‘1’. Toggle the DCE bit to re-enable DbC in
order to retry the debug device enumeration process if the DbC run
transition takes too long.
Set the timeout to 2 seconds
See xhci specification section 7.6.4.1 "Debug Capability Initialization"
Also detect cable disconnect during enable and connected state.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260603091132.1110849-12-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function is pointless because usb_submit_urb() initializes all
isoc frame descriptors to -EXDEV and 0 length so that HCDs don't need
to do anything with transfers which were never executed.
Other HCDs rely on this (e.g. EHCI itd_complete()), so we can too.
This gets rid of a potentially dangereous function which could corrupt
memory if we weren't super careful to only call it on isoc URBs.
Also, set status to 0 rather than any random status determined by the
later TD which caused skipping. This status will be ignored anyway.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260603091132.1110849-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function reads USBCMD, clears some bits and writes it back.
Its treatment of the Run bit is weird: the bit is usually written
as 0, as we would expect, but it may also be written as 1 if both
its current value and USBSTS.HCHalted are observed as 1.
Per xHCI 5.4.2, HCHalted is 0 whenever Run is 1, so the above can
only happen due to buggy HW or SW, e.g. concurrent xhci_quiesce()
and xhci_start() execution.
It's unclear why we should treat such cases specially and write
the bit as 1. The logic comes from original PoC implementation
and has never been explained. Just write 0 every time, which
looks like the safer choice when the intent is to stop the xHC.
We could get in trouble if clearing Run causes some very broken
xHC to start running after it was halted, but no such case has
been documented. It seems the logic was just poorly thought out.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260603091132.1110849-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keeping track of free TRBs in a ring by adding and subtracting each time
a enqueue or dequeue pointer is modified has proven to be buggy and
complicated, especially over long periods of time.
The xhci driver has already moved to calculating free TRBs dynamically
based on ring size and the enqueue/dequeue positions.
The DbC path is the last user of 'num_trbs_free'. Rather than maintaining
two separate accounting mechanisms, remove the field entirely and switch
DbC to use xhci_num_trbs_free(). Since 'num_trbs_free' undercounts by one,
and xhci_num_trbs_free() does not, the check for sufficient free TRBs is
adjusted.
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/20260603091132.1110849-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
