On Tue, Jun 25, 2019 at 02:06:13PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > If a device with ACPI PM is left in D0 during a system-wide > transition to the S3 (suspend-to-RAM) or S4 (hibernation) sleep > state, the actual state of the device need not be D0 during resume > from it, although its power.state value will still reflect D0 (that > is, the power state from before the system-wide transition). > > In that case, the acpi_device_set_power() call made to ensure that > the power state of the device will be D0 going forward has no effect, > because the new state (D0) is equal to the one reflected by the > device's power.state value. That does not affect power resources, > which are taken care of by acpi_resume_power_resources() called from > acpi_pm_finish() during resume from system-wide sleep states, but it > still may be necessary to invoke _PS0 for the device on top of that > in order to finalize its transition to D0. > > For this reason, modify acpi_device_set_power() to allow transitions > to D0 to occur even if D0 is the current power state of the device > according to its power.state value. > > That will not affect power resources, which are assumed to be in > the right configuration already (as reflected by the current values > of their reference counters), but it may cause _PS0 to be evaluated > for the device. However, evaluating _PS0 for a device already in D0 > may lead to confusion in general, so invoke _PSC (if present) to > check the device's current power state upfront and only evaluate > _PS0 for it if _PSC has returned a power state different from D0. > [If _PSC is not present or the evaluation of it fails, the power > state of the device is assumed to be D0 at this point.] > > Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
