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

Message-ID: <CAJZ5v0jr9LQcnbS_VxwgRvSqb3ULwJZOcNYYCTMJ=t5GUrsjRg@mail.gmail.com>
Date: Wed, 3 Dec 2025 18:16:19 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: René Rebe <rene@...ctco.de>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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

On Wed, Dec 3, 2025 at 4:26 PM René Rebe <rene@...ctco.de> wrote:
>
> 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?

Yes, you can do this, as far as I'm concerned.