Re: [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC systems

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Wed, Dec 03, 2025 at 05:49:37AM +0100, Lukas Wunner wrote:
> [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.

That and also there are discrete GPUs that can runtime suspend when 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.

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?