From: Lukas Wunner <lukas@wunner.de>
To: Niklas Schnelle <niks@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
"Maciej W. Rozycki" <macro@orcam.me.uk>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH for-linus v2 1/3] PCI: Assume 2.5 GT/s if Max Link Speed is undefined
Date: Mon, 16 Dec 2024 07:45:39 +0100 [thread overview]
Message-ID: <Z1_MkwPmT_5axOGh@wunner.de> (raw)
In-Reply-To: <6ccb04cb47da39770e62ebf3f540698e4412ae0a.camel@kernel.org>
On Sun, Dec 15, 2024 at 10:17:46PM +0100, Niklas Schnelle wrote:
> On Sun, 2024-12-15 at 11:20 +0100, Lukas Wunner wrote:
> > Broken PCIe devices may not set any of the bits in the Link Capabilities
> > Register's "Max Link Speed" field. Assume 2.5 GT/s in such a case,
> > which is the lowest possible PCIe speed. It must be supported by every
> > device per PCIe r6.2 sec 8.2.1.
[...]
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -6233,6 +6233,13 @@ u8 pcie_get_supported_speeds(struct pci_dev *dev)
> > u32 lnkcap2, lnkcap;
> > u8 speeds;
> >
> > + /* A device must support 2.5 GT/s (PCIe r6.2 sec 8.2.1) */
> > + pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
> > + if (!(lnkcap & PCI_EXP_LNKCAP_SLS)) {
> > + pci_info(dev, "Undefined Max Link Speed; assume 2.5 GT/s\n");
> > + return PCI_EXP_LNKCAP2_SLS_2_5GB;
> > + }
> > +
> > /*
> > * Speeds retain the reserved 0 at LSB before PCIe Supported Link
> > * Speeds Vector to allow using SLS Vector bit defines directly.
>
> I feel like this patch goes a bit against the idea of this being more
> future proof. Personally, I kind of expect that any future devices
> which may skip support for lower speeds would start with skipping 2.5
> GT/s and a future PCIe spec might allow this.
>
> In that case with the above code we end up assuming 2.5 GT/s which
> won't work while the Supported Link Speeds Vector could contain
> supported speeds with the assumption that when in doubt software relies
> on that (PCIe r6.2 sec 7.5.3.18) and it might even be future spec
> conformant.
>
> So I think instead of assuming 2.5 GT/s I was thinking of something
> like the diff below (on top of this series).
[...]
> @@ -6238,10 +6235,11 @@ u8 pcie_get_supported_speeds(struct pci_dev *dev)
> */
> pcie_capability_read_dword(dev, PCI_EXP_LNKCAP2, &lnkcap2);
> speeds = lnkcap2 & PCI_EXP_LNKCAP2_SLS;
> -
> /* Ignore speeds higher than Max Link Speed */
> - speeds &= GENMASK(lnkcap & PCI_EXP_LNKCAP_SLS,
> - PCI_EXP_LNKCAP2_SLS_2_5GB);
> + if (max_bits)
> + speeds &= GENMASK(max_bits, PCI_EXP_LNKCAP2_SLS_2_5GB);
> + else
> + pci_info(dev, "Undefined Max Link Speed; relying on LnkCap2\n");
I see. Right now assuming 2.5 GT/s is the most conservative approach.
We may have to revisit this once the PCIe spec does allow gaps in the
Supported Link Speeds. Then again, I'm not aware of any broken devices
that actually *have* an undefined Max Link Speed, so this patch is a
safety measure to avoid the GENMASK() inversion in patch [2/3].
Thanks,
Lukas
next prev parent reply other threads:[~2024-12-16 6:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-15 10:20 [PATCH for-linus v2 0/3] Fix bwctrl boot hang Lukas Wunner
2024-12-15 10:20 ` [PATCH for-linus v2 1/3] PCI: Assume 2.5 GT/s if Max Link Speed is undefined Lukas Wunner
2024-12-15 21:17 ` Niklas Schnelle
2024-12-16 6:45 ` Lukas Wunner [this message]
2024-12-16 10:51 ` Jonathan Cameron
2024-12-16 14:09 ` Ilpo Järvinen
2024-12-16 14:17 ` Mario Limonciello
2024-12-15 10:20 ` [PATCH for-linus v2 2/3] PCI: Honor Max Link Speed when determining supported speeds Lukas Wunner
2024-12-15 20:56 ` Niklas Schnelle
2024-12-16 10:53 ` Jonathan Cameron
2024-12-16 14:12 ` Ilpo Järvinen
2024-12-15 10:20 ` [PATCH for-linus v2 3/3] PCI/bwctrl: Enable only if more than one speed is supported Lukas Wunner
2024-12-15 21:03 ` Niklas Schnelle
2024-12-16 11:32 ` Jonathan Cameron
2024-12-16 14:20 ` Mario Limonciello
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=Z1_MkwPmT_5axOGh@wunner.de \
--to=lukas@wunner.de \
--cc=Jonathan.Cameron@huawei.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=mario.limonciello@amd.com \
--cc=mika.westerberg@linux.intel.com \
--cc=niks@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox