Re: [PATCH v2 0/4] PCI/ASPM: Allow quirks to avoid L0s and L1
From: Bjorn Helgaas <helgaas@kernel.org>
Date: 2025-11-11 15:44:46
Also in:
linux-pci, lkml
On Tue, Nov 11, 2025 at 10:33:43AM +0100, Lukas Wunner wrote:
On Mon, Nov 10, 2025 at 04:22:24PM -0600, Bjorn Helgaas wrote:quoted
We enabled ASPM too aggressively in v6.18-rc1. f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") enabled ASPM L0s, L1, and (if advertised) L1 PM Substates. df5192d9bb0e ("PCI/ASPM: Enable only L0s and L1 for devicetree platforms") (v6.18-rc3) backed off and omitted Clock PM and L1 Substates because we don't have good infrastructure to discover CLKREQ# support, and L1 Substates may require device-specific configuration. L0s and L1 are generically discoverable and should not require device-specific support, but some devices advertise them even though they don't work correctly. This series is a way to add quirks avoid L0s and L1 in this case.Reviewed-by: Lukas Wunner <lukas@wunner.de>
Thanks!
I note that a number of drivers call pci_disable_link_state() or pci_disable_link_state_locked() to disable ASPM on probe. Can we convert (all of) these to quirks which use the new helper introduced here? I think that would be useful because it would disable ASPM even if the driver isn't available and thus avoid e.g. AER messages caused by ASPM issues. pcie_aspm_init_link_state() also contains the following code comment: /* * At this stage drivers haven't had an opportunity to change the * link policy setting. Enabling ASPM on broken hardware can cripple * it even before the driver has had a chance to disable ASPM, so * default to a safe level right now. If we're enabling ASPM beyond * the BIOS's expectation, we'll do so once pci_enable_device() is * called. */ If we'd mask out incorrect or non-working L0s/L1 capabilities for all devices early during enumeration via quirks, we wouldn't have to go through these contortions of setting up deeper ASPM states only at device enable time.
I definitely agree. I forgot to follow up on all of those cases. There aren't that many of them, but it looks like probably too many to address for v6.18, and I *think* it's safe to wait and deal with them for v6.19. Bjorn