Re: [PATCH for-linus v2 2/3] PCI: Honor Max Link Speed when determining supported speeds

Jonathan Cameron
2024-12-16T10:53:08Z

On Sun, 15 Dec 2024 11:20:52 +0100
Lukas Wunner <lukas@wunner.de> wrote:

> The Supported Link Speeds Vector in the Link Capabilities 2 Register
> indicates the *supported* link speeds. The Max Link Speed field in
> the Link Capabilities Register indicates the *maximum* of those speeds.
>
> pcie_get_supported_speeds() neglects to honor the Max Link Speed field
> and will thus incorrectly deem higher speeds as supported. Fix it.
>
> One user-visible issue addressed here is an incorrect value in the sysfs
> attribute "max_link_speed".
>
> But the main motivation is a boot hang reported by Niklas: Intel JHL7540
> "Titan Ridge 2018" Thunderbolt controllers supports 2.5-8 GT/s speeds,
> but indicate 2.5 GT/s as maximum. Ilpo recalls seeing this on more
> devices. It can be explained by the controller's Downstream Ports
> supporting 8 GT/s if an Endpoint is attached, but limiting to 2.5 GT/s
> if the port interfaces to a PCIe Adapter, in accordance with USB4 v2
> sec 11.2.1:
>
> "This section defines the functionality of an Internal PCIe Port that
> interfaces to a PCIe Adapter. [...]
> The Logical sub-block shall update the PCIe configuration registers
> with the following characteristics: [...]
> Max Link Speed field in the Link Capabilities Register set to 0001b
> (data rate of 2.5 GT/s only).
> Note: These settings do not represent actual throughput. Throughput
> is implementation specific and based on the USB4 Fabric performance."
>
> The present commit is not sufficient on its own to fix Niklas' boot hang,
> but it is a prerequisite.
>
> Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds")
> Reported-by: Niklas Schnelle <niks@kernel.org>
> Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Makes sense as a hardening step, even without the oddity of thunderbolt.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>