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: <CAJZ5v0ighf93oi7peW7jRf4XsvBQe3ryLcnFqkL7aWN5TmBqsw@mail.gmail.com>
Date: Wed, 3 Dec 2025 16:22:03 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: René Rebe <rene@...ctco.de>
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>, 
	"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

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;