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

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

[Stefan Roese]

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, 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@mailbox.org

#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(-)

-- 
2.56.0

[PATCH v2 1/2] PCI/ASPM: Clear ASPM Control on links without common ASPM support

[Stefan Roese]

pcie_aspm_cap_init() returns early when the two ends of a link share
no ASPM state. It then never touches Link Control, so ASPM Control
keeps whatever the device came out of reset with. Per PCIe r7.0, sec
5.4.1.4, the result is undefined when L0s or L1 is enabled although
the other end of the link does not support it.

The Renesas uPD720201 xHCI (1912:0014) resets with LnkCtl 0x0003 (L0s
and L1 enabled), as the Mini Card CEM and M.2 specs ask for. Behind the
CPM Root Port of AMD Versal, which supports no ASPM, it only works
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, it no longer does so. Since commit
1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
pci_configure_rcb() does such a write for every endpoint, ASPM stays
enabled, and the first access to the xHCI BAR runs into completion
timeouts that hang the system.

Clear ASPM Control on every function of such a link, downstream
component first, and only where it is set. Update the saved state as
well, like the other ASPM Control writes in this file do. This matters
for the upstream port, whose state may have been saved before, e.g.
when a device is hot-added: a later pci_restore_state() after an AER or
DPC reset must not enable ASPM again.

Before (lspci -vvv -s 01:00.0):
  LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, LnkDisable- CommClk-

After:
  pci 0000:01:00.0: ASPM: link has no common ASPM support, clearing ASPM Control
  LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk-

Fixes: 1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Stefan Roese <stefan.roese@mailbox.org>
---
Changes in v2:
- Make this the first patch and the actual fix, with Fixes: and stable
  (was patch 2/2 without tags)
- Update the saved state after clearing ASPM Control, so that
  pci_restore_state() does not enable ASPM again on a port whose state
  was saved before (sashiko)
- Cite PCIe r7.0, sec 5.4.1.4, for the undefined state (Bjorn)
- Reword the message to "link has no common ASPM support", which also
  covers links where both ends support different ASPM states
- Explain the Renesas mechanism and the RCB write in the message
---
 drivers/pci/pcie/aspm.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index f8e64971c6c3..8920508c9a83 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -931,6 +931,19 @@ static void pcie_aspm_override_default_link_state(struct pcie_link_state *link)
 	}
 }
 
+static void pcie_aspm_clear_aspmc(struct pci_dev *pdev)
+{
+	u16 lnkctl;
+
+	pcie_capability_read_word(pdev, PCI_EXP_LNKCTL, &lnkctl);
+	if (!(lnkctl & PCI_EXP_LNKCTL_ASPMC))
+		return;
+
+	pci_info(pdev, "ASPM: link has no common ASPM support, clearing ASPM Control\n");
+	pcie_capability_clear_word(pdev, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_ASPMC);
+	pci_update_aspm_saved_state(pdev);
+}
+
 static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 {
 	struct pci_dev *child = link->downstream, *parent = link->pdev;
@@ -947,11 +960,17 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
 
 	/*
 	 * If ASPM not supported, don't mess with the clocks and link,
-	 * bail out now.
+	 * bail out now. A device may still come out of reset with ASPM
+	 * Control set, which the rest of this code never touches for
+	 * such a link. Clear it, downstream component first.
 	 */
 	if (!(parent->aspm_l0s_support && child->aspm_l0s_support) &&
-	    !(parent->aspm_l1_support && child->aspm_l1_support))
+	    !(parent->aspm_l1_support && child->aspm_l1_support)) {
+		list_for_each_entry(fn, &linkbus->devices, bus_list)
+			pcie_aspm_clear_aspmc(fn);
+		pcie_aspm_clear_aspmc(parent);
 		return;
+	}
 
 	/* Configure common clock before checking latencies */
 	pcie_aspm_configure_common_clock(link);
-- 
2.56.0

Re: [PATCH v2 1/2] PCI/ASPM: Clear ASPM Control on links without common ASPM support

[sashiko-bot]

