From: Bjorn Helgaas <helgaas@kernel.org>
To: Andreas Wild <andiwild@gmail.com>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com,
macro@orcam.me.uk, linux-kernel@vger.kernel.org,
M M <restafvalendergelijke@outlook.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
regressions@lists.linux.dev
Subject: Re: [PATCH v3] PCI: Skip Target Speed quirk on clamped ports with no link
Date: Thu, 17 Sep 2026 18:33:55 -0500 [thread overview]
Message-ID: <20260917233355.GA1115024@bhelgaas> (raw)
In-Reply-To: <20260801201244.4421-1-andiwild@gmail.com>
[+cc M M, Thorsten]
On Sat, Aug 01, 2026 at 10:11:48PM +0200, 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
>
> 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>
I provisionally applied this on pci/misc. It seems to address at
least part of a v7.2 regression, so it probably should go on
pci/for-linus for v7.3.
But I'd like to have it in -next for a bit before asking Linus to pull
it.
I added:
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221801
based on Edward's testing at
https://bugzilla.kernel.org/show_bug.cgi?id=221801#c13. Edward, I
bcc'd you because I haven't seen a public email response, but if you
want your Tested-by to appear in the git commit, just respond to this
email thread.
But IIUC Aoxtj still sees issues with 72780f796468 ("PCI: Always lift
2.5GT/s restriction in PCIe failed link retraining") even with this
patch
(https://lore.kernel.org/all/331e97c7-e422-420d-9f3e-5d9f734464b3@axtjblog.cc)
And M M / Mich (BCC'd) also reports an issue that (IIUC) is not fixed by
this patch (https://bugzilla.kernel.org/show_bug.cgi?id=221919#c3)
So evidently there are still issues but maybe this patch fixes part of
them?
> ---
> 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
>
next prev parent reply other threads:[~2026-09-17 23:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 20:11 [PATCH v3] PCI: Skip Target Speed quirk on clamped ports with no link Andreas Wild
2026-08-01 20:20 ` sashiko-bot
2026-08-03 5:39 ` Thorsten Leemhuis
2026-08-03 22:07 ` Maciej W. Rozycki
2026-08-04 5:32 ` Thorsten Leemhuis
2026-08-07 19:59 ` Aoxtj
2026-08-08 6:31 ` Andreas Wild
2026-08-11 3:43 ` Aoxtj
2026-08-11 6:42 ` Andreas Wild
2026-08-24 14:26 ` Thorsten Leemhuis
2026-08-25 7:05 ` Andreas Wild
2026-08-25 10:18 ` Maciej W. Rozycki
2026-09-02 15:48 ` Thorsten Leemhuis
2026-09-07 12:33 ` Maciej W. Rozycki
2026-09-17 23:33 ` Bjorn Helgaas [this message]
2026-09-18 5:39 ` Thorsten Leemhuis
2026-09-18 10:39 ` Maciej W. Rozycki
2026-09-18 11:00 ` Thorsten Leemhuis
2026-09-18 12:18 ` Maciej W. Rozycki
2026-09-18 12:50 ` Thorsten Leemhuis
2026-09-21 10:33 ` Thorsten Leemhuis
2026-09-29 5:45 ` Thorsten Leemhuis
2026-09-29 7:59 ` Andreas Wild
-- strict thread matches above, loose matches on Subject: below --
2026-09-20 8:15 blaat windows
2026-09-21 14:45 Thomas Stegbauer
2026-10-07 14:03 SyncNOW.net - Armando Araujo Filho
[not found] <DU2PPFBE35756D171CD64356C8D8DF3C2F8AB922@DU2PPFBE35756D1.EURP189.PROD.OUTLOOK.COM>
2026-10-09 11:21 ` M M
2026-10-09 11:36 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260917233355.GA1115024@bhelgaas \
--to=helgaas@kernel.org \
--cc=andiwild@gmail.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=restafvalendergelijke@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.