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

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

[Andreas Wild]

From: "Maciej W. Rozycki" <macro@orcam.me.uk>

Since commit 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe
failed link retraining") the Target Speed quirk lifts a firmware-imposed
2.5GT/s restriction on any downstream port, without checking whether the
link is up.  Where nothing is plugged in, the retraining that follows can
never complete, so each attempt costs PCIE_LINK_RETRAIN_TIMEOUT_MS.  The
quirk makes two of them -- the initial one and the restore on the error
path -- adding a fixed 2 s to every boot.

On an MSI PRO Z690-A WIFI DDR4 (Intel 600 Series PCH) with one empty x1
slot, running v7.2-rc5:

 0.541 pci 0000:00:1c.0: removing 2.5GT/s downstream link speed restriction
 1.541 pci 0000:00:1c.0: retraining failed
 2.541 pci 0000:00:1c.2: [8086:7aba] type 01 class 0x060400

Where the Link Speed has already been clamped at 2.5GT/s and no link has
been established there is nothing worth doing, which is what the kerneldoc
for the quirk already describes: the restriction is to be lifted where
firmware arranged it "and the port reports its link already being up".
Bail out early in that case, before either the ASM2824 workaround or the
removal of the restriction is considered.

Ports whose link is up are unaffected, and so is the ASM2824 workaround,
which is reached with the Target Link Speed not clamped.

With this applied the quirk returns without touching the port: both
messages are gone, enumeration proceeds from 0000:00:1c.0 to 0000:00:1c.2
in 1 ms rather than 2 s, and the systemd "kernel" boot phase goes from
3.011 s to 1.036 s.

Fixes: 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining")
Cc: stable@vger.kernel.org
Reported-by: Andreas Wild <andiwild@gmail.com>
Closes: https://lore.kernel.org/lkml/20260801092152.5643-1-andiwild@gmail.com/
Tested-by: Andreas Wild <andiwild@gmail.com>
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Andreas Wild <andiwild@gmail.com>
---
v3:
 - Replaced with Maciej's much simpler approach: bail out of the quirk
   entirely when the Target Link Speed is already clamped at 2.5GT/s and no
   link has been established, rather than programming the speed and skipping
   only the retraining.  One function, no new API, no bwctrl changes.
 - Note this leaves the Target Link Speed clamped on such a port, where v2
   left it at the Port's maximum.  A device hot-plugged there later trains at
   2.5GT/s: pcie_wait_for_link_delay() only calls the quirk when
   pcie_wait_for_link_status() fails, so a link that comes up cleanly at
   2.5GT/s never re-runs it.  Flagging in case that matters; the clamp is
   firmware's, so honouring it on an unoccupied Port seems defensible.
 - v2: https://lore.kernel.org/lkml/20260801105441.6506-1-andiwild@gmail.com/
 - v1: https://lore.kernel.org/lkml/20260801092152.5643-1-andiwild@gmail.com/
 drivers/pci/quirks.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f..9e407c4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -108,7 +108,11 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
 
 	pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
 	pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &oldlnkctl2);
