Re: [PATCH 2/2] PCI: Fix the PCIe bridge decreasing to Gen 1 during hotplug testing

Maciej W. Rozycki
2025-12-04T23:44:06Z

On Wed, 3 Dec 2025, Matthew W Carlis wrote:

> > Discard Vendor:Device ID matching in the PCIe failed link retraining
> > quirk and ignore the link status for the removal of the 2.5GT/s speed
> > clamp, whether applied by the quirk itself or the firmware earlier on.
> > Revert to the original target link speed if this final link retraining
> > has failed.
>
> I think we should either remove the quirk or only execute the quirk when the
> downstream port is the specific ASMedia 0x2824. Hardware companies that
> develop PCIe devices rely on the linux kernel for a significant amount of
> their testing & the action taken by this quirk is going to introduce
> noise into those tests by initiating unexpected speed changes etc.

Conversely, ISTM this could be good motivation for hardware designers to
reduce hot-plug noise. After all LBMS is only supposed to be ever set for
links in the active state and not while training, so perhaps debouncing is
needed for the transient state?

> As long as we have this quirk messing with link speeds we'll just
> continue to see issue reports over time in my opinion.

Well, the issues happened because I made an unfortunate design decision
with the original implementation which did not clean up after itself, just
because I have no use for hot-plug scenarios and didn't envisage it could
be causing issues.

The most recent update brings the device back to its original state
whether retraining succeeded or not, so it should now be transparent to
your noisy hot-plug scenarios, while helping stubborn devices at the same
time. You might have not noticed this code existed if it had been in its
currently proposed shape right from the beginning.

It's only those who do nothing that make no mistakes.

Maciej