Re: [PATCH] Revert "PCI: qcom: Remove custom ASPM enablement code"

[Bjorn Helgaas]

On Sun, Oct 26, 2025 at 08:58:29PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Oct 24, 2025 at 04:04:57PM -0500, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > 
> > This reverts commit a729c16646198872e345bf6c48dbe540ad8a9753.
> > 
> > Prior to a729c1664619 ("PCI: qcom: Remove custom ASPM enablement code"),
> > the qcom controller driver enabled ASPM, including L0s, L1, and L1 PM
> > Substates, for all devices powered on at the time the controller driver
> > enumerates them.
> > 
> > ASPM was *not* enabled for devices powered on later by pwrctrl (unless the
> > kernel was built with PCIEASPM_POWERSAVE or PCIEASPM_POWER_SUPERSAVE, or
> > the user enabled ASPM via module parameter or sysfs).
> > 
> > After f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for
> > devicetree platforms"), the PCI core enabled all ASPM states for all
> > devices whether powered on initially or by pwrctrl, so a729c1664619 was
> > unnecessary and reverted.
> > 
> > But f3ac2ff14834 was too aggressive and broke platforms that didn't support
> > CLKREQ# or required device-specific configuration for L1 Substates, so
> > df5192d9bb0e ("PCI/ASPM: Enable only L0s and L1 for devicetree platforms")
> > enabled only L0s and L1.
> > 
> > On Qualcomm platforms, this left L1 Substates disabled, which was a
> > regression.  Revert a729c1664619 so L1 Substates will be enabled on devices
> > that are initially powered on.  Devices powered on by pwrctrl will be
> > addressed later.
> 
> Can we rather have platform specific APIs [1] to enable ASPM states
> instead of just re-introducing this half-baked solution? (yes, I
> introduced it, but it is still imperfect).

I intend this (reverting "PCI: qcom: Remove custom ASPM enablement
code") for v6.18 to avoid regressing Qualcomm: v6.17 enabled L1 PM
Substates, and v6.18-rc3 does not.

Adding pci_host_set_default_pcie_link_state() with [1] (along with a
follow-up qcom patch using it) is another possible way to enable L1 PM
Substates, but I think the revert is the safest post-merge window
regression fix.

I have some heartburn about both the revert and the
pci_host_set_default_pcie_link_state() approach because they apply to
the entire hierarchy under a qcom or VMD root port, potentially
including add-in cards with switches.  CLKREQ# (and possibly more) is
required to enable L1SS, and I don't know if we can assume it's
supported on add-in links.

> I think we have learned by hard way that enabling ASPM by default
> can have catastrophic effects for reasons we do not certainly know.
> So how about having this platform specific API that enables
> individual platforms to enable the ASPM states?

As far as I know, it's L1SS that has catastrophic effects.  I haven't
seen anything for L0s or L1.

> [1]
> https://lore.kernel.org/linux-pci/20250825203542.3502368-1-david.e.box@xxxxxxxxxxxxxxx/