[PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

Hi,

 I've figured out that backporting will be less intrusive if an update to 
use `->supported_speeds' is posted as a separate follow-up change.  So it 
is now 2/3 in this series, after 1/3 comprising the original patch, only 
trivially updated.  Then 3/3 moves the maximum link speed determination 
earlier on for an early exit in the PCIE_SPEED_2_5GT case; maybe unlikely, 
but essentially free now, now that we retrieve the speed anyway, and makes 
code a little simpler yet.

 Please let me know if you'd prefer me to fold 2/3 into 1/3 after all.

 Previous iterations:

- v1 at: <https://lore.kernel.org/r/alpine.DEB.2.21.2511290245460.36486@angie.orcam.me.uk/>.

  Maciej

[PATCH v2 1/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

Discard Vendor:Device ID matching in the PCIe failed link retraining 
quirk and ignore the link status for the removal of the 2.5GT/s speed 
clamp, whether applied by the quirk itself or the firmware earlier on.  
Revert to the original target link speed if this final link retraining 
has failed.

This is so that link training noise in hot-plug scenarios does not make 
a link remain clamped to the 2.5GT/s speed where an event race has led 
the quirk to apply the speed clamp for one device, only to leave it in 
place for a subsequent device to be plugged in.

Refer to the Link Capabilities register directly for the maximum link 
speed determination so as to streamline backporting.

Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Cc: <stable@vger.kernel.org> # v6.5+
---
Changes from v1:

- Remove a leftover empty line (out of an overlong line confusion).

- Justify the choice to use the Link Capabilities register.
---
 drivers/pci/quirks.c |   51 ++++++++++++++++++---------------------------------
 1 file changed, 18 insertions(+), 33 deletions(-)

linux-pcie-failed-link-retrain-unclamp-always.diff
Index: linux-macro/drivers/pci/quirks.c
===================================================================
--- linux-macro.orig/drivers/pci/quirks.c
+++ linux-macro/drivers/pci/quirks.c
@@ -79,11 +79,10 @@ static bool pcie_lbms_seen(struct pci_de
  * Restrict the speed to 2.5GT/s then with the Target Link Speed field,
  * request a retrain and check the result.
  *
- * If this turns out successful and we know by the Vendor:Device ID it is
- * safe to do so, then lift the restriction, letting the devices negotiate
- * a higher speed.  Also check for a similar 2.5GT/s speed restriction the
- * firmware may have already arranged and lift it with ports that already
- * report their data link being up.
+ * If this turns out successful, or where a 2.5GT/s speed restriction has
+ * been previously arranged by the firmware and the port reports its link
+ * already being up, lift the restriction, in a hope it is safe to do so,
+ * letting the devices negotiate a higher speed.
  *
  * Otherwise revert the speed to the original setting and request a retrain
  * again to remove any residual state, ignoring the result as it's supposed
@@ -94,52 +93,38 @@ static bool pcie_lbms_seen(struct pci_de
  */
 int pcie_failed_link_retrain(struct pci_dev *dev)
 {
-	static const struct pci_device_id ids[] = {
-		{ PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
-		{}
-	};
-	u16 lnksta, lnkctl2;
+	u16 lnksta, lnkctl2, oldlnkctl2;
 	int ret = -ENOTTY;
+	u32 lnkcap;
 
 	if (!pci_is_pcie(dev) || !pcie_downstream_port(dev) ||
 	    !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting)
 		return ret;
 
 	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)) {
-		u16 oldlnkctl2;
-
 		pci_info(dev, "broken device, retraining non-functional downstream link at 2.5GT/s\n");
-
-		pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &oldlnkctl2);
 		ret = pcie_set_target_speed(dev, PCIE_SPEED_2_5GT, false);
-		if (ret) {
-			pci_info(dev, "retraining failed\n");
-			pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2),
-					      true);
-			return ret;
-		}
-
-		pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
+		if (ret)
+			goto err;
 	}
 
 	pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2);
-
-	if ((lnksta & PCI_EXP_LNKSTA_DLLLA) &&
-	    (lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT &&
-	    pci_match_id(ids, dev)) {
-		u32 lnkcap;
-
+	pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
+	if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT &&
+	    (lnkcap & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
 		pci_info(dev, "removing 2.5GT/s downstream link speed restriction\n");
-		pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
 		ret = pcie_set_target_speed(dev, PCIE_LNKCAP_SLS2SPEED(lnkcap), false);
-		if (ret) {
-			pci_info(dev, "retraining failed\n");
-			return ret;
-		}
+		if (ret)
+			goto err;
 	}
 
 	return ret;
+err:
+	pci_info(dev, "retraining failed\n");
+	pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2), true);
+	return ret;
 }
 
 static ktime_t fixup_debug_start(struct pci_dev *dev,

Re: [External] : [PATCH v2 1/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[ALOK TIWARI]

On 12/9/2025 12:54 AM, Maciej W. Rozycki wrote:
> Discard Vendor:Device ID matching in the PCIe failed link retraining
> quirk and ignore the link status for the removal of the 2.5GT/s speed
> clamp, whether applied by the quirk itself or the firmware earlier on.
> Revert to the original target link speed if this final link retraining
> has failed.
> 
> This is so that link training noise in hot-plug scenarios does not make
> a link remain clamped to the 2.5GT/s speed where an event race has led
> the quirk to apply the speed clamp for one device, only to leave it in
> place for a subsequent device to be plugged in.
> 
> Refer to the Link Capabilities register directly for the maximum link
> speed determination so as to streamline backporting.
> 
> Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
> Tested-by: Alok Tiwari<alok.a.tiwari@oracle.com>
> Signed-off-by: Maciej W. Rozycki<macro@orcam.me.uk>
> Cc:<stable@vger.kernel.org> # v6.5+

Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com>

Tested with LTS 6.18.

Thanks,
Alok

[PATCH v2 2/3] PCI: Use pcie_get_speed_cap() in PCIe failed link retraining

[Maciej W. Rozycki]

Rewrite a check for the maximum link speed in the Link Capabilities 
register in terms of pcie_get_speed_cap().  No functional change.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
 drivers/pci/quirks.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

linux-pcie-failed-link-retrain-get-speed-cap.diff
Index: linux-macro/drivers/pci/quirks.c
===================================================================
--- linux-macro.orig/drivers/pci/quirks.c
+++ linux-macro/drivers/pci/quirks.c
@@ -94,8 +94,8 @@ static bool pcie_lbms_seen(struct pci_de
 int pcie_failed_link_retrain(struct pci_dev *dev)
 {
 	u16 lnksta, lnkctl2, oldlnkctl2;
+	enum pci_bus_speed speed_cap;
 	int ret = -ENOTTY;
-	u32 lnkcap;
 
 	if (!pci_is_pcie(dev) || !pcie_downstream_port(dev) ||
 	    !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting)
@@ -110,12 +110,12 @@ int pcie_failed_link_retrain(struct pci_
 			goto err;
 	}
 
+	speed_cap = pcie_get_speed_cap(dev);
 	pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2);
-	pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
 	if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT &&
-	    (lnkcap & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
+	    speed_cap > PCIE_SPEED_2_5GT) {
 		pci_info(dev, "removing 2.5GT/s downstream link speed restriction\n");
-		ret = pcie_set_target_speed(dev, PCIE_LNKCAP_SLS2SPEED(lnkcap), false);
+		ret = pcie_set_target_speed(dev, speed_cap, false);
 		if (ret)
 			goto err;
 	}

Re: [External] : [PATCH v2 2/3] PCI: Use pcie_get_speed_cap() in PCIe failed link retraining

[ALOK TIWARI]

On 12/9/2025 12:54 AM, Maciej W. Rozycki wrote:
> Rewrite a check for the maximum link speed in the Link Capabilities
> register in terms of pcie_get_speed_cap().  No functional change.
> 
> Signed-off-by: Maciej W. Rozycki<macro@orcam.me.uk>
> ---
>   drivers/pci/quirks.c |    8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)

Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com>

Tested with LTS 6.18.

Thanks,
Alok

[PATCH v2 3/3] PCI: Bail out early for 2.5GT/s devices in PCIe failed link retraining

[Maciej W. Rozycki]

There's no point in retraining a failed 2.5GT/s device at 2.5GT/s, so 
just don't and return early.  While such devices might be unlikely to 
implement Link Active reporting, we need to retrieve the maximum link 
speed and use it in a conditional later on anyway, so the early check 
comes for free.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
 drivers/pci/quirks.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

linux-pcie-failed-link-retrain-speed-cap-early.diff
Index: linux-macro/drivers/pci/quirks.c
===================================================================
--- linux-macro.orig/drivers/pci/quirks.c
+++ linux-macro/drivers/pci/quirks.c
@@ -101,6 +101,10 @@ int pcie_failed_link_retrain(struct pci_
 	    !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting)
 		return ret;
 
+	speed_cap = pcie_get_speed_cap(dev);
+	if (speed_cap <= PCIE_SPEED_2_5GT)
+		return ret;
+
 	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)) {
@@ -110,10 +114,8 @@ int pcie_failed_link_retrain(struct pci_
 			goto err;
 	}
 
-	speed_cap = pcie_get_speed_cap(dev);
 	pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2);
-	if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT &&
-	    speed_cap > PCIE_SPEED_2_5GT) {
+	if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT) {
 		pci_info(dev, "removing 2.5GT/s downstream link speed restriction\n");
 		ret = pcie_set_target_speed(dev, speed_cap, false);
 		if (ret)

Re: [External] : [PATCH v2 3/3] PCI: Bail out early for 2.5GT/s devices in PCIe failed link retraining

[ALOK TIWARI]

On 12/9/2025 12:54 AM, Maciej W. Rozycki wrote:
> There's no point in retraining a failed 2.5GT/s device at 2.5GT/s, so
> just don't and return early.  While such devices might be unlikely to
> implement Link Active reporting, we need to retrieve the maximum link
> speed and use it in a conditional later on anyway, so the early check
> comes for free.
> 
> Signed-off-by: Maciej W. Rozycki<macro@orcam.me.uk>
> ---
>   drivers/pci/quirks.c |    8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)


Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com>

Tested with LTS 6.18.

Thanks,
Alok

[PING][PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

On Mon, 8 Dec 2025, Maciej W. Rozycki wrote:

>  I've figured out that backporting will be less intrusive if an update to 
> use `->supported_speeds' is posted as a separate follow-up change.  So it 
> is now 2/3 in this series, after 1/3 comprising the original patch, only 
> trivially updated.  Then 3/3 moves the maximum link speed determination 
> earlier on for an early exit in the PCIE_SPEED_2_5GT case; maybe unlikely, 
> but essentially free now, now that we retrieve the speed anyway, and makes 
> code a little simpler yet.

 Ping for: 
<https://lore.kernel.org/r/alpine.DEB.2.21.2512072345220.49654@angie.orcam.me.uk/>.  
Re-verified with 6.19.0-rc7.

  Maciej

Re: [PING][PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[ALOK TIWARI]

On 2/4/2026 10:42 PM, Maciej W. Rozycki wrote:
> On Mon, 8 Dec 2025, Maciej W. Rozycki wrote:
> 
>>   I've figured out that backporting will be less intrusive if an update to
>> use `->supported_speeds' is posted as a separate follow-up change.  So it
>> is now 2/3 in this series, after 1/3 comprising the original patch, only
>> trivially updated.  Then 3/3 moves the maximum link speed determination
>> earlier on for an early exit in the PCIE_SPEED_2_5GT case; maybe unlikely,
>> but essentially free now, now that we retrieve the speed anyway, and makes
>> code a little simpler yet.
> 
>   Ping for:
> <https://urldefense.com/v3/__https://lore.kernel.org/r/alpine.DEB.2.21.2512072345220.49654@angie.orcam.me.uk/__;!!ACWV5N9M2RV99hQ!OAfq9yiKnpdaetDotJN22sQQSGBYwwgga65vyQgENCufGjXofXKzxK_fIlCshhI-_EDkeOuLzjgvx4I5zng$ >.
> Re-verified with 6.19.0-rc7.
> 
>    Maciej

We’re waiting on this patch. Are there any updates or plans for it?

Thanks,
Alok

Re: [PING][PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[ALOK TIWARI]

On 2/19/2026 9:12 AM, ALOK TIWARI wrote:
> 
> 
> On 2/4/2026 10:42 PM, Maciej W. Rozycki wrote:
>> On Mon, 8 Dec 2025, Maciej W. Rozycki wrote:
>>
>>>   I've figured out that backporting will be less intrusive if an 
>>> update to
>>> use `->supported_speeds' is posted as a separate follow-up change.  
>>> So it
>>> is now 2/3 in this series, after 1/3 comprising the original patch, only
>>> trivially updated.  Then 3/3 moves the maximum link speed determination
>>> earlier on for an early exit in the PCIE_SPEED_2_5GT case; maybe 
>>> unlikely,
>>> but essentially free now, now that we retrieve the speed anyway, and 
>>> makes
>>> code a little simpler yet.
>>
>>   Ping for:
>> <https://urldefense.com/v3/__https://lore.kernel.org/r/ 
>> alpine.DEB.2.21.2512072345220.49654@angie.orcam.me.uk/__;!! 
>> ACWV5N9M2RV99hQ! 
>> OAfq9yiKnpdaetDotJN22sQQSGBYwwgga65vyQgENCufGjXofXKzxK_fIlCshhI- 
>> _EDkeOuLzjgvx4I5zng$ >.
>> Re-verified with 6.19.0-rc7.
>>
>>    Maciej
> 
> We’re waiting on this patch. Are there any updates or plans for it?
> 
> Thanks,
> Alok


This v2 patch series looks good to me. However, there has been a fairly
extensive discussion on the earlier thread linked below, and we did not
reach a clear conclusion there.

Hopefully we can resolve it soon.

https://lore.kernel.org/all/alpine.DEB.2.21.2602252156250.34294@angie.orcam.me.uk/



Thanks,
Alok

Re: [PATCH v2 0/3] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Bjorn Helgaas]

On Mon, Dec 08, 2025 at 07:24:23PM +0000, Maciej W. Rozycki wrote:
> Hi,
> 
>  I've figured out that backporting will be less intrusive if an update to 
> use `->supported_speeds' is posted as a separate follow-up change.  So it 
> is now 2/3 in this series, after 1/3 comprising the original patch, only 
> trivially updated.  Then 3/3 moves the maximum link speed determination 
> earlier on for an early exit in the PCIE_SPEED_2_5GT case; maybe unlikely, 
> but essentially free now, now that we retrieve the speed anyway, and makes 
> code a little simpler yet.
> 
>  Please let me know if you'd prefer me to fold 2/3 into 1/3 after all.
> 
>  Previous iterations:
> 
> - v1 at: <https://lore.kernel.org/r/alpine.DEB.2.21.2511290245460.36486@angie.orcam.me.uk/>.

Applied to pci/enumeration for v7.1, thanks.  This will be rebased
after v7.0-rc1.

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Matthew W Carlis]

On Thu, 19 Feb 2026, Bjorn Helgaas wrote:

> Applied to pci/enumeration for v7.1, thanks.  This will be rebased
> after v7.0-rc1.

We're heading down a path here where we keep working around the work-around &
now have decided that the kernel will be meddling with the link on potentially
all of the PCIe devices in the world. The trade off that we're making here to
accommodate a device specific interaction doesn't seem like the right direction. 

Can we reconsider my patch that restricts the link retrain mechanism
to the specific device that created the work-around?
https://lore.kernel.org/all/20250702052430.13716-1-mattc@purestorage.com/

How do we decide which device to fix and which devices to break?

- Matt

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Bjorn Helgaas]

On Thu, Feb 19, 2026 at 03:09:59PM -0700, Matthew W Carlis wrote:
> On Thu, 19 Feb 2026, Bjorn Helgaas wrote:
> 
> > Applied to pci/enumeration for v7.1, thanks.  This will be rebased
> > after v7.0-rc1.
> 
> We're heading down a path here where we keep working around the
> work-around & now have decided that the kernel will be meddling with
> the link on potentially all of the PCIe devices in the world. The
> trade off that we're making here to accommodate a device specific
> interaction doesn't seem like the right direction. 
> 
> Can we reconsider my patch that restricts the link retrain mechanism
> to the specific device that created the work-around?
> https://lore.kernel.org/all/20250702052430.13716-1-mattc@purestorage.com/

I think we already at least potentially meddle with the link on every
device, and it definitely makes me nervous.  I would like it much
better if it's possible to limit it to devices with known defects.

I'll defer these for now and we can see if a consensus emerges.

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

On Thu, 19 Feb 2026, Bjorn Helgaas wrote:

> > Can we reconsider my patch that restricts the link retrain mechanism
> > to the specific device that created the work-around?
> > https://lore.kernel.org/all/20250702052430.13716-1-mattc@purestorage.com/
> 
> I think we already at least potentially meddle with the link on every
> device, and it definitely makes me nervous.  I would like it much
> better if it's possible to limit it to devices with known defects.
> 
> I'll defer these for now and we can see if a consensus emerges.

 As I say it's logically impossible to figure out whether or not to apply 
such a workaround where the culprit is the downstream device, because 
until you've succeeded establishing a link you have no way to figure out 
what the downstream device actually is.

  Maciej

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Bjorn Helgaas]

On Fri, Feb 20, 2026 at 12:03:17PM +0000, Maciej W. Rozycki wrote:
> On Thu, 19 Feb 2026, Bjorn Helgaas wrote:
> 
> > > Can we reconsider my patch that restricts the link retrain mechanism
> > > to the specific device that created the work-around?
> > > https://lore.kernel.org/all/20250702052430.13716-1-mattc@purestorage.com/
> > 
> > I think we already at least potentially meddle with the link on every
> > device, and it definitely makes me nervous.  I would like it much
> > better if it's possible to limit it to devices with known defects.
> > 
> > I'll defer these for now and we can see if a consensus emerges.
> 
> As I say it's logically impossible to figure out whether or not to
> apply such a workaround where the culprit is the downstream device,
> because until you've succeeded establishing a link you have no way
> to figure out what the downstream device actually is.

IIUC Matthew [1] and Alok [2] have reported issues that only happen
when we run pcie_failed_link_retrain().  The issues seem to be with
NVMe devices, but I don't see a root cause or a solution (other than
skipping pcie_failed_link_retrain()).

[1] https://lore.kernel.org/all/20250702052430.13716-2-mattc@purestorage.com/
[2] https://lore.kernel.org/all/c296df33-f9c0-42f7-8add-6966d89d00c4@oracle.com/

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Matthew W Carlis]

I wonder if the compromise here isn't adding a new kind of 
DECLARE_PCI_FIXUP_<LINKFAIL?> & putting this quirk behind it?

On Thu, 19 Feb 2026 16:53:22 -0600, Bjorn Helgaas wrote:
> I would like it much better if it's possible to limit it to
> devices with known defects.

On Fri, 20 Feb 2026 12:03:17 +0000, Maciej W. Rozycki wrote:
> As I say it's logically impossible to figure out whether or not to apply 
> such a workaround where the culprit is the downstream device

I don't think we're looking at an impossible decision to make here in terms
of whether to apply the quirk. It makes the most sense in my mind to restrict
the quirk to that Asmedia device which was upstream of the pericom switch in
the initial bug report iirc.

1) There was never a root cause so we can't say that this is in fact an issue
    with the pericom switch... It could be the ASmedia switch causing the problem..
2) Even if it is a bug in the pericom, applying to only the ASmedia switch limits the
    blast radius of the retrain action. It becomes unlikely that we ever see any
    reports of issues from large scale users (hyper scalers, server vendors etc).

On Mon, 23 Feb 2026 11:36:03 -0600, Bjorn Helgaas wrote:
> IIUC Matthew [1] and Alok [2] have reported issues that only happen
> when we run pcie_failed_link_retrain().  The issues seem to be with
> NVMe devices, but I don't see a root cause or a solution (other than
> skipping pcie_failed_link_retrain()).

I don't think the issue is really specific to NVMe devices realistically what
is happening is that NVMe devices happen to be hot-plug'ed way more often than
any other kind of PCIe device. Vendors who design devices/systems for hot-plug
will also do extensive hot-plug testing & due to limitations of the kernel's
heuristics, invoke the quirk when it is not desirable to do so.

-Matt

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

On Mon, 23 Feb 2026, Bjorn Helgaas wrote:

> > > > Can we reconsider my patch that restricts the link retrain mechanism
> > > > to the specific device that created the work-around?
> > > > https://lore.kernel.org/all/20250702052430.13716-1-mattc@purestorage.com/
> > > 
> > > I think we already at least potentially meddle with the link on every
> > > device, and it definitely makes me nervous.  I would like it much
> > > better if it's possible to limit it to devices with known defects.
> > > 
> > > I'll defer these for now and we can see if a consensus emerges.
> > 
> > As I say it's logically impossible to figure out whether or not to
> > apply such a workaround where the culprit is the downstream device,
> > because until you've succeeded establishing a link you have no way
> > to figure out what the downstream device actually is.
> 
> IIUC Matthew [1] and Alok [2] have reported issues that only happen
> when we run pcie_failed_link_retrain().  The issues seem to be with
> NVMe devices, but I don't see a root cause or a solution (other than
> skipping pcie_failed_link_retrain()).

 I argue that by applying this change the issues with NVMe hot-plug will 
be sorted while keeping the configuration working that 
pcie_failed_link_retrain() is needed for.  Win-win.

 I note that active links are unaffected, so to say it's meddling with the 
link on every device is I think a bit of an overstatement, and reports of 
issues are from a few people only, of which Matthew insists on dropping 
the pcie_failed_link_retrain() stuff while Alok is happy with the solution 
proposed.

 Shall we try this change and drop the whole pcie_failed_link_retrain() 
stuff after all if it turns out to cause issues yet again?

 What outcome would you envisage had I taken the approach from this update 
right away with the original change?  My only fault was I have no use(*) 
for PCIe hot-plug and did not predict the impact there.  But no one can 
predict everything and I think dropping a solution rather than fixing it 
just because it wasn't perfect right from the beginning would be unfair.

 As to the root cause, I suppose it's hw people who see the problem in the 
lab could say more.

 I can only guess LBMS is set in the course of device removal, perhaps due 
to contacts bouncing.  It's not clear to me if this is compliant even, as 
the spec is explicit that LBMS is only allowed to be set if the port has 
not transitioned through the DL_Down status, which the loss of electrical 
connection (circuit open) would seem (?) to imply.

 Then again at x4 width which NVMe tends to imply the lanes may disconnect 
at different times each, so the loss of connection on one lane would not 
imply the loss of link, so the setting of LBMS could be legitimate before 
the device has gone for good.

 At insertion the link has to get running stable at 2.5GT/s first before 
switching to a higher speed, so even more so the LBMS is not supposed to 
be set.

 As I say it's only a guess and I may be missing something.  I can't claim 
any familiarity with the PCIe physical layer, though I can take some time 
and study it.

 In any case the unconditional unclamping and retraining actions proposed 
are expected to clean up the state, whether compliant or not.

(*) Except for ExpressCard in my laptop, but that's another story.

  Maciej

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Matthew W Carlis]

On Mon, 23 Feb 2026 23:14:37 +0000, Maciej W. Rozycki wrote:
>  I argue that by applying this change the issues with NVMe hot-plug will 
> be sorted while keeping the configuration working that 
> pcie_failed_link_retrain() is needed for.  Win-win.

I don't think that what you are saying is true there is invariably going to be
some other consequence of this change.. Its hard to believe there can be any
changes to the pci drivers that won't break something.

>  I note that active links are unaffected, so to say it's meddling with the 
> link on every device is I think a bit of an overstatement, and reports of 
> issues are from a few people only...

There is no discrimination about which device it can be invoked on..
I'm looking at a fleet of millions of hot-plug'able devices.... I don't really
know if it matters how many people report an issue, I think what probably
matters is making the right change. Initially was there any other reports
of the quirk helping with other devices besides the delock 41433?

>  What outcome would you envisage had I taken the approach from this update 
> right away with the original change?  My only fault was I have no use(*) 
> for PCIe hot-plug and did not predict the impact there. 

What I'm seeing now is an overall confusion about whether a link failed to train
to gen 1 or was recovered by the quirk or recovered on its own etc... In my systems
I would prefer to NEVER invoke the quirk under any circumstances because I expect
my devices to work. With the quirk it becomes more unclear about what the cause
of a link issue might have been or whether it was even a real link issue in the
first place or some weird timing.. 

-Matt

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[Maciej W. Rozycki]

On Tue, 24 Feb 2026, Matthew W Carlis wrote:

> >  I argue that by applying this change the issues with NVMe hot-plug will 
> > be sorted while keeping the configuration working that 
> > pcie_failed_link_retrain() is needed for.  Win-win.
> 
> I don't think that what you are saying is true there is invariably going to be
> some other consequence of this change.. Its hard to believe there can be any
> changes to the pci drivers that won't break something.

 You're being sarcastic, aren't you?

 While I sympathise with your feeling, may I pretty please ask you to at 
the very least give my fix a try in your test environment?

> >  I note that active links are unaffected, so to say it's meddling with the 
> > link on every device is I think a bit of an overstatement, and reports of 
> > issues are from a few people only...
> 
> There is no discrimination about which device it can be invoked on..
> I'm looking at a fleet of millions of hot-plug'able devices.... I don't really
> know if it matters how many people report an issue, I think what probably
> matters is making the right change. Initially was there any other reports
> of the quirk helping with other devices besides the delock 41433?

 No reports that I know of.  Please bear in mind that the failure mode is 
such that you need enough knowledge of PCIe internals and the spec to 
actually realise there is periodic link training activity taking place.

 In the absence of the quirk for the average user there's just no 
communication, as with a dead downstream device (and the upstream device 
is sound as anything else plugged in, including but not limited to NVMe 
storage, works just fine).  In the presence of the quirk the downstream 
device just works and I expect hardly anyone can be bothered to report 
seeing "broken device, retraining non-functional downstream link at 
2.5GT/s" in the log.  It's only cases like yours that bring attention to 
the message.

> >  What outcome would you envisage had I taken the approach from this update 
> > right away with the original change?  My only fault was I have no use(*) 
> > for PCIe hot-plug and did not predict the impact there. 
> 
> What I'm seeing now is an overall confusion about whether a link failed to train
> to gen 1 or was recovered by the quirk or recovered on its own etc... In my systems
> I would prefer to NEVER invoke the quirk under any circumstances because I expect
> my devices to work. With the quirk it becomes more unclear about what the cause
> of a link issue might have been or whether it was even a real link issue in the
> first place or some weird timing.. 

 I can see your point.

 However from your description I infer this is about a test environment, a
development lab so to speak.  And you are a highly skilled professional 
who has access to measurement, test, and hardware debug equipment, and are 
therefore able to figure out stuff.  Conversely, the vast majority of 
Linux deployments is in the field, where no sophisticated equipment is 
available and the operator, if any, may have basic technical skills only.

 I have been taught that in the field it is more desirable for equipment 
to operate according to expectations rather than to strictly follow the 
relevant specifications and consequently fail operating.  And the quirk I 
have come up with just follows this principle, letting unqualified people 
use their equipment (this is similar to Postel's law if you know what I 
mean).

 I realise that in the lab you want strict compliance as this will verify 
interoperation of the devices you design.

 So I think we have conflicting objectives here and I can only offer a 
sysfs setting that will switch between the modes according to the specific 
user's needs, as the intent is not something the kernel can figure out by 
itself.

 Please mind however that throughout this week and the next I'm away on 
holiday (a proper one, as in alpine skiing), so my availability to respond 
or work on stuff is limited.  I'll appreciate if you give my fix a try 
meanwhile.

  Maciej

Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[ALOK TIWARI]

On 2/27/2026 3:32 AM, Maciej W. Rozycki wrote:
> On Tue, 24 Feb 2026, Matthew W Carlis wrote:
> 
>>>   I argue that by applying this change the issues with NVMe hot-plug will
>>> be sorted while keeping the configuration working that
>>> pcie_failed_link_retrain() is needed for.  Win-win.
>>
>> I don't think that what you are saying is true there is invariably going to be
>> some other consequence of this change.. Its hard to believe there can be any
>> changes to the pci drivers that won't break something.
> 
>   You're being sarcastic, aren't you?
> 
>   While I sympathise with your feeling, may I pretty please ask you to at
> the very least give my fix a try in your test environment?
> 
>>>   I note that active links are unaffected, so to say it's meddling with the
>>> link on every device is I think a bit of an overstatement, and reports of
>>> issues are from a few people only...
>>
>> There is no discrimination about which device it can be invoked on..
>> I'm looking at a fleet of millions of hot-plug'able devices.... I don't really
>> know if it matters how many people report an issue, I think what probably
>> matters is making the right change. Initially was there any other reports
>> of the quirk helping with other devices besides the delock 41433?
> 
>   No reports that I know of.  Please bear in mind that the failure mode is
> such that you need enough knowledge of PCIe internals and the spec to
> actually realise there is periodic link training activity taking place.
> 
>   In the absence of the quirk for the average user there's just no
> communication, as with a dead downstream device (and the upstream device
> is sound as anything else plugged in, including but not limited to NVMe
> storage, works just fine).  In the presence of the quirk the downstream
> device just works and I expect hardly anyone can be bothered to report
> seeing "broken device, retraining non-functional downstream link at
> 2.5GT/s" in the log.  It's only cases like yours that bring attention to
> the message.
> 
>>>   What outcome would you envisage had I taken the approach from this update
>>> right away with the original change?  My only fault was I have no use(*)
>>> for PCIe hot-plug and did not predict the impact there.
>>
>> What I'm seeing now is an overall confusion about whether a link failed to train
>> to gen 1 or was recovered by the quirk or recovered on its own etc... In my systems
>> I would prefer to NEVER invoke the quirk under any circumstances because I expect
>> my devices to work. With the quirk it becomes more unclear about what the cause
>> of a link issue might have been or whether it was even a real link issue in the
>> first place or some weird timing..
> 
>   I can see your point.
> 
>   However from your description I infer this is about a test environment, a
> development lab so to speak.  And you are a highly skilled professional
> who has access to measurement, test, and hardware debug equipment, and are
> therefore able to figure out stuff.  Conversely, the vast majority of
> Linux deployments is in the field, where no sophisticated equipment is
> available and the operator, if any, may have basic technical skills only.
> 
>   I have been taught that in the field it is more desirable for equipment
> to operate according to expectations rather than to strictly follow the
> relevant specifications and consequently fail operating.  And the quirk I
> have come up with just follows this principle, letting unqualified people
> use their equipment (this is similar to Postel's law if you know what I
> mean).
> 
>   I realise that in the lab you want strict compliance as this will verify
> interoperation of the devices you design.
> 
>   So I think we have conflicting objectives here and I can only offer a
> sysfs setting that will switch between the modes according to the specific
> user's needs, as the intent is not something the kernel can figure out by
> itself.
> 
>   Please mind however that throughout this week and the next I'm away on
> holiday (a proper one, as in alpine skiing), so my availability to respond
> or work on stuff is limited.  I'll appreciate if you give my fix a try
> meanwhile.
> 
>    Maciej

 From my perspective, the current patch looks like a positive step and 
seems to address the NVMe hot-plug concerns without regressing the 
original use case.

That said, I’d really appreciate input from other maintainers on whether 
this approach strikes the right balance between field robustness,

Given the concerns around hot-plug behavior and diagnosability, do you 
think reverting (or partially reverting)
the behavioral impact of the original commit: "PCI: Work around PCIe 
link training failures"

what is best way to conclude this issue?

Thanks,
Alok