-	if (!(lnksta & PCI_EXP_LNKSTA_DLLLA) && pcie_lbms_seen(dev, lnksta)) {
+	if (lnksta & PCI_EXP_LNKSTA_DLLLA) {
+		;
+	} else if (PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2) == PCIE_SPEED_2_5GT) {
+		return ret;
+	} else if (pcie_lbms_seen(dev, lnksta)) {
 		pci_info(dev, "broken device, retraining non-functional downstream link at 2.5GT/s\n");
 		ret = pcie_set_target_speed(dev, PCIE_SPEED_2_5GT, false);
 		if (ret)
-- 
2.55.0

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

[Thorsten Leemhuis]

On 8/1/26 22:11, Andreas Wild wrote:
> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
> 
> Since commit 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe
> failed link retraining") the Target Speed quirk lifts a firmware-imposed
> 2.5GT/s restriction on any downstream port, without checking whether the
> link is up.  Where nothing is plugged in, the retraining that follows can
> never complete, so each attempt costs PCIE_LINK_RETRAIN_TIMEOUT_MS.  The
> quirk makes two of them -- the initial one and the restore on the error
> path -- adding a fixed 2 s to every boot.
> 
> On an MSI PRO Z690-A WIFI DDR4 (Intel 600 Series PCH) with one empty x1
> slot, running v7.2-rc5:
> 
>  0.541 pci 0000:00:1c.0: removing 2.5GT/s downstream link speed restriction
>  1.541 pci 0000:00:1c.0: retraining failed
>  2.541 pci 0000:00:1c.2: [8086:7aba] type 01 class 0x060400

TWIMC, this patch fixes a regression Edward reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=221801

[side note: the report could be more specific, yes -- I wanted to ask
Edward to clarify a few things (like the actual slowdown) before
forwarding it, but it didn't came to that when I noticed this patch and
asked Edward to just check if it helped -- which is did.]

Ciao, Thorsten
> Where the Link Speed has already been clamped at 2.5GT/s and no link has
> been established there is nothing worth doing, which is what the kerneldoc
> for the quirk already describes: the restriction is to be lifted where
> firmware arranged it "and the port reports its link already being up".
> Bail out early in that case, before either the ASM2824 workaround or the
> removal of the restriction is considered.
> 
> Ports whose link is up are unaffected, and so is the ASM2824 workaround,
> which is reached with the Target Link Speed not clamped.
> 
> With this applied the quirk returns without touching the port: both
> messages are gone, enumeration proceeds from 0000:00:1c.0 to 0000:00:1c.2
> in 1 ms rather than 2 s, and the systemd "kernel" boot phase goes from
> 3.011 s to 1.036 s.
> 
> Fixes: 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining")
> Cc: stable@vger.kernel.org
> Reported-by: Andreas Wild <andiwild@gmail.com>
> Closes: https://lore.kernel.org/lkml/20260801092152.5643-1-andiwild@gmail.com/
> Tested-by: Andreas Wild <andiwild@gmail.com>
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> Signed-off-by: Andreas Wild <andiwild@gmail.com>
> ---
> v3:
>  - Replaced with Maciej's much simpler approach: bail out of the quirk
>    entirely when the Target Link Speed is already clamped at 2.5GT/s and no
>    link has been established, rather than programming the speed and skipping
>    only the retraining.  One function, no new API, no bwctrl changes.
>  - Note this leaves the Target Link Speed clamped on such a port, where v2
>    left it at the Port's maximum.  A device hot-plugged there later trains at
>    2.5GT/s: pcie_wait_for_link_delay() only calls the quirk when
>    pcie_wait_for_link_status() fails, so a link that comes up cleanly at
>    2.5GT/s never re-runs it.  Flagging in case that matters; the clamp is
>    firmware's, so honouring it on an unoccupied Port seems defensible.
>  - v2: https://lore.kernel.org/lkml/20260801105441.6506-1-andiwild@gmail.com/
>  - v1: https://lore.kernel.org/lkml/20260801092152.5643-1-andiwild@gmail.com/
>  drivers/pci/quirks.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b09f27f..9e407c4 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -108,7 +108,11 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>  
>  	pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
>  	pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &oldlnkctl2);
> -	if (!(lnksta & PCI_EXP_LNKSTA_DLLLA) && pcie_lbms_seen(dev, lnksta)) {
> +	if (lnksta & PCI_EXP_LNKSTA_DLLLA) {
> +		;
> +	} else if (PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2) == PCIE_SPEED_2_5GT) {
> +		return ret;
> +	} else if (pcie_lbms_seen(dev, lnksta)) {
>  		pci_info(dev, "broken device, retraining non-functional downstream link at 2.5GT/s\n");
>  		ret = pcie_set_target_speed(dev, PCIE_SPEED_2_5GT, false);
>  		if (ret)

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

[Maciej W. Rozycki]

On Mon, 3 Aug 2026, Thorsten Leemhuis wrote:

> > Since commit 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe
> > failed link retraining") the Target Speed quirk lifts a firmware-imposed
> > 2.5GT/s restriction on any downstream port, without checking whether the
> > link is up.  Where nothing is plugged in, the retraining that follows can
> > never complete, so each attempt costs PCIE_LINK_RETRAIN_TIMEOUT_MS.  The
> > quirk makes two of them -- the initial one and the restore on the error
> > path -- adding a fixed 2 s to every boot.
> 
> TWIMC, this patch fixes a regression Edward reported here:
> https://bugzilla.kernel.org/show_bug.cgi?id=221801

 Thank you for the pointer.

 As it happens attempts were made to cc me on that bug, which however went 
nowhere as messages were sent to my long-defunct <macro@linux-mips.org> 
e-mail address, a clear oversight of mine as I went, back in the day, 
through numerous sites to get this updated.

 I have now asked bugzilla admins to help me recover my account.

> [side note: the report could be more specific, yes -- I wanted to ask
> Edward to clarify a few things (like the actual slowdown) before
> forwarding it, but it didn't came to that when I noticed this patch and
> asked Edward to just check if it helped -- which is did.]

 Tested-by tags welcome!

 And thank you for your input overall, really useful and appreciated!

  Maciej

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

[Thorsten Leemhuis]

On 8/4/26 00:07, Maciej W. Rozycki wrote:
> On Mon, 3 Aug 2026, Thorsten Leemhuis wrote:
>>> Since commit 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe
>>> failed link retraining") the Target Speed quirk lifts a firmware-imposed
>>> 2.5GT/s restriction on any downstream port, without checking whether the
>>> link is up.  Where nothing is plugged in, the retraining that follows can
>>> never complete, so each attempt costs PCIE_LINK_RETRAIN_TIMEOUT_MS.  The
>>> quirk makes two of them -- the initial one and the restore on the error
>>> path -- adding a fixed 2 s to every boot.
>>
>> TWIMC, this patch fixes a regression Edward reported here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=221801
> 
>  Thank you for the pointer.

yw
>  As it happens attempts were made to cc me on that bug, which however went 
> nowhere as messages were sent to my long-defunct <macro@linux-mips.org> 
> e-mail address, a clear oversight of mine as I went, back in the day, 
> through numerous sites to get this updated.
> 
>  I have now asked bugzilla admins to help me recover my account.

FWIW, Artem does that and I'm not a fan of it at all -- I think it is
only appropriate when one knows the person occasionally interacts
directly (e.g. not via mail) with bugzilla (and thus I only do it in
those cases).
>> [side note: the report could be more specific, yes -- I wanted to ask
>> Edward to clarify a few things (like the actual slowdown) before
>> forwarding it, but it didn't came to that when I noticed this patch and
>> asked Edward to just check if it helped -- which is did.]
> 
>  Tested-by tags welcome!

FWIW, as I forgot to mention it easlier: Edward is CCed.

@Edward, if you'd like a record of your test result end up in the
history, reply with

 Tested-by: Full Name <email address>

to this thread, just omit the space in the beginning and change it
accordingly.

Ciao, Thorsten

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

[Aoxtj]

Hi,

I'm the one who reported a PCIe/NVMe boot regression on the Proxmox forum:

  
https://forum.proxmox.com/threads/7-0-14-7-kernel-breaks-pci-link-training.185549/

A Proxmox dev pointed me here and asked me to try this patch. I'm not a 
kernel developer and did most of the debugging with AI help, so please 
bear with me.

TL;DR:
- Proxmox Kernel 7.0.14-6 to 7.0.14-8: SK hynix system drive disappears 
during boot.
- Narrowed down to commit 72780f796468 and verified by reverting it.
- 7.0.14-8 + revert 72780f796468: boots reliably.
- 7.0.14-8 + this v3 patch: only boots sometimes; failed boots lose the 
drive the same way.

Machine: ASRock B450M Pro4-F, SK hynix PE4010 NVMe system drive on a 
passive PCIe bifurcation card.

   AMD Renoir PCIe GPP Bridge 0000:00:02.4 [1022:1633]
   -> bus 07 -> SK hynix PE4010 0000:07:00.0 [1c5c:2527]

Initramfs dmesg from a failed v3 boot:

   [    0.555805] pci 0000:00:02.4: [1022:1633] type 01 class 0x060400 
PCIe Root Port
   [    0.555828] pci 0000:00:02.4: PCI bridge to [bus 07]
   [    0.555871] pci 0000:00:02.4: removing 2.5GT/s downstream link 
speed restriction
   [    1.636965] pci 0000:00:02.4: retraining failed

Nothing shows up on bus 07 afterwards, so my system drive is gone.

With the revert instead, the working link reports:

   Root Port 0000:00:02.4:
     LnkCap:  Speed 8GT/s, Width x4
     LnkSta:  Speed 2.5GT/s, Width x2, DLActive+
     LnkCtl2: Target Link Speed: 2.5GT/s, SpeedDis+
     LnkSta2: EqualizationComplete-, EqualizationPhase1/2/3-

   Endpoint 0000:07:00.0:
     LnkCap:  Speed 8GT/s, Width x4
     LnkSta:  Speed 2.5GT/s (downgraded), Width x2 (downgraded)
     LnkCtl2: Target Link Speed: 8GT/s
     LnkSta2: EqualizationComplete-, EqualizationPhase1/2/3-

My guess: this motherboard supports different PCIe generations depending 
on which CPU is installed, and with this CPU the link just can't run at 
the advertised 8GT/s — which would explain why the 8GT/s retrain fails.

Tested on a locally rebuilt Proxmox/Ubuntu 7.0.14-8 backport, not 
mainline. Also replied in kernel Bugzilla #221801:

   https://bugzilla.kernel.org/show_bug.cgi?id=221801

Happy to test a diagnostic patch.

Best regards,
Aoxtj

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

[Andreas Wild]

On Sat, 1 Aug 2026, Aoxtj wrote:

> - 7.0.14-8 + revert 72780f796468: boots reliably.
> - 7.0.14-8 + this v3 patch: only boots sometimes; failed boots lose the
> drive the same way.

Thanks for testing it.  v3 only covers ports with no link at all, so it
does not address your case.

72780f796468 removed two guards at once: the Data Link Layer Link Active
check, and the device ID match against the ASMedia ASM2824.  My
regression comes from losing the first; yours looks like it comes from
losing the second.

v3 only bails out where DLLLA is clear.  Your link is up:

>      LnkSta:  Speed 2.5GT/s, Width x2, DLActive+

so the quirk runs past the v3 early return, lifts the restriction and
retrains at 8GT/s, exactly as it did before.  Reverting works for you
because your AMD Renoir Root Port didn't match the ASM2824 ID list that
used to gate this.

A possible workaround:

If your BIOS lets you pin that slot to Gen1, you could try that.  With
the Root Port advertising only 2.5GT/s the quirk never reaches the
retrain at all: on current mainline it returns at

	speed_cap = pcie_get_speed_cap(dev);
	if (speed_cap <= PCIE_SPEED_2_5GT)
		return ret;

and on the older code your 7.0.14 backport is based on, the
(lnkcap & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB condition is
false, so the restriction is never lifted.

Since the link already runs at 2.5GT/s x2, that should cost you nothing
- it just makes the Root Port advertise what the link can actually do.

Something that is different in your case:

Your Root Port reports

>      LnkCtl2: Target Link Speed: 2.5GT/s, SpeedDis+

where mine reports the same clamp with SpeedDis-.  SpeedDis is
PCI_EXP_LNKCTL2_HASD, and as far as I can tell the quirk never looks at
it; the only user in the tree is pcie-designware.c.  Firmware setting
both the clamp and Hardware Autonomous Speed Disable looks like a
deliberate pin rather than an incidental one.

I am aware that HASD is specified as disabling *hardware autonomous*
speed changes and so does not literally forbid a software-initiated
retrain, so this is just a heuristic about firmware intent.

About the drive disappearing:

The error path is

	err:
		pci_info(dev, "retraining failed\n");
		pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2), true);

