VL805 (1106:3483) PCIe USB cards fail with `xhci_hcd: can't setup: -12` on Pi 5 since the 36-bit DMA cap

[OnlineDynamic]

Describe the bug

Commit fe7892d ("usb: xhci-pci: Limit VIA VL805 DMA addressing to 36
bits", a backport of mainline 1fc50f1) makes every VL805-based PCIe USB
card unusable in the Raspberry Pi 5's external PCIe slot.

The commit clamps the VL805 to a 36-bit DMA mask because the chip "fails to
handle DMA addresses at or above 0x1000000000". On BCM2712, that address is
exactly where the inbound window starts:

brcm-pcie 1000110000.pcie:   IB MEM 0x0000000000..0x0fffffffff -> 0x1000000000

All system RAM is presented to devices on that port at bus addresses
0x1000000000 and above. A 36-bit mask tops out at 0xfffffffff, one bit short,
so the intersection of "what the device may address" and "where RAM actually
is" is empty. dma_set_mask() still succeeds (36 is a legal mask, so the
driver gets no signal), and the failure surfaces later as an allocation failure
in xhci_mem_init():

pci 0001:01:00.0: [1106:3483] type 00 class 0x0c0330 PCIe Endpoint
pci 0001:01:00.0: ASPM: VL805 fixup applied
xhci_hcd 0001:01:00.0: xHCI Host Controller
xhci_hcd 0001:01:00.0: new USB bus registered, assigned bus number 1
xhci_hcd 0001:01:00.0: can't setup: -12
xhci_hcd 0001:01:00.0: USB bus 1 deregistered
xhci_hcd 0001:01:00.0: init 0001:01:00.0 fail, -12
xhci_hcd 0001:01:00.0: probe with driver xhci_hcd failed with error -12

The PCIe link trains and the card enumerates correctly — only the DMA
allocation fails. The card is then dead: no USB bus, and nothing behind it
exists.

This affects rpi-6.12.y and rpi-6.18.y (both carry the commit). rpi-6.15.y,
rpi-6.16.y and rpi-6.17.y do not, and rpi-6.6.y predates it.

Note the slot has no IOMMU (/proc/device-tree/axi/pcie@1000110000 has no
iommus or iommu-map), so there's nothing to remap around it. The RP1 port
does carry an extra low window, but that maps RP1's own register space rather
than RAM, and the external slot has no low window at all.

Steps to reproduce the behaviour

1. Raspberry Pi 5, PCIe slot enabled in config.txt (dtparam=pciex1_gen=2).
2. Fit any VL805-based PCIe USB card. Reported here with a Waveshare "PCIe TO
   4-CH Gigabit ETH Board (B)", which is a VL805 bridge feeding four RTL8153
   USB Ethernet controllers, but this should reproduce with any VL805 card.
3. Boot a kernel containing fe7892d (6.12.y or 6.18.y).
4. dmesg | grep xhci shows can't setup: -12; lsusb shows only the Pi's
   own root hubs.

The same card works on the same Pi 5 under a 6.6 kernel, and the reporter also
reports it working on the current stock Raspberry Pi OS 64-bit image (I have
not confirmed which kernel version that image ships, but the release images
lag the next branch, so an unaffected kernel is the likely explanation).

Device (s)

Raspberry Pi 5

System

• OS: Raspberry Pi OS Trixie based (Falcon Player 10, v2026-08 64-bit image)
• Kernel: Linux 6.18.45-v8+ #1998 SMP PREEMPT Fri Aug 21 10:57:50 BST 2026 aarch64
• Machine model: Raspberry Pi 5 Model B Rev 1.0
• Kernel command line (firmware defaults, unmodified):
  reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=32 numa=fake=8 system_heap.max_order=0 iommu_dma_numa_policy=interleave ...

I do not own this card myself — the logs come from a Falcon Player user's bug
report, FalconChristmas/fpp#2863. Happy to relay
anything further you want captured from that machine.

Logs

