Re: [PATCH v3] PCI: Skip Target Speed quirk on clamped ports with no link

[Thomas Stegbauer <thomas.stegbauer@stegbauer.info>]

In-Reply-To: <20260801201244.4421-1-andiwild@gmail.com>
References: <20260801201244.4421-1-andiwild@gmail.com>

Hi,

another data point for the regression from 72780f796468 ("PCI: Always
lift 2.5GT/s restriction in PCIe failed link retraining"), for the case
with a device present, which v3 does not appear to cover.

Hardware: Raspberry Pi 5 (BCM2712, pcie-brcmstb), ASMedia ASM1182e
[1b21:1182] Gen2 packet switch on a dual M.2 carrier, one NVMe SSD
behind each downstream port.

Downstream port 7 (0001:02:07.0) does not train at 5GT/s on this board.
Without the backport (v6.12.75) the quirk clamps it and the link comes
up at Gen1, in use for over a year:

  pci 0001:02:07.0: broken device, retraining non-functional downstream link at 2.5GT/s
  LnkSta:  Speed 2.5GT/s, Width x1, DLActive+
  LnkCtl2: Target Link Speed: 2.5GT/s

With the backport (v6.18.50, also v6.18.39; Raspberry Pi downstream
kernels, pcie-brcmstb identical between both 6.18 versions) the device
is lost:

  [0.518303] pci 0001:02:07.0: broken device, retraining non-functional downstream link at 2.5GT/s
  [0.538795] pci 0001:02:07.0: removing 2.5GT/s downstream link speed restriction
  [1.537936] pci 0001:02:07.0: retraining failed
  LnkSta:  Speed 5GT/s, Width x1, DLActive-, BWMgmt+
  LnkCtl2: Target Link Speed: 5GT/s

Same hardware, firmware and DT; only the kernel differs. Swapping the
SSDs moves the failure with the port, not with the drive.

To be fair, the Gen1 link is marginal: AER on the port shows RxErr
right after clearing, and BadTLP/BadDLLP under load. The replays are
absorbed, though: 8 GiB O_DIRECT read at 222 MB/s, no data errors.

So: the port is not clamped on entry, hence v3's new early return does
not trigger; the first block clamps and the link trains at 2.5GT/s; the
second block then lifts the clamp because LnkCap is 5GT/s; the 5GT/s
retrain fails as the initial training did, and the error path restores
the old 5GT/s target, leaving the link down (and adding ~2 s to boot).

Before 72780f796468 the lift was limited to the ASM2824 with the link
up, which is why this worked. Would it make sense to fall back to the
2.5GT/s clamp when lifting fails, rather than to the original target
speed, at least when the clamp had produced a working link?

Happy to test patches (v6.18.y based on the Raspberry Pi tree is
easiest for me). Downstream report with full logs:
https://github.com/raspberrypi/linux/issues/7635

Thanks,
Thomas S.

p.s. hopefully the mail get properly added, as I hade to add the in-reply and reference to the txt-body of the mail.