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: <E5E42CF4-7D6B-4081-AD59-CAC09FCB1890@exactco.de>
Date: Wed, 3 Dec 2025 15:48:26 +0100
From: René Rebe <rene@...ctco.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Lukas Wunner <lukas@...ner.de>,
 Brian Norris <briannorris@...omium.org>,
 Bjorn Helgaas <helgaas@...nel.org>,
 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 3. Dec 2025, at 15:27, Mika Westerberg <mika.westerberg@...ux.intel.com> wrote:

…

>> 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?

Let’s not overcomplicate it for now. All we have are a couple of old Unix
RISC workstations. Let’s see if we can somehow fix them for real first.

Given the feedback that D3Hot “should” more often work I went ahead
and changed the patch in T2/Linux removing the 2015 check and all arch
except SPARC and let our prosumer enthusiast users find out if something
else breaks first to gather more data points.

I’ll try to find time to debug the SPARC64 Sun Blade 1K issue, but I have
some other TODO first, so it might be January for more work on that.

Maybe we should push a patch to only disable this for SPARC64 to stable
In the meantime?

https://svn.exactcode.de/t2/trunk/package/kernel/linux/hotfix-legacy-pci-bridge-d3.patch

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 2b53219fda3b..869d204a70a3 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3067,10 +3067,9 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
 			return false;

 		/*
-		 * Out of caution, we only allow PCIe ports from 2015 or newer
-		 * into D3 on x86.
+		 * It should be safe to put PCIe ports to D3.
 		 */
-		if (!IS_ENABLED(CONFIG_X86) || dmi_get_bios_year() >= 2015)
+		if (!IS_ENABLED(CONFIG_SPARC64))
 			return true;
 		break;
 	}

	René

-- 
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe