linux-kernel - Re: [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC systems

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

Message-ID: <20251203142743.GD2580184@black.igk.intel.com>
Date: Wed, 3 Dec 2025 15:27:43 +0100
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: Brian Norris <briannorris@...omium.org>,
	Bjorn Helgaas <helgaas@...nel.org>,
	René Rebe <rene@...ctco.de>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	Riccardo Mottola <riccardo.mottola@...ero.it>,
	Manivannan Sadhasivam <mani@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC
 systems

Hi,

On Wed, Dec 03, 2025 at 05:49:37AM +0100, Lukas Wunner wrote:
> [cc += Mika]
> 
> On Tue, Dec 02, 2025 at 01:54:00PM -0800, Brian Norris wrote:
> > I wonder if we could take a different approach that helps straddle the
> > uncertain boundary here a bit:
> [...]
> >  2) be less aggressive about default-enabling runtime suspend / D3
> >  (i.e., only call pm_runtime_allow() in drivers/pci/pcie/portdrv.c in
> >  limited circumstances).
> [...]
> > So instead of portdrv.c calling pm_runtime_allow(), we'd leave that
> > decision to user space (i.e., udev or similar). That will help limit the
> > impact of getting #1 "wrong." And it's possible the bad systems didn't
> > really want aggressive PM anyway, so it's not worth much trouble.
> 
> I think runtime PM support in the PCIe port driver was primarily
> motivated by the need to power down Thunderbolt controllers when
> they're not in use.

That and also there are discrete GPUs that can runtime suspend when not in
use.

> A Thunderbolt controller exposes a PCIe switch.  Daisy-chained
> Thunderbolt devices are thus visible to the OS as nested switches.
> If we followed the approach you're suggesting, users would have to
> manually allow runtime PM on every Switch Upstream and Downstream Port
> as well as the Root Port and they'd have to do that upon hotplugging
> a device.  Yes, yes, users could add a udev rule to allow runtime PM
> automatically by default, but that's exactly the policy we have hardcoded
> in the kernel right now, so why the change?
> 
> I expect massive power regressions for users (not least Chromebook
> users) if we made that change.
> 
> The discrete Thunderbolt controller in my machine consumes 1.5W
> when nothing is attached.  Some laptops have multiple of these.
> Recent CPUs with integrated Thunderbolt/USB4 may fail to transition
> the package to a low power state unless the Thunderbolt ports go
> to D3hot.
> 
> So I don't think this approach is a viable option.

I agree.  If this is limited to some older RISC machines (based on the
$subject) perhaps this could be solved by adding udev rules to block
runtime PM on those certain ports?