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

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc Tim]

On Tue, Aug 11, 2026 at 04:28:37PM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 11, 2026 at 05:57:33AM -0500, Max Stevens wrote:
> > Hi Bjorn,
> > 
> > Thanks for the quick patch. I tested its effect on my PI7C9X2G608GP
> > (12d8:2608) by replicating what pci_fixup_pericom_acs_store_forward()
> > does, using setpci at runtime (I have not built a patched kernel —
> > happy to do that too if you want a test of the actual binary).
> > 
> > Findings on the 2G608:
> > 
> > The mode register exists at the same offset as on the smaller
> > switches: upstream port config 0x74. Value on my system before any
> > test: 0x0102 (store-forward bit clear).
> > With ACS on all four downstream ports set to what the kernel normally
> > enables here (ACSCtl = SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+),
> > and 0x74 bit 0 CLEAR, device enumeration on the downstream xHCI
> > controllers fails: [43069.603242] xhci-pci-renesas 0000:0c:00.0: Error
> > while assigning device slot ID: Command Aborted [43069.603270] usb
> > usb9-port1: couldn't allocate usb_device
> > Setting 0x74 to 0x0103 (bit 0, store-forward) with ACS unchanged, then
> > rebinding the xHCI drivers: the same device on the same port
> > enumerates immediately and works fully: [43071.971147] usb 9-1: new
> > full-speed USB device number 2 using xhci-pci-renesas [43072.132176]
> > usb 9-1: Product: Azeron Keypad [43072.218656] hid-generic
> > 0003:16D0:113C.0017: input,hidraw12: USB HID v1.11 Keyboard [Azeron
> > LTD Azeron Keypad] on usb-0000:0c:00.0-1/input1
> > I toggled the bit back and forth across several driver rebinds. Every
> > "Command Aborted" failure I have logged (both today and across earlier
> > debugging) occurred with the bit clear; none with it set.
> > 
> > One honest nuance: with the bit clear the failure is not 100% — I saw
> > one enumeration attempt start successfully during a bit-clear window.
> > That intermittency is consistent with the load-dependent packet
> > buffering behaviour described in Nathan's original erratum writeup,
> > and with this card family's long history of "sometimes almost works"
> > reports on various forums.
> 
> If it's an improvement, I think it's worth applying even if it's not a
> 100% fix.
> 
> > So on this hardware the store-forward workaround behaves exactly as it
> > does on the already-quirked siblings, and the patch looks correct to
> > me.
> > 
> > Tested-by: Maximo Paulino Thinker.Healer@gmail.com
> 
> Thanks for doing this.  I'll queue up the patch below for v7.3 without
> your explicit tested-by because quirks run at different times than
> setpci, and the timing/ordering is often important.

Actually, I take that back because the same patch is already queued up
from Tim Harvey:

  https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=virtualization&id=062fb7f816439da6bf3860386889343482a66bd4