From: "David E. Box" <david.e.box@linux.intel.com>
To: rafael@kernel.org, bhelgaas@google.com,
vicamo.yang@canonical.com, kenny@panix.com,
ilpo.jarvinen@linux.intel.com, nirmal.patel@linux.intel.com
Cc: "David E. Box" <david.e.box@linux.intel.com>,
linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [RFC 0/2] PCI/ASPM: Allow controller-defined default link state
Date: Wed, 16 Jul 2025 17:40:24 -0700 [thread overview]
Message-ID: <20250717004034.2998443-1-david.e.box@linux.intel.com> (raw)
Hi all,
This RFC series addresses a limitation in the PCIe ASPM subsystem where
devices on synthetic PCIe hierarchies, such as those created by Intel’s
Volume Management Device (VMD), do not receive default ASPM settings
because they are not visible to firmware. As a result, ASPM remains
disabled on these devices unless explicitly enabled later by the driver,
contrary to platform power-saving expectations.
Problem with Current Behavior
Today, ASPM default policy is set in pcie_aspm_cap_init() based on values
provided by BIOS. For devices under VMD, BIOS has no visibility into the
hierarchy, and therefore no ASPM defaults are applied. The VMD driver can
attempt to walk the bus hierarchy and enable ASPM post-init using runtime
mechanisms, but this fails when aspm_disabled is set because the kernel
intentionally blocks runtime ASPM changes under ACPI’s FADT_NO_ASPM flag.
However, this flag does not apply to VMD, which controls its domain
independently of firmware.
Goal
The ideal solution is to allow VMD or any controller driver managing a
synthetic hierarchy to provide a default ASPM link state at the same time
it's set for BIOS, in pcie_aspm_cap_init().
Solution
1. A new bus flag, PCI_BUS_FLAGS_ASPM_DEFAULT_OVERRIDE, based on Rafael's
suggestion, to signal that the driver intends to override the default ASPM
setting. 2. A new field, aspm_bus_link_state, in 'struct pci_bus' to supply
the desired default link state using the existing PCIE_LINK_STATE_XXX
bitmask.
If the flag is set, the ASPM core uses the driver-supplied value in place
of the firmware one. If not, behavior is unchanged.
Only the immediate parent bus is checked for this flag. If future use cases
require deeper inheritance (e.g., through PCIe switches), the logic can be
extended to walk the bus hierarchy.
This approach avoids adding driver-specific logic to ASPM core code and
keeps the layering clean.
Testing is appreciated as I didn't get a chance to do so yet but plan to.
Thanks, David
---
David E. Box (2):
PCI/ASPM: Allow drivers to provide ASPM link state via pci_bus
PCI: vmd: Provide default ASPM link state for synthetic hierarchy
drivers/pci/controller/vmd.c | 7 +++++--
drivers/pci/pcie/aspm.c | 5 ++++-
include/linux/pci.h | 12 ++++++++----
3 files changed, 17 insertions(+), 7 deletions(-)
base-commit: d0b3b7b22dfa1f4b515fd3a295b3fd958f9e81af
--
2.43.0
next reply other threads:[~2025-07-17 0:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 0:40 David E. Box [this message]
2025-07-17 0:40 ` [RFC 1/2] PCI/ASPM: Allow drivers to provide ASPM link state via pci_bus David E. Box
2025-07-17 10:00 ` Rafael J. Wysocki
2025-07-17 0:40 ` [RFC 2/2] PCI: vmd: Provide default ASPM link state for synthetic hierarchy David E. Box
2025-07-17 6:12 ` [RFC 0/2] PCI/ASPM: Allow controller-defined default link state Kenneth R. Crudup
2025-07-17 6:57 ` Manivannan Sadhasivam
2025-07-17 14:03 ` David Box
2025-07-17 6:55 ` Manivannan Sadhasivam
2025-07-17 10:03 ` Rafael J. Wysocki
2025-07-17 14:13 ` David Box
2025-07-17 15:37 ` Rafael J. Wysocki
2025-07-17 17:49 ` David Box
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=20250717004034.2998443-1-david.e.box@linux.intel.com \
--to=david.e.box@linux.intel.com \
--cc=bhelgaas@google.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=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;
as well as URLs for NNTP newsgroup(s).