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: <A6C6B078-16D7-4BBB-8E9C-3F599EADF84C@exactco.de>
Date: Wed, 3 Dec 2025 16:26:50 +0100
From: René Rebe <rene@...ctco.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>,
 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>,
 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 16:22, Rafael J. Wysocki <rafael@...nel.org> wrote:
> 
> On Wed, Dec 3, 2025 at 3:48 PM René Rebe <rene@...ctco.de> wrote:
>> 
>> 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;
>>        }
> 
> I would prefer
> 
> if ((IS_ENABLED(CONFIG_X86) && dmi_get_bios_year() >= 2015) ||
> !IS_ENABLED(CONFIG_SPARC64))
>         return true;

Sorry for any confusion, I did not mean the above for upstream, but as I
tried to express for us downstream in T2 to gather more data (if any) from
our users for for pre 2015 x86 machines.

Should I send your proposal which matches mine for stable in the
meantime?

	René

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