[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2512080029210.49654@angie.orcam.me.uk>
Date: Mon, 8 Dec 2025 19:25:26 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Matthew W Carlis <mattc@...estorage.com>
cc: ahuang12@...ovo.com, alok.a.tiwari@...cle.com, ashishk@...estorage.com,
Bjorn Helgaas <bhelgaas@...gle.com>, guojinhui.liam@...edance.com,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
jiwei.sun.bj@...com, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, Lukas Wunner <lukas@...ner.de>,
msaggi@...estorage.com, sconnor@...estorage.com, sunjw10@...ovo.com
Subject: Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link
retraining
On Thu, 4 Dec 2025, Matthew W Carlis wrote:
> For what its worth I have a particular Gen5 device in my lab here that gets stuck
> in an infinite link up-down loop when you force the speed to Gen2 when also combined
> with a specific downstream port... I'm sure there is another device somewhere else
> in the world that has the same issue when you force it to Gen1.
Well, it's an erratum vs another erratum case. Then should such a device
at its maximum link speed trigger the workaround somehow, with this fix in
place any temporary clamp will be lifted anyway and the link retrained, so
it will recover from the link up-down loop. So no functional regression.
> The kernel should assume a PCIe link will automatically train to the best
> speed that the devices can achieve & if the link fails to train then it should
> be up to the user space to decide what to do with it in my opinion.
It might be tough where you have your rootfs device down the problematic
link.
Thank you for your input.
Maciej
Powered by blists - more mailing lists