Re: Pericom PI7C9X2G608 (12d8:2608) missing from ACS quirk — breaks Renesas uPD720202 USB3 cards when IOMMU is on

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Aug 10, 2026 at 08:00:59PM -0500, Max Stevens wrote:
> Hello,
> 
> I'd like to report that the Pericom PI7C9X2G ACS erratum handled by
> pci_fixup_pericom_acs_store_forward() also affects the 6-port variant
> of the switch, PI7C9X2G608GP (12d8:2608), which is not covered by the
> existing quirk (2404/2304/2303, and b404 recently proposed by Nicolas
> Cavallari). On this switch the erratum is severe enough to make an
> entire class of consumer USB 3.0 cards completely non-functional on
> any system with the IOMMU enabled.
> 
> Hardware
> 
> StarTech PEXUSB3S44V-style 4-port USB 3.0 card ("one dedicated channel
> per port", widely sold ~2016 for Oculus Rift sensors). Topology:
> 
> 00:1d.0 Intel Z690 PCH root port 07:00.0 Pericom PI7C9X2G608GP switch
> upstream [12d8:2608] (x4 gen2) 08:01.0 - 08:04.0 switch downstream
> ports [12d8:2608] 09:00.0 - 0c:00.0 4x Renesas uPD720202 xHCI
> [1912:0015] (rev 02)
> 
> System: Alder Lake / Z690, kernel 6.18.43 (Void Linux), VT-d enabled,
> booted with iommu=pt (default domain: passthrough). Firmware for the
> uPD720202s is the correct v2.0.2.6 image (sha256 177560c2...) and
> uploads successfully on every probe.
> 
> Symptom
> 
> With the IOMMU on, the kernel enables ACS on the switch's downstream
> ports (ACSCtl: SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+). The four
> xHCI controllers then probe cleanly, register their buses, upload
> firmware, and report port connect status normally — but any device
> plugged into any port fails enumeration with:
> 
> xhci-pci-renesas 0000:09:00.0: Error while assigning device slot ID:
> Command Aborted xhci-pci-renesas 0000:09:00.0: Max number of devices
> this xHCI host supports is 32. usb usb3-port1: couldn't allocate
> usb_device
> 
> All four controllers fail identically. xhci debugfs portsc shows the
> port stuck at "Connected ... Link:Polling" while the Enable Slot
> command times out. Posted writes from the endpoints still work (MSI-X
> interrupts for port change events are delivered), but the controllers
> appear unable to complete DMA reads (command ring fetch) — consistent
> with the known PI7C9X2G packet-buffering erratum when P2P Request
> Redirect is enabled. No AER/DMAR errors are logged for the failed
> requests.
> 
> Confirmation
> 
> Clearing ACS control on the downstream ports at runtime and rebinding
> the drivers immediately and fully fixes the card:
> 
> for p in 08:01.0 08:02.0 08:03.0 08:04.0; do setpci -s $p
> ECAP_ACS+6.w=0x0000 done
> 
> + unbind/rebind xhci-pci-renesas for each 0x:00.0
> 
> After this, all four controllers enumerate devices normally and the
> card works (tested with HID devices, hubs, and mass storage).
> "pci=disable_acs_redir=pci:12d8:2608" is my current persistent
> workaround.
> 
> Given that the 2G404/2G304/2G303 (and b404) already have the
> store-and-forward fixup, could 12d8:2608 be added as well? I'm happy
> to test a patch, and can provide full lspci -vv dumps, dmesg, or
> register reads from the switch on request. I can't say whether the
> store-and-forward vendor register of the smaller switches exists at
> the same offset on the 2G608, but I'm glad to poke it under
> instruction.
> 
> These cards were sold in large numbers and every Linux report I can
> find about them (Arch, FreeBSD, Proxmox, Unraid forums) describes
> unexplained failures or dropped input events with no root cause
> identified — this quirk gap likely explains most of them.

Can you test the patch below?


diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f7846f..27f7d56c9ac3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6263,6 +6263,10 @@ DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_PERICOM, 0xb404,
 			 pci_fixup_pericom_acs_store_forward);
 DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_PERICOM, 0xb404,
 			 pci_fixup_pericom_acs_store_forward);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_PERICOM, 0x2608,
+			 pci_fixup_pericom_acs_store_forward);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_PERICOM, 0x2608,
+			 pci_fixup_pericom_acs_store_forward);
 
 static void nvidia_ion_ahci_fixup(struct pci_dev *pdev)
 {