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

[Thorsten Leemhuis]

On 10/2/26 11:10, Stefan Roese wrote:
> 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.

Is this regression fix still in the "to review" list of anyone, or did
it fell through the cracks? Or was this solved meanwhile and I just
missed it?

Ciao, Thorsten
> 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, which leaves
> the link in a state that PCIe r7.0, sec 5.4.1.4, calls undefined. 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. pci_configure_rcb() does exactly such a write for every endpoint.
> 
> Patch 1 fixes the ASPM state: on a link without common ASPM support,
> clear ASPM Control where a device has it set, and update the saved
> state.
> 
> Patch 2 is Bjorn's set-only RCB change. It also avoids the Link Control
> write on this board, which matters with pcie_aspm=off or
> CONFIG_PCIEASPM=n, where patch 1 never runs.
> 
> Testing on the Versal board, v6.18.40 (AMD linux-xlnx) with the patches
> backported, 3 cold boots each:
> 
> - patch 1 alone: good, "clearing ASPM Control" for the xHCI
> - patches 1 and 2: good
> - patch 2 alone, pcie_aspm=off: good, the chip clears ASPM Control
>   itself again
> - patch 1 alone, pcie_aspm=off: bad, completion timeouts
> 
> On pci/next the series builds without warnings (W=1, arm64 and x86_64
> defconfig). I could not boot test it on pci/next, as this board does
> not run a mainline kernel.
> 
> Changes in v2:
> - Make the aspm.c change patch 1 and the actual fix (Bjorn)
> - Update the saved state after clearing ASPM Control (sashiko)
> - Reword the clearing message to "link has no common ASPM support"
> - Cite PCIe r7.0, sec 5.4.1.4, in patch 1 (Bjorn)
> - Replace "write RCB only when it changes" with set-only RCB, now
>   with Fixes: and stable because of the pcie_aspm=off and
>   CONFIG_PCIEASPM=n cases (Bjorn)
> 
> 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
> 
> v1: https://lore.kernel.org/r/20260930144650.3701516-1-stefan.roese@xxxxxxxxxxx
> 
> #regzbot introduced: 1a6845aaa6de
> 
> Stefan Roese (2):
>   PCI/ASPM: Clear ASPM Control on links without common ASPM support
>   PCI: Set RCB only when the Root Port has it set
> 
>  drivers/pci/pcie/aspm.c | 23 +++++++++++++++++++++--
>  drivers/pci/probe.c     |  7 +++----
>  2 files changed, 24 insertions(+), 6 deletions(-)
>