which reaches pcie_retrain_link(pdev, use_lt=true), whose last wait is

	rc = pcie_wait_for_link_status(pdev, use_lt, !use_lt);

With use_lt set that waits for the Link Training bit to clear (for
training to stop) and not for DLLLA to come back.  So the restore can
return having never confirmed the link recovered.  Since the quirk runs
from pci_device_add(), before pci_scan_bridge_extend() creates the
subordinate bus, a link that comes up shortly afterwards is never
scanned and the device behind it is simply not there.  That would fit
only booting sometimes better than anything about speed policy does.

I could easily be wrong about this - I am just reading the code, and I
came to the PCI core a few days ago via this one bug.

Since you offered to test a diagnostic, here is one.  It only touches the
err: block, which is identical in mainline and in the 7.0.14 code your
backport is based on, so it should apply to your tree (it applied to
v7.1.5 here with a -2 line offset):

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f..e4fcdfb 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -126,7 +126,32 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
 	return ret;
 err:
 	pci_info(dev, "retraining failed\n");
+	{
+		/* DIAGNOSTIC ONLY -- not for merging */
+		u16 sta = 0, ctl2 = 0;
+
+		pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &sta);
+		pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &ctl2);
+		pci_info(dev, "diag: pre ret=%d DLLLA=%d sta=%#06x ctl2=%#06x\n",
+			 ret, !!(sta & PCI_EXP_LNKSTA_DLLLA), sta, ctl2);
+	}
 	pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2), true);
