kernel/linux.git/drivers/acpi/device_pm.c, branch v4.9.331

ACPI: PM: Avoid using power resources if there are none for D0

2020-06-20T08:24:09+00:00

commit 956ad9d98b73f59e442cc119c98ba1e04e94fe6d upstream. As recently reported, some platforms provide a list of power resources for device power state D3hot, through the _PR3 object, but they do not provide a list of power resources for device power state D0. Among other things, this causes acpi_device_get_power() to return D3hot as the current state of the device in question if all of the D3hot power resources are "on", because it sees the power_resources flag set and calls acpi_power_get_inferred_state() which finds that D3hot is the shallowest power state with all of the associated power resources turned "on", so that's what it returns. Moreover, that value takes precedence over the acpi_dev_pm_explicit_get() return value, because it means a deeper power state. The device may very well be in D0 physically at that point, however. Moreover, the presence of _PR3 without _PR0 for a given device means that only one D3-level power state can be supported by it. Namely, because there are no power resources to turn "off" when transitioning the device from D0 into D3cold (which should be supported since _PR3 is present), the evaluation of _PS3 should be sufficient to put it straight into D3cold, but this means that the effect of turning "on" the _PR3 power resources is unclear, so it is better to avoid doing that altogether. Consequently, there is no practical way do distinguish D3cold from D3hot for the device in question and the power states of it can be labeled so that D3hot is the deepest supported one (and Linux assumes that putting a device into D3hot via ACPI may cause power to be removed from it anyway, for legacy reasons). To work around the problem described above modify the ACPI enumeration of devices so that power resources are only used for device power management if the list of D0 power resources is not empty and make it mart D3cold as supported only if that is the case and the D3hot list of power resources is not empty too. Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057 Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/ Reported-by: Hans de Goede Tested-by: Hans de Goede Tested-by: youling257@gmail.com Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

PM: ACPI: Output correct message on target power state

2020-05-05T17:14:36+00:00

commit a9b760b0266f563b4784f695bbd0e717610dc10a upstream. Transitioned power state logged at the end of setting ACPI power. However, D3cold won't be in the message because state can only be D3hot at most. Use target_state to corretly report when power state is D3cold. Cc: All applicable Signed-off-by: Kai-Heng Feng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: PM: Avoid attaching ACPI PM domain to certain devices

2019-12-21T09:42:06+00:00

commit b9ea0bae260f6aae546db224daa6ac1bd9d94b91 upstream. Certain ACPI-enumerated devices represented as platform devices in Linux, like fans, require special low-level power management handling implemented by their drivers that is not in agreement with the ACPI PM domain behavior. That leads to problems with managing ACPI fans during system-wide suspend and resume. For this reason, make acpi_dev_pm_attach() skip the affected devices by adding a list of device IDs to avoid to it and putting the IDs of the affected devices into that list. Fixes: e5cc8ef31267 (ACPI / PM: Provide ACPI PM callback routines for subsystems) Reported-by: Zhang Rui Tested-by: Todd Brandt Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Export acpi_device_fix_up_power()

2016-05-20T13:54:01+00:00

Drivers that needs acpi_device_fix_up_power(), allow them to be built as modules by exporting this function. Cc: # 4.5+ Tested-by: Laszlo Fiat Signed-off-by: Ulf Hansson Acked-by: Rafael J. Wysocki

PM / Domains: add setter for dev.pm_domain

2016-01-08T00:12:06+00:00

Adds a function that sets the pointer to dev_pm_domain in struct device and that warns if the device has already finished probing. The reason why we want to enforce that is because in the general case that can cause problems and also that we can simplify code quite a bit if we can always assume that. This patch also changes all current code that directly sets the dev.pm_domain pointer. Signed-off-by: Tomeu Vizoso Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / PCI / ACPI: Kick devices that might have been reset by firmware

2015-10-14T00:17:34+00:00

There is a concern that if the platform firmware was involved in the system resume that's being completed, some devices might have been reset by it and if those devices had the power.direct_complete flag set during the preceding suspend transition, they may stay in a reset-power-on state indefinitely (until they are runtime-resumed and then suspended again). That may not be a big deal from the individual device's perspective, but if the system is an SoC, it may be prevented from entering deep SoC-wide low-power states on idle because of that. The devices that are most likely to be affected by this issue are PCI devices and ACPI-enumerated devices using the general ACPI PM domain, so to prevent it from happening for those devices, force a runtime resume for them if they have their power.direct_complete flags set and the platform firmware was involved in the resume transition currently in progress. Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-pm'

2015-09-01T01:38:43+00:00

* acpi-pm: ACPI / bus: Move duplicate code to a separate new function mfd: Add support for Intel Sunrisepoint LPSS devices dmaengine: add a driver for Intel integrated DMA 64-bit mfd: make mfd_remove_devices() iterate in reverse order driver core: implement device_for_each_child_reverse() klist: implement klist_prev() Driver core: wakeup the parent device before trying probe ACPI / PM: Attach ACPI power domain only once PM / QoS: Make it possible to expose device latency tolerance to userspace ACPI / PM: Update the copyright notice and description of power.c

Merge branches 'acpi-scan', 'acpi-processor' and 'acpi-assorted'

2015-09-01T01:38:22+00:00

* acpi-scan: ACPI / bus: Move ACPI bus type registration ACPI / scan: Move bus operations and notification routines to bus.c ACPI / scan: Move device matching code to bus.c ACPI / scan: Move sysfs-related device code to a separate file * acpi-processor: PCC: Disable compilation by default ACPI: Decouple ACPI idle and ACPI processor drivers ACPI: Split out ACPI PSS from ACPI Processor driver PCC: Initialize PCC Mailbox earlier at boot ACPI / processor: remove leftover __refdata annotations * acpi-assorted: ACPI: fix acpi_debugfs_init prototype ACPI: Remove FSF mailing addresses

Merge back earlier ACPI PM material for v4.3.

2015-07-31T19:40:03+00:00

ACPI / PM: Use target_state to set the device power state

2015-07-28T14:29:08+00:00

Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow ACPI 6") changed the device power management to use D3hot if the device in question does not have _PR3 method even if D3cold was requested by the caller. However, if the device has _PR3 device->power.state is also set to D3hot instead of D3Cold after power resources have been turned off because device->power.state will be assigned from "state" instead of "target_state". Next time the device is transitioned to D0, acpi_power_transition() will find that the current power state of the device is D3hot instead of D3cold which causes it to power down all resources required for the current (wrong) state D3hot. Below is a simplified ASL example of a real touch panel device which triggers the problem: Scope (TPL1) { Name (_PR0, Package (1) { \_SB.PCI0.I2C1.PXTC }) Name (_PR3, Package (1) { \_SB.PCI0.I2C1.PXTC }) ... } In both D0 and D3hot the same power resource is required. However, when acpi_power_transition() turns off power resources required for D3hot (as the device is transitioned to D0) it powers down PXTC which then makes the device to lose its power. Fix this by assigning "target_state" to the device power state instead of "state" that is always D3hot even for devices with valid _PR3. Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki