linux-kernel - Re: [PATCH v2 1/2] PCI/ASPM: Override the ASPM and Clock PM states set by BIOS for devicetree platforms

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-prev] [day] [month] [year] [list]

Message-ID: <20251017134554.GA1027663@bhelgaas>
Date: Fri, 17 Oct 2025 08:45:54 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Shawn Lin <shawn.lin@...k-chips.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
	Niklas Cassel <cassel@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Rob Herring <robh@...nel.org>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	"David E. Box" <david.e.box@...ux.intel.com>,
	Kai-Heng Feng <kai.heng.feng@...onical.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Chia-Lin Kao <acelan.kao@...onical.com>,
	Dragan Simic <dsimic@...jaro.org>,
	linux-rockchip@...ts.infradead.org, regressions@...ts.linux.dev,
	FUKAUMI Naoki <naoki@...xa.com>
Subject: Re: [PATCH v2 1/2] PCI/ASPM: Override the ASPM and Clock PM states
 set by BIOS for devicetree platforms

On Fri, Oct 17, 2025 at 06:24:26PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Oct 17, 2025 at 08:19:11PM +0800, Shawn Lin wrote:
> > 在 2025/10/17 星期五 18:04, Manivannan Sadhasivam 写道:
> > > On Fri, Oct 17, 2025 at 05:47:44PM +0800, Shawn Lin wrote:
> ...

> > > > While we're on the topic of ASPM, may I ask a silly question?
> > > > I saw the ASPM would only be configured once the function
> > > > driver calling pci_enable_device. So if the modular driver
> > > > hasn't been insmoded, the link will be in L0 even though there
> > > > is no transcation on-going. What is the intention behind it?
> > > 
> > > I don't see where ASPM is configured during pci_enable_device().
> > > It is currently configured for all devices during
> > > pci_scan_slot().
> > 
> > This is the dump_stack() where I observed. If I compile NVMe
> > driver as a module and never insmod it, the link is always in L0,
> > namely ASPM Disabled.
> 
> I guess this comment answers your question:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pcie/aspm.c?h=v6.18-rc1#n1179

The comment is:

   * At this stage drivers haven't had an opportunity to change the
   * link policy setting. Enabling ASPM on broken hardware can cripple
   * it even before the driver has had a chance to disable ASPM, so
   * default to a safe level right now. If we're enabling ASPM beyond
   * the BIOS's expectation, we'll do so once pci_enable_device() is
   * called.

I don't think relying on a driver to disable ASPM to avoid broken
hardware is the right answer.  If the driver is never loaded, we waste
power.  And if the user enables ASPM via sysfs, apparently the device
may be crippled.

I think it would be better to have an enumeration-time quirk to keep
us from enabling ASPM.  We might trip over some of this broken
hardware, but I don't think there are very many drivers that fiddle
with ASPM, so we should be able to be proactive about it.

> But with the recent ASPM change, the ASPM settings for DT platforms
> will be applied before pci_enable_device(). Also, the comment is
> somewhat outdated as we generally do not want PCI client drivers to
> enable/disable ASPM nowadays. They can however do it under specific
> circumstances.