public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "David E. Box" <david.e.box@linux.intel.com>,
	rafael@kernel.org, bhelgaas@google.com,
	vicamo.yang@canonical.com, kenny@panix.com,
	ilpo.jarvinen@linux.intel.com, nirmal.patel@linux.intel.com,
	linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default ASPM/CLKPM link state
Date: Wed, 3 Sep 2025 17:55:27 -0500	[thread overview]
Message-ID: <20250903225527.GA1236657@bhelgaas> (raw)
In-Reply-To: <2fo64esrc5v5vj46iff2ptgcthaeahwicuzug46popwqrryfsi@yt62sqsnv4e3>

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?

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.

  reply	other threads:[~2025-09-03 22:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25 20:35 [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default ASPM/CLKPM link state David E. Box
2025-08-25 20:35 ` [PATCH V3 2/2] PCI: vmd: Use pci_host_set_default_pcie_link_state() to set ASPM defaults David E. Box
2025-08-28 20:43 ` [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default ASPM/CLKPM link state Bjorn Helgaas
2025-08-29 19:54   ` David Box
2025-09-03 23:04     ` Bjorn Helgaas
2025-09-04 16:02       ` David Box
2025-09-04 16:35         ` Manivannan Sadhasivam
2025-08-31 12:58   ` Manivannan Sadhasivam
2025-09-03 22:55     ` Bjorn Helgaas [this message]
2025-09-04 16:45       ` Manivannan Sadhasivam
2025-09-04 17:11         ` Bjorn Helgaas
2025-09-04 17:16           ` Kenneth Crudup
2025-09-24  6:12             ` Manivannan Sadhasivam
2025-10-06 19:42               ` Kenneth Crudup
2025-09-04 21:11 ` Kenneth Crudup
2025-09-22 18:38   ` Kenneth Crudup
2025-09-04 21:12 ` Kenneth Crudup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250903225527.GA1236657@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=david.e.box@linux.intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=kenny@panix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=nirmal.patel@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=vicamo.yang@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox