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: <aS_BYeSApI2XuPcD@wunner.de>
Date: Wed, 3 Dec 2025 05:49:37 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Brian Norris <briannorris@...omium.org>
Cc: 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>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC
 systems

[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.

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.

Thanks,

Lukas