> pcie_aspm_cap_init() returns early when the two ends of a link share
> no ASPM state. It then never touches Link Control, so ASPM Control
> keeps whatever the device came out of reset with. Per PCIe r7.0, sec
> 5.4.1.4, the result is undefined when L0s or L1 is enabled although
> the other end of the link does not support it.
> 
> The Renesas uPD720201 xHCI (1912:0014) resets with LnkCtl 0x0003 (L0s
> and L1 enabled), as the Mini Card CEM and M.2 specs ask for. Behind the
> CPM Root Port of AMD Versal, which supports no ASPM, it only works
> 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, it no longer does so. Since commit
> 1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
> pci_configure_rcb() does such a write for every endpoint, ASPM stays
> enabled, and the first access to the xHCI BAR runs into completion
> [ ... ]
> 
> Fixes: 1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Stefan Roese <stefan.roese@mailbox.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002091029.2225203-1-stefan.roese@mailbox.org?part=1

[PATCH v2 2/2] PCI: Set RCB only when the Root Port has it set

[Stefan Roese]

pci_configure_rcb() read-modify-writes Link Control of every endpoint
at enumeration, also when RCB is clear in the Root Port and there is
nothing to set. Not writing a register that has nothing to change is
justified on its own, but the write-back of the other Link Control bits
also has side effects on some devices: the Renesas uPD720201 xHCI
(1912:0014) comes out of reset with ASPM L0s and L1 enabled and stops
clearing them itself once Link Control has been written. On a link
whose Root Port supports no ASPM, the previous patch clears them, but
it does not run with pcie_aspm=off or CONFIG_PCIEASPM=n. There the
first access to the xHCI BAR runs into completion timeouts that hang
the system.

RCB may only be set in an endpoint if it is set in the Root Port, so
there is no need to ever clear it here; an endpoint with RCB set
below a Root Port without it is a firmware configuration error. Only
set RCB, and only when the Root Port has it set.

Fixes: 1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
Cc: stable@vger.kernel.org
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Stefan Roese <stefan.roese@mailbox.org>
---
Changes in v2:
- Replace "PCI: Write RCB only when it changes" (v1 1/2) with the
  set-only variant suggested by Bjorn: never clear RCB, set it only
  when the Root Port has it set
- Now patch 2/2, still with Fixes: and stable, because with
  pcie_aspm=off or CONFIG_PCIEASPM=n patch 1 never runs and only
  avoiding the Link Control write prevents the hang
---
 drivers/pci/probe.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 721daf5c5184..0d05536216fb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2448,10 +2448,9 @@ static void pci_configure_rcb(struct pci_dev *dev)
 		return;
 
 	pcie_capability_read_word(rp, PCI_EXP_LNKCTL, &rp_lnkctl);
-	pcie_capability_clear_and_set_word(dev, PCI_EXP_LNKCTL,
-					   PCI_EXP_LNKCTL_RCB,
-					   (rp_lnkctl & PCI_EXP_LNKCTL_RCB) ?
-					   PCI_EXP_LNKCTL_RCB : 0);
+	if (rp_lnkctl & PCI_EXP_LNKCTL_RCB)
+		pcie_capability_set_word(dev, PCI_EXP_LNKCTL,
+					 PCI_EXP_LNKCTL_RCB);
 }
 
 static void pci_configure_device(struct pci_dev *dev)
-- 
2.56.0

Re: [PATCH v2 2/2] PCI: Set RCB only when the Root Port has it set

[sashiko-bot]

> pci_configure_rcb() read-modify-writes Link Control of every endpoint
> at enumeration, also when RCB is clear in the Root Port and there is
> nothing to set. Not writing a register that has nothing to change is
> justified on its own, but the write-back of the other Link Control bits
> also has side effects on some devices: the Renesas uPD720201 xHCI
> (1912:0014) comes out of reset with ASPM L0s and L1 enabled and stops
> clearing them itself once Link Control has been written. On a link
> whose Root Port supports no ASPM, the previous patch clears them, but
> it does not run with pcie_aspm=off or CONFIG_PCIEASPM=n. There the
> first access to the xHCI BAR runs into completion timeouts that hang
> the system.
> 
> RCB may only be set in an endpoint if it is set in the Root Port, so
> there is no need to ever clear it here; an endpoint with RCB set
> below a Root Port without it is a firmware configuration error. Only
> set RCB, and only when the Root Port has it set.
> 
> Fixes: 1a6845aaa6de ("PCI: Initialize RCB from pci_configure_device()")
> Cc: stable@vger.kernel.org
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Stefan Roese <stefan.roese@mailbox.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002091029.2225203-1-stefan.roese@mailbox.org?part=2