u-boot.git/drivers/usb/host, branch next

usb: xhci: fix DMA address corruption in abort_td

2026-01-25T09:40:42+00:00

When aborting a Transfer Descriptor (TD), the xHCI driver updates the
device dequeue pointer by converting the virtual enqueue TRB pointer
into a DMA address.

Previously, the code OR-ed the ring's Dequeue Cycle State (DCS) bit into
the virtual TRB pointer before passing it to xhci_trb_virt_to_dma().
This produced an unaligned virtual address (e.g. ending in 0x...1).

Inside xhci_trb_virt_to_dma(), the offset calculation:

segment_offset = trb - seg->trbs;

operated on this unaligned pointer, resulting in an incorrect TRB index.
In wraparound cases, this caused the bounds check to fail and the
function to return 0.

As a result, a SET_DEQ_PTR command was issued with a DMA address of 0x0,
leading to controller hangs and transfer timeouts, most commonly when
aborting TDs near the end of a ring segment (e.g. index 63).

Fix this by translating the aligned virtual TRB pointer to a DMA address
first, and only then applying the DCS bit to the resulting physical
address.

Reviewed-by: Marek Vasut 
Signed-off-by: ANANDHAKRISHNAN S

arm: Remove remainder of ARCH_ORION5X

2026-01-21T18:05:15+00:00

With commit 5663b137e682 ("arm: Remove edminiv2 board") the last
ARCH_ORION5X platform was removed. Remove the rest of the architecture
code which is now unused.

Reviewed-by: Tony Dinh 
Signed-off-by: Tom Rini

usb: xhci-dwc3: Add "apple,t8103-dwc3" compatible

2026-01-16T14:03:51+00:00

The Linux support for dwc3 on Apple silicon SoCs switched to using a
apple specific glue driver [1] that uses it own compatible string. The
glue driver handles platform specific requirements on the interaction
between dwc3 and the USB2/USB3 PHY and reset-controller for USB role
switches and plug events.
To keep USB working as before when the nodes still carried "snps,dwc3"
as compatible add "apple,t8103-dwc3" to the of match table. Eventually
it is probably advisable to add a dwc3-apple glue driver and write code
for the currently empty Apple Type-C PHY driver in phy-apple-atc.c.

Link: https://lore.kernel.org/asahi/20251015-b4-aplpe-dwc3-v2-0-cbd65a2d511a@kernel.org/ [1]
Reviewed-by: Neal Gompa 
Reviewed-by: Mark Kettenis 
Reviewed-by: Marek Vasut 
Signed-off-by: Janne Grunau

Merge patch series "Enable / require DEVRES for devm_.alloc usage outside xPL"

2026-01-09T16:19:57+00:00

Tom Rini  says:

As seen by a number of patches fixing memory leaks, U-Boot has a problem
with developer expectations around devm_kmalloc and friends. Namely,
whereas in Linux these memory allocations will be freed automatically in
most cases, in U-Boot this is only true if DEVRES is enabled. Now,
intentionally, in xPL phases, we do not (and do not offer as an option)
enabling DEVRES. However in full U-Boot this is left either to the user,
or some drivers have select'd DEVRES on their own. This inconsistency is
a problem. This series goes and deals with two small issues that were
shown by having all drivers that use devm_.alloc to allocate memory also
select DEVRES and then we make DEVRES no longer be a prompted option and
instead select'd as needed. We do not make this unconditional as it
would result in growing the resulting binary on the many platforms which
have no users of the devm_.alloc family of functions.

Link: https://lore.kernel.org/r/20251227223833.3019311-1-trini@konsulko.com

dm: core: Default to using DEVRES outside of xPL

2026-01-09T15:08:14+00:00

The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).

This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.

Reviewed-by: Michael Trimarchi 
Signed-off-by: Tom Rini

usb: xhci: avoid noisy 'Starting the controller' message.

2026-01-08T14:12:59+00:00

We should avoid overwhelming users with non-essential messages.

The message 'Starting the controller' is not written for EHCI.
We should not write it for XHCI either.

Adjust the Python test accordingly.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Mattijs Korpershoek

usb/xhci: avoid noisy 'Register NbrPorts' message

2025-11-27T18:41:03+00:00

We should avoid overwhelming users with non-essential messages.

'Register NbrPorts' is a debug message for EHCI. Do the same for XHCI.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Marek Vasut

usb: USB_EHCI_PCI depends on PCI

2025-11-27T18:14:09+00:00

CONFIG_USB_EHCI_PCI cannot work without CONFIG_PCI.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Marek Vasut

usb: host: xhci: Make U_BOOT_DRIVER entries unique

2025-11-12T21:13:03+00:00

All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.

Signed-off-by: Tom Rini 
Reviewed-by: Peter Robinson

usb: ehci-mx6: Extend support to i.MX91, i.MX93, i.MX94, and i.MX95

2025-11-04T15:39:45+00:00

Since the EHCI USB driver is shared across i.MX91, i.MX93, i.MX94, and
i.MX95, the condition check is updated to use IMX9.

Signed-off-by: Alice Guo 
Reviewed-by: Marek Vasut