Thread (149 messages) flat view 149 messages, 20 authors, 2025-11-13

Re: [PPC] Boot problems after the pci-v6.18-changes

From: Bjorn Helgaas <helgaas@kernel.org>
Date: 2025-11-06 18:25:12
Also in: linux-pci, regressions

On Thu, Nov 06, 2025 at 08:48:16AM +0000, Hongxing Zhu wrote:
...
I tested these patches on i.MX95 EVK board with NVME storage device.
Because that i.MX95 PCIe RC failed enter into L2 when one NVME
device is connected to the port if ASPM L1 is enabled in default.

These patches work as expected, the l0s and l1 can be disabled after
adding the following quirk.

"DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PHILIPS, PCI_ANY_ID,
quirk_disable_aspm_l0s_l1_cap);"
Thanks for trying this out.

So if I understand correctly, the i.MX95 Root Port has
PCI_VENDOR_ID_PHILIPS, and if ASPM L1 is enabled on its link, the link
doesn't go to L2 when suspending?  But it *does* go to L2 on suspend
if L1 is disabled?

I wonder if the issue is with the RC or with the NVMe device.  The
comments in dw_pcie_suspend_noirq() and qcom_pcie_suspend_noirq() make
me wonder if there's something weird about NVMe and L2.

I assume you don't want to disable L0s and L1 for *all* devices with
PCI_VENDOR_ID_PHILIPS though.  Aren't there endpoints with that ID
that can use L0s and L1?

And I suppose the best thing would be if we could enable L0s and L1,
but turn them off before suspending?  That would require something
different, like something in imx_pcie_suspend_noirq() or a
DECLARE_PCI_FIXUP_SUSPEND() quirk.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help