On Mon, Jun 23, 2025 at 08:27:19AM -0600, Manivannan Sadhasivam wrote:
> On Fri, Jun 13, 2025 at 02:48:43PM +0200, Niklas Cassel wrote:
> > Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of
> > 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before
> > sending a Configuration Request.
> >
> > Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect
> > Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0
> > and 90ms after the link came up before we enumerate the bus, and this
> > was apparently enough for most devices.
> >
> > After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration
> > immediately when handling the link-up IRQ, and devices (e.g., Laszlo
> > Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config
> > requests yet.
> >
> > Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting
> > enumeration.
> >
> > Reviewed-by: Damien Le Moal <dlemoal@xxxxxxxxxx>
> > Reviewed-by: Wilfred Mallawa <wilfred.mallawa@xxxxxxx>
> > Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
>
> Shouldn't 36971d6c5a9a be the fixes commit?
See Bjorn's comment:
https://lore.kernel.org/linux-pci/20250611211456.GA869983@bhelgaas/
I would argue that 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip
RK356X host controller driver") is the right Fixes: commit here
because dw_pcie_wait_for_link() *never* waited the required time, and
it's quite possible that other devices don't work correctly. The
delay was about 90ms - <time required for link training>, so could be
significantly less than 100ms.
Thus, following Bjorn's comment, to put the commit that introduced the driver
as the Fixes tag for dw-rockchip, I did the same thing for qcom.
Kind regards,
Niklas
