Re: [PATCH 3/3] PCI / ACPI: Handle sibling devices sharing power resources

Mika Westerberg
2019-06-06T11:26:46Z

On Thu, Jun 06, 2019 at 10:54:40AM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 5, 2019 at 4:58 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Intel Ice Lake has an interated Thunderbolt controller which means that
>
> integrated

Right :)

> > the PCIe topology is extended directly from the two root ports (RP0 and
> > RP1). Power management is handled by ACPI power resources that are
> > shared between the root ports, Thunderbolt controller (NHI) and xHCI
> > controller.
> >
> > The topology with the power resources (marked with []) looks like:
> >
> > Host bridge
> > |
> > +- RP0 ---\
> > +- RP1 ---|--+--> [TBT]
> > +- NHI --/ |
> > | |
> > | v
> > +- xHCI --> [D3C]
> >
> > Here TBT and D3C are the shared ACPI power resources. ACPI _PR3() method
> > returns either TBT or D3C or both.
> >
> > Say we runtime suspend first the root ports RP0 and RP1, then NHI. Now
> > since the TBT power resource is still on when the root ports are runtime
> > suspended their dev->current_state is set to D3hot. When NHI is runtime
> > suspended TBT is finally turned off but state of the root ports remain
> > to be D3hot.
>
> It looks like this problem will affect all ACPI devices using power
> resources and _PR3 in general, so fixing it just for PCI is not
> sufficient IMO.

Fair enough.

> An alternative approach may be to set the state of a device that
> dropped its references to power resources listed in _PR3 to D3cold
> even though those power resources may be physically "on" at that time.
> Everything else (including this patch AFAICS) will be racy this way or
> another.

OK, thanks for the comment. I'll try to look into this approach then.