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

Rafael J. Wysocki
2019-06-19T13:24:53Z

On Tue, Jun 18, 2019 at 6:19 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi all,
>
> Based on a discussion regarding patch series I sent previously [1] to deal
> with sibling devices sharing ACPI power resources, I prepared a new
> reworked version according to the comments I got.
>
> To summarize, in Intel Ice Lake the Thunderbolt controller, PCIe root ports
> and xHCI all share power resources. When they are all in D3hot power
> resources (returned by _PR3) can be turned off powering off the whole
> block. However, there are two issues around this.
>
> Firstly the PCI core sets the device power state by asking what the real
> ACPI power state is. This results that all but last device sharing the
> power resources are in D3hot when the power resources are turned off. This
> causes issues if user runs for example 'lspci' because the device is really
> in D3cold so what user gets back is all ones (0xffffffff).
>
> Secondly if any of the device is runtime resumed the power resources are
> turned on bringing all other devices sharing the resources to
> D0uninitialized losing their wakeup configuration.
>
> This series aims to fix the two issues by:
>
> 1. Using the ACPI cached power state when PCI devices are transitioned
> into low power states instead of reading back the "real" power state.
>
> 2. Introducing concept of "_PR0 dependent devices" that get runtime
> resumed whenever their power resource (which they might share with
> other sibling devices) gets turned on.
>
> The series is based on the idea of Rafael J. Wysocki <rafael@kernel.org>.
>
> [1] https://www.spinics.net/lists/linux-pci/msg83583.html
>
> Mika Westerberg (3):
> PCI / ACPI: Use cached ACPI device state to get PCI device power state
> ACPI / PM: Introduce concept of a _PR0 dependent device
> PCI / ACPI: Add _PR0 dependent devices

LGMT overall, patch [2/3] can be simplified slightly IMO (already sent
comments for that one).

As far as I'm concerned, the other patches need not be updated.