Re: [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Jun 18, 2019 at 07:18:56PM +0300, Mika Westerberg wrote:
> Intel Ice Lake has an integrated Thunderbolt controller which means that
> the PCIe topology is extended directly from the two root ports (RP0 and
> RP1).

A PCIe topology is always extended directly from root ports,
regardless of whether a Thunderbolt controller is integrated, so I
guess I'm missing the point you're making.  It doesn't sound like this
is anything specific to Thunderbolt?

> 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.
> 
> If the user now runs lspci for instance, the result is all 1's like in
> the below output (07.0 is the first root port, RP0):
> 
> 00:07.0 PCI bridge: Intel Corporation Device 8a1d (rev ff) (prog-if ff)
>     !!! Unknown header type 7f
>     Kernel driver in use: pcieport
> 
> I short the hardware state is not in sync with the software state
> anymore. The exact same thing happens with the PME polling thread which
> ends up bringing the root ports back into D0 after they are runtime
> suspended.

s/I /In /