Re: [PATCH v2 1/5] PCI: host-common: Add helper to determine host bridge D3cold eligibility

[Rafael J. Wysocki]

On Mon, Feb 23, 2026 at 8:55 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
>
> On Mon, Feb 23, 2026 at 07:46:08PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Feb 23, 2026 at 7:10 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > > On Tue, Feb 17, 2026 at 04:49:06PM +0530, Krishna Chaitanya Chundru wrote:
> > > > Add a common helper, pci_host_common_can_enter_d3cold(), to determine
> > > > whether a PCI host bridge can safely transition to D3cold.
> > > >
> > > > This helper is intended to be used by PCI host controller drivers to
> > > > decide whether they may safely put the host bridge into D3cold based on
> > > > the power state and wakeup capabilities of downstream endpoints.
> > > >
> > > > The helper walks all devices on the bridge's primary bus and only allows
> > > > the host bridge to enter D3cold if all PCIe endpoints are already in
> > > > PCI_D3hot. This ensures that we do not power off the host bridge while
> > > > any active endpoint still requires the link to remain powered.
> > > >
> > > > For devices that may wake the system, the helper additionally requires
> > > > that the device supports PME wake from D3cold (via WAKE#). Devices that
> > > > do not have wakeup enabled are not restricted by this check and do not
> > > > block the host bridge from entering D3cold.
> > > >
> > > > Devices without a bound driver and with PCI not enabled via sysfs are
> > > > treated as inactive and therefore do not prevent the host bridge from
> > > > entering D3cold. This allows controllers to power down more aggressively
> > > > when there are no actively managed endpoints.
> > >
> > > This series is currently structured so it's only applicable to native
> > > host bridge drivers, i.e., things using DT.  Is there anything that
> > > prevents using D3cold for host bridges in ACPI systems?
> >
> > Do you mean in principle or in practice?
>
> Just in principle.  I was hoping for some way to tie this decision
> making back to a spec.  Everything downstream being in D3 already, and
> any wakeup devices supporting PME from D3cold sounds plausible to me,
> but I don't know about any prescriptive spec language, and I wouldn't
> want to get locked into a scheme that couldn't be supported on ACPI.

In principle, I guess someone might want to add ACPI PM support to a
PCI host bridge device object.

In theory, there may be a problem with message-based PME wakeup unless
the host bridge device has some D3cold aux power, but it at least
seems to be doable.

I think that this question is for non-x86 folks who use ACPI in their
platforms because they may just have this use case.