[PATCH 0/2] PCI: Fix Renesas uPD720201 hang after the RCB Link Control write

[Stefan Roese <stefan.roese@mailbox.org>]

Since commit 1a6845aaa6de ("PCI: Initialize RCB from
pci_configure_device()"), which went into v6.18.14 as dbe723b480e4, a
Renesas uPD720201 xHCI (1912:0014) behind the CPM Root Port of an AMD
Versal SoC hangs the system on every boot. The first access to the xHCI
BAR after the firmware download runs into PCIe completion timeouts.

The chip comes out of reset with LnkCtl 0x0003 (ASPM L0s and L1
enabled), although the Root Port supports no ASPM. pcie_aspm_cap_init()
returns early for such a link and never clears these bits. This went
unnoticed so far because the chip clears ASPM Control itself during the
firmware download by xhci-pci-renesas. Once the host has written Link
Control, even with the unchanged value, the chip no longer does so, and
ASPM stays enabled on a link that cannot support it.
pci_configure_rcb() does exactly such a write: it read-modify-writes
Link Control of every endpoint at enumeration, even when RCB does not
change.

What was checked on the board:

- Bisecting v6.18.10..v6.18.40 ends at dbe723b480e4.
- v6.18.40 with that commit reverted: good.
- v6.18.10, which does not have it, booted with xhci_pci_renesas
  blacklisted, then a single "setpci CAP_EXP+0x10.w=0003" (the
  unchanged value) before loading the driver: bad. Without the setpci:
  good.

Patch 1 writes RCB only when it changes. On this board RCB is 0 on both
ends, so Link Control is no longer written, and this alone fixes the
hang. It is the minimal fix and marked for stable.

Patch 2 closes the underlying gap: on a link without common ASPM
support, clear ASPM Control where a device has it set. This does not
depend on patch 1 and also covers any other Link Control write that
might come before the driver.

Testing: both patches were tested on v6.18.40 (AMD linux-xlnx) on the
Versal board: USB comes up without completion timeouts in 3 of 3 cold
boots, and lspci shows "ASPM Disabled" for the xHCI. On pci/next the
only change is that patch 2 uses the existing "fn" iterator. The series
builds without warnings (W=1, arm64 and x86_64 defconfig), but I could
not boot test it on pci/next, as this board does not run a mainline
kernel.

Similar reports with this chip and ASPM, possibly related:
- Qualcomm RB3Gen2 needs pcie_aspm=off: https://lkml.iu.edu/2603.3/02364.html
- RPi CM5 "HC died": https://github.com/raspberrypi/linux/issues/6849

#regzbot introduced: 1a6845aaa6de

Stefan Roese (2):
  PCI: Write RCB only when it changes
  PCI/ASPM: Clear ASPM Control on links without common ASPM support

 drivers/pci/pcie/aspm.c | 22 ++++++++++++++++++++--
 drivers/pci/probe.c     | 17 ++++++++++++-----
 2 files changed, 32 insertions(+), 7 deletions(-)

-- 
2.56.0