linux-kernel - [RFC 0/2] PCI/ASPM: Allow controller-defined default link state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250717004034.2998443-1-david.e.box@linux.intel.com>
Date: Wed, 16 Jul 2025 17:40:24 -0700
From: "David E. Box" <david.e.box@...ux.intel.com>
To: rafael@...nel.org,
	bhelgaas@...gle.com,
	vicamo.yang@...onical.com,
	kenny@...ix.com,
	ilpo.jarvinen@...ux.intel.com,
	nirmal.patel@...ux.intel.com
Cc: "David E. Box" <david.e.box@...ux.intel.com>,
	linux-pm@...r.kernel.org,
	linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [RFC 0/2] PCI/ASPM: Allow controller-defined default link state

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