Message-ID: <a47sg5ahflhvzyzqnfxvpk3dw4clkhqlhznjxzwqpf4nyjx5dk@bcghz5o6zolk>
Date: Thu, 4 Sep 2025 22:15:44 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: "David E. Box" <david.e.box@...ux.intel.com>, rafael@...nel.org, 
	bhelgaas@...gle.com, vicamo.yang@...onical.com, kenny@...ix.com, 
	ilpo.jarvinen@...ux.intel.com, nirmal.patel@...ux.intel.com, linux-pm@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default
 ASPM/CLKPM link state

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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists