[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251204183036.39649-1-mattc@purestorage.com>
Date: Thu, 4 Dec 2025 11:30:36 -0700
From: Matthew W Carlis <mattc@...estorage.com>
To: macro@...am.me.uk
Cc: ahuang12@...ovo.com,
alok.a.tiwari@...cle.com,
ashishk@...estorage.com,
bamstadt@...estorage.com,
bhelgaas@...gle.com,
guojinhui.liam@...edance.com,
ilpo.jarvinen@...ux.intel.com,
jiwei.sun.bj@...com,
linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org,
lukas@...ner.de,
mattc@...estorage.com,
msaggi@...estorage.com,
sconnor@...estorage.com,
sunjw10@...ovo.com
Subject: Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining
I'm sorry my last response kind of messed up the threading in this chain...
I don't understand why we still think its a good idea to have this action
in the kernel for any device type since it seems to only help Maciej W. Rozycki's
specific situation which is very likely to be the only one of its kind. In
addition the Delock adapter isn't what I would consider a particularly
"solid" device.
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.
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.
Powered by blists - more mailing lists