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.
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.