Re: [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default ASPM/CLKPM link state

[Bjorn Helgaas <helgaas@kernel.org>]

On Thu, Sep 04, 2025 at 10:15:44PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Sep 03, 2025 at 05:55:27PM GMT, Bjorn Helgaas wrote:
> > On Sun, Aug 31, 2025 at 06:28:53PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Aug 28, 2025 at 03:43:45PM GMT, Bjorn Helgaas wrote:
> > > > On Mon, Aug 25, 2025 at 01:35:22PM -0700, David E. Box wrote:
> > > > > Synthetic PCIe hierarchies, such as those created by Intel VMD, are not
> > > > > enumerated by firmware and do not receive BIOS-provided ASPM or CLKPM
> > > > > defaults. Devices in such domains may therefore run without the intended
> > > > > power management.
> > > > > 
> > > > > Add a host-bridge mechanism that lets controller drivers supply their own
> > > > > defaults. A new aspm_default_link_state field in struct pci_host_bridge is
> > > > > set via pci_host_set_default_pcie_link_state(). During link initialization,
> > > > > if this field is non-zero, ASPM and CLKPM defaults come from it instead of
> > > > > BIOS.
> > > > > 
> > > > > This enables drivers like VMD to align link power management with platform
> > > > > expectations and avoids embedding controller-specific quirks in ASPM core
> > > > > logic.
> > > > 
> > > > I think this kind of sidesteps the real issue.  Drivers for host
> > > > controllers or PCI devices should tell us about *broken* things, but
> > > > not about things advertised by the hardware and available for use.
> > > > 
> > > > The only documented policy controls I'm aware of for ASPM are:
> > > > 
> > > >   - FADT "PCIe ASPM Controls" bit ("if set, OS must not enable ASPM
> > > >     control on this platform")
> > > > 
> > > >   - _OSC negotiation for control of the PCIe Capability (OS is only
> > > >     allowed to write PCI_EXP_LNKCTL if platform has granted control to
> > > >     the OS)
> > > > 
> > > > I think what we *should* be doing is enabling ASPM when it's
> > > > advertised, subject to those platform policy controls and user choices
> > > > like CONFIG_PCIEASPM_PERFORMANCE/POWERSAVE/etc and sysfs attributes.
> > > > 
> > > > So basically I think link->aspm_default should be PCIE_LINK_STATE_ALL
> > > > without drivers doing anything at all.  Maybe we have to carve out
> > > > exceptions, e.g., "VMD hierarchies are exempt from _OSC," or "devices
> > > > on x86 systems before 2026 can't enable more ASPM than BIOS did," or
> > > > whatever.  Is there any baby step we can make in that direction?
> > > 
> > > I'm not sure about the ACPI world, but for devicetree platforms,
> > > BIOS or the bootloader won't configure ASPM for the devices
> > > (mostly). So the baby step would be to set PCIE_LINK_STATE_ALL for
> > > all devicetree platforms :)
> > 
> > Yes.  How likely would this be to break something?
> 
> I don't know :) If we want to bite the bullet, let's do it.
> Otherwise, let's keep waiting for the time to come ;) For sure there
> will be breakages reported, but it won't be like on x86 which people
> use for day to day work.  There are IBM Power and MIPS based servers
> using devicetree as well, so they might also get impacted.
> 
> But it would be the optimal test bed if we ever want to start
> enabling ASPM by default.
> 
> > Before doing that, I think we need to add some logging, at least
> > at pci_dbg(), of what is already enabled and what we change, so we
> > have some kind of hint when things do break.
> 
> Sure. Even if we want to make it pci_info(), I think it would be
> worth doing it as it will make the reporting much easier.
> 
> Let me know if I can proceed with this.

Yes, I think so.  I would likely target v6.19 for upstream to give us
more time, but if we can get in -next for a bit now, that would be
great.