From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>, <linux-pci@vger.kernel.org>,
"Niklas Schnelle" <niks@kernel.org>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.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 3/3] PCI/bwctrl: Enable only if more than one speed is supported
Date: Mon, 16 Dec 2024 11:32:22 +0000 [thread overview]
Message-ID: <20241216113222.000033a4@huawei.com> (raw)
In-Reply-To: <2292e75dcf26f1c6d7c1f715edfe0e49f079149d.1734257330.git.lukas@wunner.de>
On Sun, 15 Dec 2024 11:20:53 +0100
Lukas Wunner <lukas@wunner.de> wrote:
> If a PCIe port only supports a single speed, enabling bandwidth control
> is pointless: There's no need to monitor autonomous speed changes, nor
> can the speed be changed.
>
> Not enabling it saves a small amount of memory and compute resources,
> but also fixes a boot hang reported by Niklas: It occurs when enabling
> bandwidth control on Downstream Ports of Intel JHL7540 "Titan Ridge 2018"
> Thunderbolt controllers. The ports only support 2.5 GT/s in accordance
> with USB4 v2 sec 11.2.1, so the present commit works around the issue.
>
> PCIe r6.2 sec 8.2.1 prescribes that:
>
> "A device must support 2.5 GT/s and is not permitted to skip support
> for any data rates between 2.5 GT/s and the highest supported rate."
>
> Consequently, bandwidth control is currently only disabled if a port
> doesn't support higher speeds than 2.5 GT/s. However the Implementation
> Note in PCIe r6.2 sec 7.5.3.18 cautions:
>
> "It is strongly encouraged that software primarily utilize the
> Supported Link Speeds Vector instead of the Max Link Speed field,
> so that software can determine the exact set of supported speeds on
> current and future hardware. This can avoid software being confused
> if a future specification defines Links that do not require support
> for all slower speeds."
>
> In other words, future revisions of the PCIe Base Spec may allow gaps
> in the Supported Link Speeds Vector. To be future-proof, don't just
> check whether speeds above 2.5 GT/s are supported, but rather check
> whether *more than one* speed is supported.
It has long felt like the need for the very low speeds will become optional
eventually, though the challenges of getting a backwards compatibility
change into the specification may make that take a while. Hence
I agree this approach makes sense.
Reviewed-by: Jonathan Cameron <Jonthan.Cameron@huawei.com>
>
> Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller")
> Reported-by: Niklas Schnelle <niks@kernel.org>
> Closes: https://lore.kernel.org/r/db8e457fcd155436449b035e8791a8241b0df400.camel@kernel.org/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
> drivers/pci/pcie/portdrv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
> index 5e10306b6308..02e73099bad0 100644
> --- a/drivers/pci/pcie/portdrv.c
> +++ b/drivers/pci/pcie/portdrv.c
> @@ -265,12 +265,14 @@ static int get_port_device_capability(struct pci_dev *dev)
> (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> services |= PCIE_PORT_SERVICE_DPC;
>
> + /* Enable bandwidth control if more than one speed is supported. */
> if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
> pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
> u32 linkcap;
>
> pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &linkcap);
> - if (linkcap & PCI_EXP_LNKCAP_LBNC)
> + if (linkcap & PCI_EXP_LNKCAP_LBNC &&
> + hweight8(dev->supported_speeds) > 1)
> services |= PCIE_PORT_SERVICE_BWCTRL;
> }
>
next prev parent reply other threads:[~2024-12-16 11:32 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
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 [this message]
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=20241216113222.000033a4@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--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 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.