+	{
+		/* DIAGNOSTIC ONLY -- not for merging */
+		u16 sta = 0, ctl2 = 0;
+		int i;
+
+		for (i = 0; i <= 100; i++) {
+			pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &sta);
+			if (sta & PCI_EXP_LNKSTA_DLLLA)
+				break;
+			msleep(10);
+		}
+		pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &ctl2);
+		pci_info(dev, "diag: post DLLLA=%d after %dms sta=%#06x\n",
+			 !!(sta & PCI_EXP_LNKSTA_DLLLA), i * 10, sta);
+		pci_info(dev, "diag: post ctl2=%#06x\n", ctl2);
+	}
 	return ret;
 }


Expected output:

- "diag: pre" gives the error the retrain returned and whether the
  link was already down at that point.
- "diag: post DLLLA=1 after <n>ms" would mean the link does come back,
  just not before pci_device_add() returns and the bus below is
  scanned.  That would point at the error path needing to wait for
  DLLLA rather than only for the Link Training bit to clear.
- "diag: post DLLLA=0 after 1000ms" would mean the link is genuinely
  down and staying down, which is a different problem and
  probably a worse one.

One caveat: the poll loop waits up to a second in the error path, so it
changes timing.  If the diagnostic build happens to boot reliably where
the plain v3 build did not, that is also worth reporting.

Best regards,
Andreas Wild