brcm-pcie 1000110000.pcie: host bridge /axi/pcie@1000110000 ranges:
brcm-pcie 1000110000.pcie:      MEM 0x1b80000000..0x1bffffffff -> 0x0080000000
brcm-pcie 1000110000.pcie:      MEM 0x1800000000..0x1b7fffffff -> 0x0400000000
brcm-pcie 1000110000.pcie:   IB MEM 0x0000000000..0x0fffffffff -> 0x1000000000
brcm-pcie 1000110000.pcie:   IB MEM 0x1000131000..0x1000131fff -> 0xfffffff000
brcm-pcie 1000110000.pcie: PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [bus 00-ff]
pci_bus 0001:00: root bus resource [mem 0x1b80000000-0x1bffffffff] (bus address [0x80000000-0xffffffff])
pci_bus 0001:00: root bus resource [mem 0x1800000000-0x1b7fffffff pref] (bus address [0x400000000-0x77fffffff])
pci 0001:00:00.0: [14e4:2712] type 01 class 0x060400 PCIe Root Port
pci 0001:00:00.0: PCI bridge to [bus 00]
pci 0001:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
pci 0001:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
pci 0001:00:00.0: PME# supported from D0 D3hot
pci 0001:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
brcm-pcie 1000110000.pcie: clkreq-mode set to safe
brcm-pcie 1000110000.pcie: link up, 5.0 GT/s PCIe x1 (!SSC)
pci 0001:01:00.0: [1106:3483] type 00 class 0x0c0330 PCIe Endpoint
pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x00000fff 64bit]
pci 0001:01:00.0: ASPM: VL805 fixup applied
pci 0001:01:00.0: PME# supported from D0 D3cold
pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
pci 0001:00:00.0: bridge window [mem 0x1b80000000-0x1b800fffff]: assigned
pci 0001:01:00.0: BAR 0 [mem 0x1b80000000-0x1b80000fff 64bit]: assigned
pci 0001:00:00.0: PCI bridge to [bus 01]
pci 0001:00:00.0:   bridge window [mem 0x1b80000000-0x1b800fffff]
pci_bus 0001:00: resource 4 [mem 0x1b80000000-0x1bffffffff]
pci_bus 0001:00: resource 5 [mem 0x1800000000-0x1b7fffffff pref]
pci_bus 0001:01: resource 1 [mem 0x1b80000000-0x1b800fffff]
pci 0001:00:00.0: Max Payload Size set to  256/ 512 (was  128), Max Read Rq  512
pci 0001:01:00.0: Max Payload Size set to  256/ 256 (was  128), Max Read Rq  512
pcieport 0001:00:00.0: enabling device (0000 -> 0002)
pcieport 0001:00:00.0: PME: Signaling with IRQ 37
pcieport 0001:00:00.0: AER: enabled with IRQ 37
pci 0001:01:00.0: enabling device (0000 -> 0002)
xhci_hcd 0001:01:00.0: xHCI Host Controller
xhci_hcd 0001:01:00.0: new USB bus registered, assigned bus number 1
xhci_hcd 0001:01:00.0: can't setup: -12
xhci_hcd 0001:01:00.0: USB bus 1 deregistered
xhci_hcd 0001:01:00.0: init 0001:01:00.0 fail, -12
xhci_hcd 0001:01:00.0: probe with driver xhci_hcd failed with error -12

(syslog host/timestamp prefixes stripped; kernel text verbatim)

lsusb -t on the same boot — only the Pi's own two controllers, no VL805 bus:

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M

dma-ranges for the slot, read from one of my own Pi 5s on the same kernel.
It comes from the base DTB rather than from RAM size, and the reporter's
IB MEM lines above match it exactly:

/proc/device-tree/axi/pcie@1000110000
    status         : okay
    dma-ranges = <0x3000000 0x10 0x00 0x00 0x00 0x10 0x00 ...>;
                              ^^^^ bus address 0x10_0000_0000

Additional context

The workaround is confirmed. Adding dtoverlay=pcie-32bit-dma-pi5 to
config.txt — which repoints the slot's dma-ranges to a 2 GB window at bus
address 0 — makes the card work completely. On the same kernel
(6.18.45-v8+), with nothing else changed:

$ lsusb
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

$ ip -br link
eth1   UP             00:e0:4c:68:03:fd <BROADCAST,MULTICAST,UP,LOWER_UP>
eth2   DOWN           00:e0:4c:68:04:19 <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3   DOWN           00:e0:4c:68:04:15 <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth4   DOWN           00:e0:4c:68:04:14 <NO-CARRIER,BROADCAST,MULTICAST,UP>

[    4.505074] r8152-cfgselector 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[    4.689066] r8152-cfgselector 2-2: reset SuperSpeed USB device number 3 using xhci_hcd
[    4.877067] r8152-cfgselector 2-3: reset SuperSpeed USB device number 4 using xhci_hcd
[    5.069058] r8152-cfgselector 2-4: reset SuperSpeed USB device number 5 using xhci_hcd

(eth2-4 show NO-CARRIER only because nothing is plugged into them.)

Since the kernel is identical across both runs and the inbound window is the
only variable, that isolates the mechanism: the 36-bit clamp against a window
that starts at 0x1000000000 is what breaks it, and moving the window down fixes
it. It is not a driver bug beyond the mask.

Possible directions, in rough order of how targeted they are — I have no
preference and don't know which fits your tree best:

1. Only apply the clamp when it is satisfiable. The quirk currently narrows
   the mask unconditionally; it could compare against what the host bridge can
   actually reach (dev->bus_dma_limit / the resolved dma-ranges) and leave
   the mask alone — or fail loudly — when the clamp would leave nothing
   addressable. This keeps the fix working on the platforms it was written for
   without silently bricking the device elsewhere.

2. Give BCM2712's pcie1 a low inbound window by default, as the existing
   pcie-32bit-dma-pi5 overlay does. That fixes every sub-37-bit device on the
   slot rather than just this one, at the cost of bounce buffers for everybody.

3. At minimum, have the VL805 quirk note the incompatibility, so the failure
   isn't a bare -12.

There's a related report of an MT7925e failing the same way on the same slot
(#7046), which suggests any device that ends up with a sub-37-bit mask hits
this, and that a generic answer may be worth more than a per-device one.

Downstream report with the original logs, for reference:
FalconChristmas/fpp#2863

[pelwell]

#7611 is a simple patch that raises the limit one notch to 37 bits. I've been able to verify that a VL805 on a PCIe card comes up and generates interrupts.

If you wait 25 minutes you should be able to install a trial build of a kernel with this patch - sudo rpi-update pulls/7611, after first reading the caveats..