On Fri, 27 Jun 2025, Maciej W. Rozycki wrote:
> Have you verified that with a fix[1] applied for a regression introduced
> by commit de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set
> PCIe Link Speed") discussed in the other thread[2] you can still see those
> issues?
When I tested with bwctrl.c I also picked the mentioned patch with it.
Certainly the patch series related to bwctrl.c & the patch you mention helped
significantly, but it seems that it is still possible to have the quirk degrade
a 'would be healthy' link. What I have seen so far with the bwctrl patch series
have been during PCIe error injection testing & the quirk running at the end of
DPC handling during pci_bridge_wait_for_secondary_bus(). I believe sometimes an
endpoint isn't ready for the link to be active again during DPC handling as
soon as DPC status is cleared & therefore the quirk may be triggered. One case
I haven't quite fully explained was the quirk running twice when DPC is in
pci_bridge_wait_for_secondary_bus().. It means that both
pcie_wait_for_link_delay() and the final pci_dev_wait() must have been the
callers of the quirk(), but I think it implies that the first must have thought
the link initially wasn't working then the quirk thought forcing to Gen1 fixed
the issue however the drive must not have been read to respond to command
register reads soon enough.
On another note I realized I left off a closing parenthesis in my patch... I
guess I would have to re-submit if we move forward on this.
