2019-05-27 06:55:21 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-11-02 00:40:09 +00:00
|
|
|
/*
|
|
|
|
* drivers/acpi/device_pm.c - ACPI device power management routines.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012, Intel Corp.
|
|
|
|
* Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*/
|
|
|
|
|
2022-04-04 15:02:00 +00:00
|
|
|
#define pr_fmt(fmt) "PM: " fmt
|
2021-01-20 18:58:18 +00:00
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-11 21:41:56 +00:00
|
|
|
#include <linux/acpi.h>
|
2012-11-02 00:40:18 +00:00
|
|
|
#include <linux/export.h>
|
2012-11-02 00:40:09 +00:00
|
|
|
#include <linux/mutex.h>
|
2012-11-02 00:40:18 +00:00
|
|
|
#include <linux/pm_qos.h>
|
2016-01-07 15:46:13 +00:00
|
|
|
#include <linux/pm_domain.h>
|
2012-11-02 00:40:28 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state. However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up. In fact,
quite often they should just be discarded.
Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.
For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.
In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume. In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.
In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled. However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-12 20:56:34 +00:00
|
|
|
#include <linux/suspend.h>
|
2012-11-02 00:40:09 +00:00
|
|
|
|
2021-05-14 19:08:51 +00:00
|
|
|
#include "fan.h"
|
2013-01-17 13:11:08 +00:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_power_state_string - String representation of ACPI device power state.
|
|
|
|
* @state: ACPI device power state to return the string representation of.
|
|
|
|
*/
|
|
|
|
const char *acpi_power_state_string(int state)
|
|
|
|
{
|
|
|
|
switch (state) {
|
|
|
|
case ACPI_STATE_D0:
|
|
|
|
return "D0";
|
|
|
|
case ACPI_STATE_D1:
|
|
|
|
return "D1";
|
|
|
|
case ACPI_STATE_D2:
|
|
|
|
return "D2";
|
|
|
|
case ACPI_STATE_D3_HOT:
|
|
|
|
return "D3hot";
|
|
|
|
case ACPI_STATE_D3_COLD:
|
2013-01-22 11:56:26 +00:00
|
|
|
return "D3cold";
|
2013-01-17 13:11:08 +00:00
|
|
|
default:
|
|
|
|
return "(unknown)";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
static int acpi_dev_pm_explicit_get(struct acpi_device *device, int *state)
|
|
|
|
{
|
|
|
|
unsigned long long psc;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_integer(device->handle, "_PSC", NULL, &psc);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
*state = psc;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:08 +00:00
|
|
|
/**
|
|
|
|
* acpi_device_get_power - Get power state of an ACPI device.
|
|
|
|
* @device: Device to get the power state of.
|
|
|
|
* @state: Place to store the power state of the device.
|
|
|
|
*
|
|
|
|
* This function does not update the device's power.state field, but it may
|
|
|
|
* update its parent's power.state field (when the parent's power state is
|
|
|
|
* unknown and the device's power state turns out to be D0).
|
2019-07-03 23:02:49 +00:00
|
|
|
*
|
|
|
|
* Also, it does not update power resource reference counters to ensure that
|
|
|
|
* the power state returned by it will be persistent and it may return a power
|
|
|
|
* state shallower than previously set by acpi_device_set_power() for @device
|
|
|
|
* (if that power state depends on any power resources).
|
2013-01-17 13:11:08 +00:00
|
|
|
*/
|
|
|
|
int acpi_device_get_power(struct acpi_device *device, int *state)
|
|
|
|
{
|
|
|
|
int result = ACPI_STATE_UNKNOWN;
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
int error;
|
2013-01-17 13:11:08 +00:00
|
|
|
|
|
|
|
if (!device || !state)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!device->flags.power_manageable) {
|
|
|
|
/* TBD: Non-recursive algorithm for walking up hierarchy. */
|
|
|
|
*state = device->parent ?
|
|
|
|
device->parent->power.state : ACPI_STATE_D0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
* Get the device's power state from power resources settings and _PSC,
|
|
|
|
* if available.
|
2013-01-17 13:11:08 +00:00
|
|
|
*/
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
if (device->power.flags.power_resources) {
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
error = acpi_power_get_inferred_state(device, &result);
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
if (device->power.flags.explicit_get) {
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
int psc;
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
error = acpi_dev_pm_explicit_get(device, &psc);
|
|
|
|
if (error)
|
|
|
|
return error;
|
2013-01-17 13:11:08 +00:00
|
|
|
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
/*
|
|
|
|
* The power resources settings may indicate a power state
|
2015-05-15 23:55:35 +00:00
|
|
|
* shallower than the actual power state of the device, because
|
|
|
|
* the same power resources may be referenced by other devices.
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
*
|
2015-05-15 23:55:35 +00:00
|
|
|
* For systems predating ACPI 4.0 we assume that D3hot is the
|
|
|
|
* deepest state that can be supported.
|
ACPI / PM: Fix potential problem in acpi_device_get_power()
Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.
Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone. Also suppose
that _PS0 and _PS3 are present for both A and B. Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2. To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1). Next, _PS3 will be executed for device A. Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).
In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3. That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.
To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-03-24 21:54:40 +00:00
|
|
|
*/
|
|
|
|
if (psc > result && psc < ACPI_STATE_D3_COLD)
|
|
|
|
result = psc;
|
|
|
|
else if (result == ACPI_STATE_UNKNOWN)
|
2015-05-15 23:55:35 +00:00
|
|
|
result = psc > ACPI_STATE_D2 ? ACPI_STATE_D3_HOT : psc;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we were unsure about the device parent's power state up to this
|
|
|
|
* point, the fact that the device is in D0 implies that the parent has
|
2013-10-10 10:28:46 +00:00
|
|
|
* to be in D0 too, except if ignore_parent is set.
|
2013-01-17 13:11:08 +00:00
|
|
|
*/
|
2013-10-10 10:28:46 +00:00
|
|
|
if (!device->power.flags.ignore_parent && device->parent
|
|
|
|
&& device->parent->power.state == ACPI_STATE_UNKNOWN
|
2013-01-17 13:11:08 +00:00
|
|
|
&& result == ACPI_STATE_D0)
|
|
|
|
device->parent->power.state = ACPI_STATE_D0;
|
|
|
|
|
|
|
|
*state = result;
|
|
|
|
|
|
|
|
out:
|
2022-04-04 15:00:45 +00:00
|
|
|
acpi_handle_debug(device->handle, "Power state: %s\n",
|
|
|
|
acpi_power_state_string(*state));
|
2013-01-17 13:11:08 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-01-22 11:55:52 +00:00
|
|
|
static int acpi_dev_pm_explicit_set(struct acpi_device *adev, int state)
|
|
|
|
{
|
|
|
|
if (adev->power.states[state].flags.explicit_set) {
|
|
|
|
char method[5] = { '_', 'P', 'S', '0' + state, '\0' };
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(adev->handle, method, NULL, NULL);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:08 +00:00
|
|
|
/**
|
|
|
|
* acpi_device_set_power - Set power state of an ACPI device.
|
|
|
|
* @device: Device to set the power state of.
|
|
|
|
* @state: New power state to set.
|
|
|
|
*
|
|
|
|
* Callers must ensure that the device is power manageable before using this
|
|
|
|
* function.
|
|
|
|
*/
|
|
|
|
int acpi_device_set_power(struct acpi_device *device, int state)
|
|
|
|
{
|
2015-05-15 23:55:35 +00:00
|
|
|
int target_state = state;
|
2013-01-17 13:11:08 +00:00
|
|
|
int result = 0;
|
|
|
|
|
2013-07-30 12:34:00 +00:00
|
|
|
if (!device || !device->flags.power_manageable
|
|
|
|
|| (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
|
2013-01-17 13:11:08 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2019-08-02 10:26:02 +00:00
|
|
|
acpi_handle_debug(device->handle, "Power state change: %s -> %s\n",
|
|
|
|
acpi_power_state_string(device->power.state),
|
|
|
|
acpi_power_state_string(state));
|
|
|
|
|
2013-01-17 13:11:08 +00:00
|
|
|
/* Make sure this is a valid target state */
|
|
|
|
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
/* There is a special case for D0 addressed below. */
|
2022-04-14 12:58:42 +00:00
|
|
|
if (state > ACPI_STATE_D0 && state == device->power.state)
|
|
|
|
goto no_change;
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
if (state == ACPI_STATE_D3_COLD) {
|
|
|
|
/*
|
|
|
|
* For transitions to D3cold we need to execute _PS3 and then
|
|
|
|
* possibly drop references to the power resources in use.
|
|
|
|
*/
|
|
|
|
state = ACPI_STATE_D3_HOT;
|
ACPI: PM: Avoid using power resources if there are none for D0
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 <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: youling257@gmail.com
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-06-04 17:22:26 +00:00
|
|
|
/* If D3cold is not supported, use D3hot as the target state. */
|
2015-05-15 23:55:35 +00:00
|
|
|
if (!device->power.states[ACPI_STATE_D3_COLD].flags.valid)
|
|
|
|
target_state = state;
|
|
|
|
} else if (!device->power.states[state].flags.valid) {
|
2022-04-04 15:03:11 +00:00
|
|
|
acpi_handle_debug(device->handle, "Power state %s not supported\n",
|
|
|
|
acpi_power_state_string(state));
|
2013-01-17 13:11:08 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2015-05-15 23:55:35 +00:00
|
|
|
|
2022-04-04 15:03:11 +00:00
|
|
|
if (!device->power.flags.ignore_parent && device->parent &&
|
|
|
|
state < device->parent->power.state) {
|
|
|
|
acpi_handle_debug(device->handle,
|
|
|
|
"Cannot transition to %s for parent in %s\n",
|
|
|
|
acpi_power_state_string(state),
|
|
|
|
acpi_power_state_string(device->parent->power.state));
|
2013-01-17 13:11:08 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Transition Power
|
|
|
|
* ----------------
|
2015-05-15 23:55:35 +00:00
|
|
|
* In accordance with ACPI 6, _PSx is executed before manipulating power
|
|
|
|
* resources, unless the target state is D0, in which case _PS0 is
|
|
|
|
* supposed to be executed after turning the power resources on.
|
2013-01-17 13:11:08 +00:00
|
|
|
*/
|
2015-05-15 23:55:35 +00:00
|
|
|
if (state > ACPI_STATE_D0) {
|
|
|
|
/*
|
|
|
|
* According to ACPI 6, devices cannot go from lower-power
|
|
|
|
* (deeper) states to higher-power (shallower) states.
|
|
|
|
*/
|
|
|
|
if (state < device->power.state) {
|
2022-04-04 15:03:11 +00:00
|
|
|
acpi_handle_debug(device->handle,
|
|
|
|
"Cannot transition from %s to %s\n",
|
|
|
|
acpi_power_state_string(device->power.state),
|
|
|
|
acpi_power_state_string(state));
|
2015-05-15 23:55:35 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2019-06-25 12:04:45 +00:00
|
|
|
/*
|
|
|
|
* If the device goes from D3hot to D3cold, _PS3 has been
|
|
|
|
* evaluated for it already, so skip it in that case.
|
|
|
|
*/
|
|
|
|
if (device->power.state < ACPI_STATE_D3_HOT) {
|
|
|
|
result = acpi_dev_pm_explicit_set(device, state);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
if (device->power.flags.power_resources)
|
|
|
|
result = acpi_power_transition(device, target_state);
|
|
|
|
} else {
|
2019-07-31 23:31:08 +00:00
|
|
|
int cur_state = device->power.state;
|
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
if (device->power.flags.power_resources) {
|
|
|
|
result = acpi_power_transition(device, ACPI_STATE_D0);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
|
|
|
}
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
|
2019-07-31 23:31:08 +00:00
|
|
|
if (cur_state == ACPI_STATE_D0) {
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
int psc;
|
|
|
|
|
|
|
|
/* Nothing to do here if _PSC is not present. */
|
|
|
|
if (!device->power.flags.explicit_get)
|
2022-04-14 12:58:42 +00:00
|
|
|
goto no_change;
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The power state of the device was set to D0 last
|
|
|
|
* time, but that might have happened before a
|
|
|
|
* system-wide transition involving the platform
|
|
|
|
* firmware, so it may be necessary to evaluate _PS0
|
|
|
|
* for the device here. However, use extra care here
|
|
|
|
* and evaluate _PSC to check the device's current power
|
|
|
|
* state, and only invoke _PS0 if the evaluation of _PSC
|
|
|
|
* is successful and it returns a power state different
|
|
|
|
* from D0.
|
|
|
|
*/
|
|
|
|
result = acpi_dev_pm_explicit_get(device, &psc);
|
|
|
|
if (result || psc == ACPI_STATE_D0)
|
2022-04-14 12:58:42 +00:00
|
|
|
goto no_change;
|
ACPI: PM: Allow transitions to D0 to occur in special cases
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@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:06:13 +00:00
|
|
|
}
|
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
result = acpi_dev_pm_explicit_set(device, ACPI_STATE_D0);
|
2013-01-22 11:56:35 +00:00
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2022-04-14 12:58:42 +00:00
|
|
|
end:
|
2013-01-22 11:56:04 +00:00
|
|
|
if (result) {
|
2022-04-04 15:03:11 +00:00
|
|
|
acpi_handle_debug(device->handle,
|
|
|
|
"Failed to change power state to %s\n",
|
|
|
|
acpi_power_state_string(target_state));
|
2013-01-22 11:56:04 +00:00
|
|
|
} else {
|
2015-07-28 10:51:21 +00:00
|
|
|
device->power.state = target_state;
|
2022-04-04 15:03:11 +00:00
|
|
|
acpi_handle_debug(device->handle, "Power state changed to %s\n",
|
|
|
|
acpi_power_state_string(target_state));
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2022-04-14 12:58:42 +00:00
|
|
|
|
|
|
|
no_change:
|
|
|
|
acpi_handle_debug(device->handle, "Already in %s\n",
|
|
|
|
acpi_power_state_string(state));
|
|
|
|
return 0;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_device_set_power);
|
|
|
|
|
|
|
|
int acpi_bus_set_power(acpi_handle handle, int state)
|
|
|
|
{
|
2021-12-03 16:37:10 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2021-12-03 16:37:10 +00:00
|
|
|
if (device)
|
|
|
|
return acpi_device_set_power(device, state);
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2021-12-03 16:37:10 +00:00
|
|
|
return -ENODEV;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_bus_set_power);
|
|
|
|
|
|
|
|
int acpi_bus_init_power(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
int state;
|
|
|
|
int result;
|
|
|
|
|
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
device->power.state = ACPI_STATE_UNKNOWN;
|
2017-06-06 09:37:36 +00:00
|
|
|
if (!acpi_device_is_present(device)) {
|
|
|
|
device->flags.initialized = false;
|
ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it. Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.
To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.
Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-01 22:38:28 +00:00
|
|
|
return -ENXIO;
|
2017-06-06 09:37:36 +00:00
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
|
|
|
|
result = acpi_device_get_power(device, &state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
2013-01-22 11:54:38 +00:00
|
|
|
if (state < ACPI_STATE_D3_COLD && device->power.flags.power_resources) {
|
2015-05-15 23:55:35 +00:00
|
|
|
/* Reference count the power resources. */
|
2013-01-17 13:11:08 +00:00
|
|
|
result = acpi_power_on_resources(device, state);
|
2013-01-22 11:54:38 +00:00
|
|
|
if (result)
|
|
|
|
return result;
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
if (state == ACPI_STATE_D0) {
|
|
|
|
/*
|
|
|
|
* If _PSC is not present and the state inferred from
|
|
|
|
* power resources appears to be D0, it still may be
|
|
|
|
* necessary to execute _PS0 at this point, because
|
|
|
|
* another device using the same power resources may
|
|
|
|
* have been put into D0 previously and that's why we
|
|
|
|
* see D0 here.
|
|
|
|
*/
|
|
|
|
result = acpi_dev_pm_explicit_set(device, state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
}
|
2013-02-01 22:43:02 +00:00
|
|
|
} else if (state == ACPI_STATE_UNKNOWN) {
|
2013-06-05 12:01:19 +00:00
|
|
|
/*
|
|
|
|
* No power resources and missing _PSC? Cross fingers and make
|
|
|
|
* it D0 in hope that this is what the BIOS put the device into.
|
|
|
|
* [We tried to force D0 here by executing _PS0, but that broke
|
|
|
|
* Toshiba P870-303 in a nasty way.]
|
|
|
|
*/
|
2013-02-01 22:43:02 +00:00
|
|
|
state = ACPI_STATE_D0;
|
2013-01-22 11:54:38 +00:00
|
|
|
}
|
|
|
|
device->power.state = state;
|
|
|
|
return 0;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
|
2013-06-18 22:45:34 +00:00
|
|
|
/**
|
|
|
|
* acpi_device_fix_up_power - Force device with missing _PSC into D0.
|
|
|
|
* @device: Device object whose power state is to be fixed up.
|
|
|
|
*
|
|
|
|
* Devices without power resources and _PSC, but having _PS0 and _PS3 defined,
|
|
|
|
* are assumed to be put into D0 by the BIOS. However, in some cases that may
|
|
|
|
* not be the case and this function should be used then.
|
|
|
|
*/
|
|
|
|
int acpi_device_fix_up_power(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!device->power.flags.power_resources
|
|
|
|
&& !device->power.flags.explicit_get
|
|
|
|
&& device->power.state == ACPI_STATE_D0)
|
|
|
|
ret = acpi_dev_pm_explicit_set(device, ACPI_STATE_D0);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2016-05-19 13:25:41 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_device_fix_up_power);
|
2013-06-18 22:45:34 +00:00
|
|
|
|
2022-06-13 18:36:06 +00:00
|
|
|
static int fix_up_power_if_applicable(struct acpi_device *adev, void *not_used)
|
|
|
|
{
|
|
|
|
if (adev->status.present && adev->status.enabled)
|
|
|
|
acpi_device_fix_up_power(adev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_device_fix_up_power_extended - Force device and its children into D0.
|
|
|
|
* @adev: Parent device object whose power state is to be fixed up.
|
|
|
|
*
|
|
|
|
* Call acpi_device_fix_up_power() for @adev and its children so long as they
|
|
|
|
* are reported as present and enabled.
|
|
|
|
*/
|
|
|
|
void acpi_device_fix_up_power_extended(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
acpi_device_fix_up_power(adev);
|
|
|
|
acpi_dev_for_each_child(adev, fix_up_power_if_applicable, NULL);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_device_fix_up_power_extended);
|
|
|
|
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
int acpi_device_update_power(struct acpi_device *device, int *state_p)
|
2013-01-17 13:11:08 +00:00
|
|
|
{
|
|
|
|
int state;
|
|
|
|
int result;
|
|
|
|
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
if (device->power.state == ACPI_STATE_UNKNOWN) {
|
|
|
|
result = acpi_bus_init_power(device);
|
|
|
|
if (!result && state_p)
|
|
|
|
*state_p = device->power.state;
|
|
|
|
|
2013-01-17 13:11:08 +00:00
|
|
|
return result;
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
|
|
|
|
result = acpi_device_get_power(device, &state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
2013-07-04 11:22:11 +00:00
|
|
|
if (state == ACPI_STATE_UNKNOWN) {
|
2013-02-03 13:57:32 +00:00
|
|
|
state = ACPI_STATE_D0;
|
2013-07-04 11:22:11 +00:00
|
|
|
result = acpi_device_set_power(device, state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
} else {
|
|
|
|
if (device->power.flags.power_resources) {
|
|
|
|
/*
|
|
|
|
* We don't need to really switch the state, bu we need
|
|
|
|
* to update the power resources' reference counters.
|
|
|
|
*/
|
|
|
|
result = acpi_power_transition(device, state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
device->power.state = state;
|
|
|
|
}
|
|
|
|
if (state_p)
|
2013-01-17 13:11:08 +00:00
|
|
|
*state_p = state;
|
|
|
|
|
2013-07-04 11:22:11 +00:00
|
|
|
return 0;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
2013-11-19 07:43:52 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_device_update_power);
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
|
|
|
|
int acpi_bus_update_power(acpi_handle handle, int *state_p)
|
|
|
|
{
|
2021-12-03 16:37:10 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
|
2021-12-03 16:37:10 +00:00
|
|
|
if (device)
|
|
|
|
return acpi_device_update_power(device, state_p);
|
|
|
|
|
|
|
|
return -ENODEV;
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
}
|
2013-01-17 13:11:08 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_update_power);
|
|
|
|
|
|
|
|
bool acpi_bus_power_manageable(acpi_handle handle)
|
|
|
|
{
|
2021-12-03 16:37:10 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2021-12-03 16:37:10 +00:00
|
|
|
return device && device->flags.power_manageable;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_bus_power_manageable);
|
|
|
|
|
2022-04-22 15:13:48 +00:00
|
|
|
static int acpi_power_up_if_adr_present(struct acpi_device *adev, void *not_used)
|
2022-04-04 15:23:13 +00:00
|
|
|
{
|
|
|
|
if (!(adev->flags.power_manageable && adev->pnp.type.bus_address))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
acpi_handle_debug(adev->handle, "Power state: %s\n",
|
|
|
|
acpi_power_state_string(adev->power.state));
|
|
|
|
|
|
|
|
if (adev->power.state == ACPI_STATE_D3_COLD)
|
|
|
|
return acpi_device_set_power(adev, ACPI_STATE_D0);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_power_up_children_with_adr - Power up childres with valid _ADR
|
|
|
|
* @adev: Parent ACPI device object.
|
|
|
|
*
|
|
|
|
* Change the power states of the direct children of @adev that are in D3cold
|
|
|
|
* and hold valid _ADR objects to D0 in order to allow bus (e.g. PCI)
|
|
|
|
* enumeration code to access them.
|
|
|
|
*/
|
|
|
|
void acpi_dev_power_up_children_with_adr(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
acpi_dev_for_each_child(adev, acpi_power_up_if_adr_present, NULL);
|
|
|
|
}
|
|
|
|
|
2013-05-16 20:29:28 +00:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
static DEFINE_MUTEX(acpi_pm_notifier_lock);
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
static DEFINE_MUTEX(acpi_pm_notifier_install_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
|
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state. However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up. In fact,
quite often they should just be discarded.
Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.
For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.
In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume. In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.
In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled. However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-12 20:56:34 +00:00
|
|
|
void acpi_pm_wakeup_event(struct device *dev)
|
|
|
|
{
|
|
|
|
pm_wakeup_dev_event(dev, 0, acpi_s2idle_wakeup());
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_pm_wakeup_event);
|
|
|
|
|
2014-07-22 23:00:45 +00:00
|
|
|
static void acpi_pm_notify_handler(acpi_handle handle, u32 val, void *not_used)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
|
|
|
|
|
|
|
if (val != ACPI_NOTIFY_DEVICE_WAKE)
|
|
|
|
return;
|
|
|
|
|
2017-08-10 23:32:40 +00:00
|
|
|
acpi_handle_debug(handle, "Wake notify\n");
|
|
|
|
|
2014-07-22 23:00:45 +00:00
|
|
|
adev = acpi_bus_get_acpi_device(handle);
|
|
|
|
if (!adev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_pm_notifier_lock);
|
|
|
|
|
|
|
|
if (adev->wakeup.flags.notifier_present) {
|
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state. However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up. In fact,
quite often they should just be discarded.
Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.
For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.
In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume. In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.
In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled. However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-12 20:56:34 +00:00
|
|
|
pm_wakeup_ws_event(adev->wakeup.ws, 0, acpi_s2idle_wakeup());
|
2017-08-10 23:32:40 +00:00
|
|
|
if (adev->wakeup.context.func) {
|
2019-03-25 19:32:28 +00:00
|
|
|
acpi_handle_debug(handle, "Running %pS for %s\n",
|
2017-08-10 23:32:40 +00:00
|
|
|
adev->wakeup.context.func,
|
|
|
|
dev_name(adev->wakeup.context.dev));
|
2017-06-12 20:48:41 +00:00
|
|
|
adev->wakeup.context.func(&adev->wakeup.context);
|
2017-08-10 23:32:40 +00:00
|
|
|
}
|
2014-07-22 23:00:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&acpi_pm_notifier_lock);
|
|
|
|
|
|
|
|
acpi_bus_put_acpi_device(adev);
|
|
|
|
}
|
|
|
|
|
2013-05-16 20:29:28 +00:00
|
|
|
/**
|
2014-07-22 23:00:45 +00:00
|
|
|
* acpi_add_pm_notifier - Register PM notify handler for given ACPI device.
|
|
|
|
* @adev: ACPI device to add the notify handler for.
|
|
|
|
* @dev: Device to generate a wakeup event for while handling the notification.
|
2017-06-12 20:48:41 +00:00
|
|
|
* @func: Work function to execute when handling the notification.
|
2013-05-16 20:29:28 +00:00
|
|
|
*
|
|
|
|
* NOTE: @adev need not be a run-wake or wakeup device to be a valid source of
|
|
|
|
* PM wakeup events. For example, wakeup events may be generated for bridges
|
|
|
|
* if one of the devices below the bridge is signaling wakeup, even if the
|
|
|
|
* bridge itself doesn't have a wakeup GPE associated with it.
|
|
|
|
*/
|
2014-07-22 23:00:45 +00:00
|
|
|
acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev,
|
2017-06-12 20:48:41 +00:00
|
|
|
void (*func)(struct acpi_device_wakeup_context *context))
|
2013-05-16 20:29:28 +00:00
|
|
|
{
|
|
|
|
acpi_status status = AE_ALREADY_EXISTS;
|
|
|
|
|
2017-06-12 20:48:41 +00:00
|
|
|
if (!dev && !func)
|
2014-07-22 23:00:45 +00:00
|
|
|
return AE_BAD_PARAMETER;
|
|
|
|
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_lock(&acpi_pm_notifier_install_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
|
|
|
|
if (adev->wakeup.flags.notifier_present)
|
|
|
|
goto out;
|
|
|
|
|
2014-07-22 23:00:45 +00:00
|
|
|
status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY,
|
|
|
|
acpi_pm_notify_handler, NULL);
|
2013-05-16 20:29:28 +00:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto out;
|
|
|
|
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_lock(&acpi_pm_notifier_lock);
|
2019-08-07 01:48:46 +00:00
|
|
|
adev->wakeup.ws = wakeup_source_register(&adev->dev,
|
|
|
|
dev_name(&adev->dev));
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
adev->wakeup.context.dev = dev;
|
|
|
|
adev->wakeup.context.func = func;
|
2013-05-16 20:29:28 +00:00
|
|
|
adev->wakeup.flags.notifier_present = true;
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_unlock(&acpi_pm_notifier_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
|
|
|
|
out:
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_unlock(&acpi_pm_notifier_install_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_remove_pm_notifier - Unregister PM notifier from given ACPI device.
|
|
|
|
* @adev: ACPI device to remove the notifier from.
|
|
|
|
*/
|
2014-07-22 23:00:45 +00:00
|
|
|
acpi_status acpi_remove_pm_notifier(struct acpi_device *adev)
|
2013-05-16 20:29:28 +00:00
|
|
|
{
|
|
|
|
acpi_status status = AE_BAD_PARAMETER;
|
|
|
|
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_lock(&acpi_pm_notifier_install_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
|
|
|
|
if (!adev->wakeup.flags.notifier_present)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
status = acpi_remove_notify_handler(adev->handle,
|
|
|
|
ACPI_SYSTEM_NOTIFY,
|
2014-07-22 23:00:45 +00:00
|
|
|
acpi_pm_notify_handler);
|
2013-05-16 20:29:28 +00:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto out;
|
|
|
|
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_lock(&acpi_pm_notifier_lock);
|
2017-06-12 20:48:41 +00:00
|
|
|
adev->wakeup.context.func = NULL;
|
2014-07-22 23:00:45 +00:00
|
|
|
adev->wakeup.context.dev = NULL;
|
|
|
|
wakeup_source_unregister(adev->wakeup.ws);
|
2013-05-16 20:29:28 +00:00
|
|
|
adev->wakeup.flags.notifier_present = false;
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_unlock(&acpi_pm_notifier_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
|
|
|
|
out:
|
ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
acpi_remove_pm_notifier() ends up calling flush_workqueue() while
holding acpi_pm_notifier_lock, and that same lock is taken by
by the work via acpi_pm_notify_handler(). This can deadlock.
To fix the problem let's split the single lock into two: one to
protect the dev->wakeup between the work vs. add/remove, and
another one to handle notifier installation vs. removal.
After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
annotation" I was able to kill the machine (Intel Braswell)
very easily with 'powertop --auto-tune', runtime suspending i915,
and trying to wake it up via the USB keyboard. The cases when
it didn't die are presumably explained by lockdep getting disabled
by something else (cpu hotplug locking issues usually).
Fortunately I still got a lockdep report over netconsole
(trickling in very slowly), even though the machine was
otherwise practically dead:
[ 112.179806] ======================================================
[ 114.670858] WARNING: possible circular locking dependency detected
[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
[ 119.658101] ------------------------------------------------------
[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 121.313485] usb 1-6: USB disconnect, device number 3
[ 121.313501] usb 1-6.2: USB disconnect, device number 4
[ 134.747383] kworker/0:2/47 is trying to acquire lock:
[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
[ 139.721524]
[ 139.721524] but task is already holding lock:
[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 147.184450]
[ 147.184450] which lock already depends on the new lock.
[ 147.184450]
[ 154.604711]
[ 154.604711] the existing dependency chain (in reverse order) is:
[ 159.447888]
[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
[ 164.183486] __lock_acquire+0x1255/0x13f0
[ 166.504313] lock_acquire+0xb5/0x210
[ 168.778973] process_one_work+0x1b9/0x720
[ 171.030316] worker_thread+0x4c/0x440
[ 173.257184] kthread+0x154/0x190
[ 175.456143] ret_from_fork+0x27/0x40
[ 177.624348]
[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
[ 181.850351] __lock_acquire+0x1255/0x13f0
[ 183.941695] lock_acquire+0xb5/0x210
[ 186.046115] flush_workqueue+0xdd/0x510
[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
[ 192.625303] acpi_remove_notify_handler+0x133/0x188
[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
[ 199.145866] dev_pm_domain_detach+0x27/0x30
[ 201.285614] i2c_device_probe+0x100/0x210
[ 203.411118] driver_probe_device+0x23e/0x310
[ 205.522425] __driver_attach+0xa3/0xb0
[ 207.634268] bus_for_each_dev+0x69/0xa0
[ 209.714797] driver_attach+0x1e/0x20
[ 211.778258] bus_add_driver+0x1bc/0x230
[ 213.837162] driver_register+0x60/0xe0
[ 215.868162] i2c_register_driver+0x42/0x70
[ 217.869551] 0xffffffffa0172017
[ 219.863009] do_one_initcall+0x45/0x170
[ 221.843863] do_init_module+0x5f/0x204
[ 223.817915] load_module+0x225b/0x29b0
[ 225.757234] SyS_finit_module+0xc6/0xd0
[ 227.661851] do_syscall_64+0x5c/0x120
[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
[ 231.392444]
[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
[ 235.124914] check_prev_add+0x44e/0x8a0
[ 237.024795] __lock_acquire+0x1255/0x13f0
[ 238.937351] lock_acquire+0xb5/0x210
[ 240.840799] __mutex_lock+0x75/0x940
[ 242.709517] mutex_lock_nested+0x1c/0x20
[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
[ 248.194412] acpi_os_execute_deferred+0x14/0x30
[ 250.003925] process_one_work+0x1ec/0x720
[ 251.803191] worker_thread+0x4c/0x440
[ 253.605307] kthread+0x154/0x190
[ 255.387498] ret_from_fork+0x27/0x40
[ 257.153175]
[ 257.153175] other info that might help us debug this:
[ 257.153175]
[ 262.324392] Chain exists of:
[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
[ 262.324392]
[ 267.391997] Possible unsafe locking scenario:
[ 267.391997]
[ 270.758262] CPU0 CPU1
[ 272.431713] ---- ----
[ 274.060756] lock((&dpc->work));
[ 275.646532] lock("kacpi_notify");
[ 277.260772] lock((&dpc->work));
[ 278.839146] lock(acpi_pm_notifier_lock);
[ 280.391902]
[ 280.391902] *** DEADLOCK ***
[ 280.391902]
[ 284.986385] 2 locks held by kworker/0:2/47:
[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
[ 289.727725]
Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-07 21:08:10 +00:00
|
|
|
mutex_unlock(&acpi_pm_notifier_install_lock);
|
2013-05-16 20:29:28 +00:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:08 +00:00
|
|
|
bool acpi_bus_can_wakeup(acpi_handle handle)
|
|
|
|
{
|
2021-12-03 16:37:10 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2013-01-17 13:11:08 +00:00
|
|
|
|
2021-12-03 16:37:10 +00:00
|
|
|
return device && device->wakeup.flags.valid;
|
2013-01-17 13:11:08 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_bus_can_wakeup);
|
|
|
|
|
2017-06-23 23:56:13 +00:00
|
|
|
bool acpi_pm_device_can_wakeup(struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
|
|
|
|
return adev ? acpi_device_can_wakeup(adev) : false;
|
|
|
|
}
|
|
|
|
|
2012-11-02 00:40:18 +00:00
|
|
|
/**
|
2013-06-15 22:37:42 +00:00
|
|
|
* acpi_dev_pm_get_state - Get preferred power state of ACPI device.
|
2012-11-02 00:40:18 +00:00
|
|
|
* @dev: Device whose preferred target power state to return.
|
|
|
|
* @adev: ACPI device node corresponding to @dev.
|
|
|
|
* @target_state: System state to match the resultant device state.
|
2013-06-15 22:37:59 +00:00
|
|
|
* @d_min_p: Location to store the highest power state available to the device.
|
|
|
|
* @d_max_p: Location to store the lowest power state available to the device.
|
2012-11-02 00:40:18 +00:00
|
|
|
*
|
2013-06-15 22:37:59 +00:00
|
|
|
* Find the lowest power (highest number) and highest power (lowest number) ACPI
|
|
|
|
* device power states that the device can be in while the system is in the
|
|
|
|
* state represented by @target_state. Store the integer numbers representing
|
|
|
|
* those stats in the memory locations pointed to by @d_max_p and @d_min_p,
|
|
|
|
* respectively.
|
2012-11-02 00:40:18 +00:00
|
|
|
*
|
|
|
|
* Callers must ensure that @dev and @adev are valid pointers and that @adev
|
|
|
|
* actually corresponds to @dev before using this function.
|
2013-06-15 22:37:59 +00:00
|
|
|
*
|
|
|
|
* Returns 0 on success or -ENODATA when one of the ACPI methods fails or
|
|
|
|
* returns a value that doesn't make sense. The memory locations pointed to by
|
|
|
|
* @d_max_p and @d_min_p are only modified on success.
|
2012-11-02 00:40:18 +00:00
|
|
|
*/
|
2013-06-15 22:37:42 +00:00
|
|
|
static int acpi_dev_pm_get_state(struct device *dev, struct acpi_device *adev,
|
2013-06-15 22:37:59 +00:00
|
|
|
u32 target_state, int *d_min_p, int *d_max_p)
|
2012-11-02 00:40:18 +00:00
|
|
|
{
|
2013-06-15 22:37:59 +00:00
|
|
|
char method[] = { '_', 'S', '0' + target_state, 'D', '\0' };
|
|
|
|
acpi_handle handle = adev->handle;
|
|
|
|
unsigned long long ret;
|
|
|
|
int d_min, d_max;
|
2012-11-02 00:40:18 +00:00
|
|
|
bool wakeup = false;
|
2018-03-20 04:07:35 +00:00
|
|
|
bool has_sxd = false;
|
2013-06-15 22:37:59 +00:00
|
|
|
acpi_status status;
|
2012-11-02 00:40:18 +00:00
|
|
|
|
|
|
|
/*
|
2013-06-15 22:37:59 +00:00
|
|
|
* If the system state is S0, the lowest power state the device can be
|
|
|
|
* in is D3cold, unless the device has _S0W and is supposed to signal
|
|
|
|
* wakeup, in which case the return value of _S0W has to be used as the
|
|
|
|
* lowest power state available to the device.
|
2012-11-02 00:40:18 +00:00
|
|
|
*/
|
|
|
|
d_min = ACPI_STATE_D0;
|
2013-06-15 22:37:50 +00:00
|
|
|
d_max = ACPI_STATE_D3_COLD;
|
2012-11-02 00:40:18 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If present, _SxD methods return the minimum D-state (highest power
|
|
|
|
* state) we can use for the corresponding S-states. Otherwise, the
|
|
|
|
* minimum D-state is D0 (ACPI 3.x).
|
|
|
|
*/
|
|
|
|
if (target_state > ACPI_STATE_S0) {
|
2013-06-15 22:37:59 +00:00
|
|
|
/*
|
|
|
|
* We rely on acpi_evaluate_integer() not clobbering the integer
|
|
|
|
* provided if AE_NOT_FOUND is returned.
|
|
|
|
*/
|
|
|
|
ret = d_min;
|
|
|
|
status = acpi_evaluate_integer(handle, method, NULL, &ret);
|
|
|
|
if ((ACPI_FAILURE(status) && status != AE_NOT_FOUND)
|
|
|
|
|| ret > ACPI_STATE_D3_COLD)
|
|
|
|
return -ENODATA;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to handle legacy systems where D3hot and D3cold are
|
|
|
|
* the same and 3 is returned in both cases, so fall back to
|
|
|
|
* D3cold if D3hot is not a valid state.
|
|
|
|
*/
|
|
|
|
if (!adev->power.states[ret].flags.valid) {
|
|
|
|
if (ret == ACPI_STATE_D3_HOT)
|
|
|
|
ret = ACPI_STATE_D3_COLD;
|
|
|
|
else
|
|
|
|
return -ENODATA;
|
|
|
|
}
|
2018-03-20 04:07:35 +00:00
|
|
|
|
|
|
|
if (status == AE_OK)
|
|
|
|
has_sxd = true;
|
|
|
|
|
2013-06-15 22:37:59 +00:00
|
|
|
d_min = ret;
|
2012-11-02 00:40:18 +00:00
|
|
|
wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid
|
|
|
|
&& adev->wakeup.sleep_state >= target_state;
|
2017-10-13 13:27:24 +00:00
|
|
|
} else {
|
2012-11-02 00:40:18 +00:00
|
|
|
wakeup = adev->wakeup.flags.valid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If _PRW says we can wake up the system from the target sleep state,
|
|
|
|
* the D-state returned by _SxD is sufficient for that (we assume a
|
|
|
|
* wakeup-aware driver if wake is set). Still, if _SxW exists
|
|
|
|
* (ACPI 3.x), it should return the maximum (lowest power) D-state that
|
|
|
|
* can wake the system. _S0W may be valid, too.
|
|
|
|
*/
|
|
|
|
if (wakeup) {
|
2013-06-15 22:37:59 +00:00
|
|
|
method[3] = 'W';
|
|
|
|
status = acpi_evaluate_integer(handle, method, NULL, &ret);
|
|
|
|
if (status == AE_NOT_FOUND) {
|
2018-03-20 04:07:35 +00:00
|
|
|
/* No _SxW. In this case, the ACPI spec says that we
|
|
|
|
* must not go into any power state deeper than the
|
|
|
|
* value returned from _SxD.
|
|
|
|
*/
|
|
|
|
if (has_sxd && target_state > ACPI_STATE_S0)
|
2012-11-02 00:40:18 +00:00
|
|
|
d_max = d_min;
|
2013-06-15 22:37:59 +00:00
|
|
|
} else if (ACPI_SUCCESS(status) && ret <= ACPI_STATE_D3_COLD) {
|
|
|
|
/* Fall back to D3cold if ret is not a valid state. */
|
|
|
|
if (!adev->power.states[ret].flags.valid)
|
|
|
|
ret = ACPI_STATE_D3_COLD;
|
|
|
|
|
|
|
|
d_max = ret > d_min ? ret : d_min;
|
|
|
|
} else {
|
|
|
|
return -ENODATA;
|
2012-11-02 00:40:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (d_min_p)
|
|
|
|
*d_min_p = d_min;
|
2013-06-15 22:37:59 +00:00
|
|
|
|
|
|
|
if (d_max_p)
|
|
|
|
*d_max_p = d_max;
|
|
|
|
|
|
|
|
return 0;
|
2012-11-02 00:40:18 +00:00
|
|
|
}
|
2012-11-02 00:40:28 +00:00
|
|
|
|
2012-11-02 00:40:53 +00:00
|
|
|
/**
|
|
|
|
* acpi_pm_device_sleep_state - Get preferred power state of ACPI device.
|
|
|
|
* @dev: Device whose preferred target power state to return.
|
|
|
|
* @d_min_p: Location to store the upper limit of the allowed states range.
|
|
|
|
* @d_max_in: Deepest low-power state to take into consideration.
|
|
|
|
* Return value: Preferred power state of the device on success, -ENODEV
|
2013-06-15 22:37:59 +00:00
|
|
|
* if there's no 'struct acpi_device' for @dev, -EINVAL if @d_max_in is
|
|
|
|
* incorrect, or -ENODATA on ACPI method failure.
|
2012-11-02 00:40:53 +00:00
|
|
|
*
|
|
|
|
* The caller must ensure that @dev is valid before using this function.
|
|
|
|
*/
|
|
|
|
int acpi_pm_device_sleep_state(struct device *dev, int *d_min_p, int d_max_in)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
2013-06-27 12:01:02 +00:00
|
|
|
int ret, d_min, d_max;
|
2013-06-15 22:37:59 +00:00
|
|
|
|
|
|
|
if (d_max_in < ACPI_STATE_D0 || d_max_in > ACPI_STATE_D3_COLD)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
if (d_max_in > ACPI_STATE_D2) {
|
2013-06-15 22:37:59 +00:00
|
|
|
enum pm_qos_flags_status stat;
|
|
|
|
|
|
|
|
stat = dev_pm_qos_flags(dev, PM_QOS_FLAG_NO_POWER_OFF);
|
|
|
|
if (stat == PM_QOS_FLAGS_ALL)
|
2015-05-15 23:55:35 +00:00
|
|
|
d_max_in = ACPI_STATE_D2;
|
2013-06-15 22:37:59 +00:00
|
|
|
}
|
2012-11-02 00:40:53 +00:00
|
|
|
|
2014-07-22 23:01:41 +00:00
|
|
|
adev = ACPI_COMPANION(dev);
|
|
|
|
if (!adev) {
|
|
|
|
dev_dbg(dev, "ACPI companion missing in %s!\n", __func__);
|
2012-11-02 00:40:53 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2013-06-15 22:37:59 +00:00
|
|
|
ret = acpi_dev_pm_get_state(dev, adev, acpi_target_system_state(),
|
2013-06-27 12:01:02 +00:00
|
|
|
&d_min, &d_max);
|
2013-06-15 22:37:59 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-06-27 12:01:02 +00:00
|
|
|
if (d_max_in < d_min)
|
2013-06-15 22:37:59 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (d_max > d_max_in) {
|
2013-06-27 12:01:02 +00:00
|
|
|
for (d_max = d_max_in; d_max > d_min; d_max--) {
|
2013-06-15 22:37:59 +00:00
|
|
|
if (adev->power.states[d_max].flags.valid)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2013-06-27 12:01:02 +00:00
|
|
|
|
|
|
|
if (d_min_p)
|
|
|
|
*d_min_p = d_min;
|
|
|
|
|
2013-06-15 22:37:59 +00:00
|
|
|
return d_max;
|
2012-11-02 00:40:53 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_pm_device_sleep_state);
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
2014-07-22 23:00:45 +00:00
|
|
|
* acpi_pm_notify_work_func - ACPI devices wakeup notification work function.
|
2017-06-12 20:48:41 +00:00
|
|
|
* @context: Device wakeup context.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*/
|
2017-06-12 20:48:41 +00:00
|
|
|
static void acpi_pm_notify_work_func(struct acpi_device_wakeup_context *context)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
{
|
2017-06-12 20:48:41 +00:00
|
|
|
struct device *dev = context->dev;
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
2014-07-22 23:00:45 +00:00
|
|
|
if (dev) {
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
pm_wakeup_event(dev, 0);
|
2017-06-12 20:48:41 +00:00
|
|
|
pm_request_resume(dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
static DEFINE_MUTEX(acpi_wakeup_lock);
|
|
|
|
|
2017-08-01 00:56:18 +00:00
|
|
|
static int __acpi_device_wakeup_enable(struct acpi_device *adev,
|
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 19:44:00 +00:00
|
|
|
u32 target_state)
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
{
|
|
|
|
struct acpi_device_wakeup *wakeup = &adev->wakeup;
|
2017-07-21 12:40:49 +00:00
|
|
|
acpi_status status;
|
|
|
|
int error = 0;
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
mutex_lock(&acpi_wakeup_lock);
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
|
2020-11-24 19:46:38 +00:00
|
|
|
/*
|
|
|
|
* If the device wakeup power is already enabled, disable it and enable
|
|
|
|
* it again in case it depends on the configuration of subordinate
|
|
|
|
* devices and the conditions have changed since it was enabled last
|
|
|
|
* time.
|
|
|
|
*/
|
2017-08-01 00:56:18 +00:00
|
|
|
if (wakeup->enable_count > 0)
|
2020-11-24 19:46:38 +00:00
|
|
|
acpi_disable_wakeup_device_power(adev);
|
2017-08-01 00:56:18 +00:00
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
error = acpi_enable_wakeup_device_power(adev, target_state);
|
2020-11-24 19:46:38 +00:00
|
|
|
if (error) {
|
|
|
|
if (wakeup->enable_count > 0) {
|
|
|
|
acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
|
|
|
|
wakeup->enable_count = 0;
|
|
|
|
}
|
2017-07-21 12:40:49 +00:00
|
|
|
goto out;
|
2020-11-24 19:46:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (wakeup->enable_count > 0)
|
|
|
|
goto inc;
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
status = acpi_enable_gpe(wakeup->gpe_device, wakeup->gpe_number);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
acpi_disable_wakeup_device_power(adev);
|
2017-07-21 12:40:49 +00:00
|
|
|
error = -EIO;
|
|
|
|
goto out;
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
}
|
2017-07-21 12:40:49 +00:00
|
|
|
|
2019-04-03 21:58:01 +00:00
|
|
|
acpi_handle_debug(adev->handle, "GPE%2X enabled for wakeup\n",
|
|
|
|
(unsigned int)wakeup->gpe_number);
|
|
|
|
|
2017-08-01 00:56:18 +00:00
|
|
|
inc:
|
2020-11-24 19:46:38 +00:00
|
|
|
if (wakeup->enable_count < INT_MAX)
|
|
|
|
wakeup->enable_count++;
|
|
|
|
else
|
|
|
|
acpi_handle_info(adev->handle, "Wakeup enable count out of bounds!\n");
|
2017-07-21 12:40:49 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_wakeup_lock);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2017-08-01 00:56:18 +00:00
|
|
|
/**
|
|
|
|
* acpi_device_wakeup_enable - Enable wakeup functionality for device.
|
|
|
|
* @adev: ACPI device to enable wakeup functionality for.
|
|
|
|
* @target_state: State the system is transitioning into.
|
|
|
|
*
|
|
|
|
* Enable the GPE associated with @adev so that it can generate wakeup signals
|
|
|
|
* for the device in response to external (remote) events and enable wakeup
|
|
|
|
* power for it.
|
|
|
|
*
|
|
|
|
* Callers must ensure that @adev is a valid ACPI device node before executing
|
|
|
|
* this function.
|
|
|
|
*/
|
|
|
|
static int acpi_device_wakeup_enable(struct acpi_device *adev, u32 target_state)
|
|
|
|
{
|
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 19:44:00 +00:00
|
|
|
return __acpi_device_wakeup_enable(adev, target_state);
|
2017-08-01 00:56:18 +00:00
|
|
|
}
|
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
/**
|
|
|
|
* acpi_device_wakeup_disable - Disable wakeup functionality for device.
|
|
|
|
* @adev: ACPI device to disable wakeup functionality for.
|
|
|
|
*
|
|
|
|
* Disable the GPE associated with @adev and disable wakeup power for it.
|
|
|
|
*
|
|
|
|
* Callers must ensure that @adev is a valid ACPI device node before executing
|
|
|
|
* this function.
|
|
|
|
*/
|
|
|
|
static void acpi_device_wakeup_disable(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_device_wakeup *wakeup = &adev->wakeup;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_wakeup_lock);
|
|
|
|
|
|
|
|
if (!wakeup->enable_count)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
|
|
|
|
acpi_disable_wakeup_device_power(adev);
|
|
|
|
|
|
|
|
wakeup->enable_count--;
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_wakeup_lock);
|
ACPI / PM: Split device wakeup management routines
Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node. That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.
Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often. However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.
To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.
Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:40:36 +00:00
|
|
|
}
|
|
|
|
|
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 19:44:00 +00:00
|
|
|
/**
|
|
|
|
* acpi_pm_set_device_wakeup - Enable/disable remote wakeup for given device.
|
|
|
|
* @dev: Device to enable/disable to generate wakeup events.
|
|
|
|
* @enable: Whether to enable or disable the wakeup functionality.
|
|
|
|
*/
|
|
|
|
int acpi_pm_set_device_wakeup(struct device *dev, bool enable)
|
2012-11-02 00:40:53 +00:00
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
|
|
|
int error;
|
|
|
|
|
2014-07-22 23:01:41 +00:00
|
|
|
adev = ACPI_COMPANION(dev);
|
|
|
|
if (!adev) {
|
|
|
|
dev_dbg(dev, "ACPI companion missing in %s!\n", __func__);
|
2012-11-02 00:40:53 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2017-06-23 23:54:39 +00:00
|
|
|
if (!acpi_device_can_wakeup(adev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-07-21 12:40:49 +00:00
|
|
|
if (!enable) {
|
|
|
|
acpi_device_wakeup_disable(adev);
|
|
|
|
dev_dbg(dev, "Wakeup disabled by ACPI\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 19:44:00 +00:00
|
|
|
error = __acpi_device_wakeup_enable(adev, acpi_target_system_state());
|
2012-11-02 00:40:53 +00:00
|
|
|
if (!error)
|
2017-07-21 12:40:49 +00:00
|
|
|
dev_dbg(dev, "Wakeup enabled by ACPI\n");
|
2012-11-02 00:40:53 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
2017-08-01 00:56:18 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_pm_set_device_wakeup);
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_pm_low_power - Put ACPI device into a low-power state.
|
|
|
|
* @dev: Device to put into a low-power state.
|
|
|
|
* @adev: ACPI device node corresponding to @dev.
|
|
|
|
* @system_state: System state to choose the device state for.
|
|
|
|
*/
|
|
|
|
static int acpi_dev_pm_low_power(struct device *dev, struct acpi_device *adev,
|
|
|
|
u32 system_state)
|
|
|
|
{
|
2013-06-15 22:37:59 +00:00
|
|
|
int ret, state;
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
|
|
|
if (!acpi_device_power_manageable(adev))
|
|
|
|
return 0;
|
|
|
|
|
2013-06-15 22:37:59 +00:00
|
|
|
ret = acpi_dev_pm_get_state(dev, adev, system_state, NULL, &state);
|
|
|
|
return ret ? ret : acpi_device_set_power(adev, state);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_pm_full_power - Put ACPI device into the full-power state.
|
|
|
|
* @adev: ACPI device node to put into the full-power state.
|
|
|
|
*/
|
|
|
|
static int acpi_dev_pm_full_power(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return acpi_device_power_manageable(adev) ?
|
|
|
|
acpi_device_set_power(adev, ACPI_STATE_D0) : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-10-14 15:43:15 +00:00
|
|
|
* acpi_dev_suspend - Put device into a low-power state using ACPI.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
* @dev: Device to put into a low-power state.
|
2017-10-14 15:43:15 +00:00
|
|
|
* @wakeup: Whether or not to enable wakeup for the device.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*
|
2017-10-14 15:43:15 +00:00
|
|
|
* Put the given device into a low-power state using the standard ACPI
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
* mechanism. Set up remote wakeup if desired, choose the state to put the
|
|
|
|
* device into (this checks if remote wakeup is expected to work too), and set
|
|
|
|
* the power state of the device.
|
|
|
|
*/
|
2017-10-14 15:43:15 +00:00
|
|
|
int acpi_dev_suspend(struct device *dev, bool wakeup)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
{
|
2014-01-27 22:10:24 +00:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
2017-10-14 15:43:15 +00:00
|
|
|
u32 target_state = acpi_target_system_state();
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!adev)
|
|
|
|
return 0;
|
|
|
|
|
2017-10-14 15:43:15 +00:00
|
|
|
if (wakeup && acpi_device_can_wakeup(adev)) {
|
|
|
|
error = acpi_device_wakeup_enable(adev, target_state);
|
2017-07-21 12:40:49 +00:00
|
|
|
if (error)
|
|
|
|
return -EAGAIN;
|
2017-10-14 15:43:15 +00:00
|
|
|
} else {
|
|
|
|
wakeup = false;
|
2017-07-21 12:40:49 +00:00
|
|
|
}
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
2017-10-14 15:43:15 +00:00
|
|
|
error = acpi_dev_pm_low_power(dev, adev, target_state);
|
|
|
|
if (error && wakeup)
|
2017-07-21 12:40:49 +00:00
|
|
|
acpi_device_wakeup_disable(adev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
2017-10-14 15:43:15 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_suspend);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
|
|
|
/**
|
2017-10-10 16:49:22 +00:00
|
|
|
* acpi_dev_resume - Put device into the full-power state using ACPI.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
* @dev: Device to put into the full-power state.
|
|
|
|
*
|
|
|
|
* Put the given device into the full-power state using the standard ACPI
|
2017-10-10 16:49:22 +00:00
|
|
|
* mechanism. Set the power state of the device to ACPI D0 and disable wakeup.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*/
|
2017-10-10 16:49:22 +00:00
|
|
|
int acpi_dev_resume(struct device *dev)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
{
|
2014-01-27 22:10:24 +00:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!adev)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
error = acpi_dev_pm_full_power(adev);
|
2017-07-21 12:40:49 +00:00
|
|
|
acpi_device_wakeup_disable(adev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
return error;
|
|
|
|
}
|
2017-10-10 16:49:22 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resume);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_subsys_runtime_suspend - Suspend device using ACPI.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Carry out the generic runtime suspend procedure for @dev and use ACPI to put
|
|
|
|
* it into a runtime low-power state.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_runtime_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
int ret = pm_generic_runtime_suspend(dev);
|
2021-03-27 12:08:22 +00:00
|
|
|
|
2017-10-14 15:43:15 +00:00
|
|
|
return ret ? ret : acpi_dev_suspend(dev, true);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_runtime_suspend);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_subsys_runtime_resume - Resume device using ACPI.
|
|
|
|
* @dev: Device to Resume.
|
|
|
|
*
|
|
|
|
* Use ACPI to put the given device into the full-power state and carry out the
|
|
|
|
* generic runtime resume procedure for it.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_runtime_resume(struct device *dev)
|
|
|
|
{
|
2017-10-10 16:49:22 +00:00
|
|
|
int ret = acpi_dev_resume(dev);
|
2021-03-27 12:08:22 +00:00
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
return ret ? ret : pm_generic_runtime_resume(dev);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_runtime_resume);
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2017-10-03 07:11:08 +00:00
|
|
|
static bool acpi_dev_needs_resume(struct device *dev, struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
u32 sys_target = acpi_target_system_state();
|
|
|
|
int ret, state;
|
|
|
|
|
2019-05-16 10:42:20 +00:00
|
|
|
if (!pm_runtime_suspended(dev) || !adev || (adev->wakeup.flags.valid &&
|
|
|
|
device_may_wakeup(dev) != !!adev->wakeup.prepare_count))
|
2017-10-03 07:11:08 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
if (sys_target == ACPI_STATE_S0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (adev->power.flags.dsw_present)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
ret = acpi_dev_pm_get_state(dev, adev, sys_target, NULL, &state);
|
|
|
|
if (ret)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return state != adev->power.state;
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_prepare - Prepare device for system transition to a sleep state.
|
|
|
|
* @dev: Device to prepare.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_prepare(struct device *dev)
|
|
|
|
{
|
2014-05-16 22:18:13 +00:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
|
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-25 12:12:29 +00:00
|
|
|
if (dev->driver && dev->driver->pm && dev->driver->pm->prepare) {
|
|
|
|
int ret = dev->driver->pm->prepare(dev);
|
2014-05-16 22:18:13 +00:00
|
|
|
|
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-25 12:12:29 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!ret && dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_PREPARE))
|
|
|
|
return 0;
|
|
|
|
}
|
2014-05-16 22:18:13 +00:00
|
|
|
|
2017-10-03 07:11:08 +00:00
|
|
|
return !acpi_dev_needs_resume(dev, adev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
|
|
|
|
|
2017-10-03 07:11:06 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_complete - Finalize device's resume during system resume.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
|
|
|
void acpi_subsys_complete(struct device *dev)
|
|
|
|
{
|
|
|
|
pm_generic_complete(dev);
|
|
|
|
/*
|
|
|
|
* If the device had been runtime-suspended before the system went into
|
|
|
|
* the sleep state it is going out of and it has never been resumed till
|
|
|
|
* now, resume it in case the firmware powered it up.
|
|
|
|
*/
|
2017-11-18 14:35:00 +00:00
|
|
|
if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
|
2017-10-03 07:11:06 +00:00
|
|
|
pm_request_resume(dev);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_complete);
|
|
|
|
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_suspend - Run the device driver's suspend callback.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
* Follow PCI and resume devices from runtime suspend before running their
|
|
|
|
* system suspend callbacks, unless the driver can cope with runtime-suspended
|
|
|
|
* devices during system suspend and there are no ACPI-specific reasons for
|
|
|
|
* resuming them.
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
*/
|
|
|
|
int acpi_subsys_suspend(struct device *dev)
|
|
|
|
{
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
|
|
|
|
acpi_dev_needs_resume(dev, ACPI_COMPANION(dev)))
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
return pm_generic_suspend(dev);
|
|
|
|
}
|
2014-05-15 13:40:23 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_suspend);
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_suspend_late - Suspend device using ACPI.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Carry out the generic late suspend procedure for @dev and use ACPI to put
|
|
|
|
* it into a low-power state during system transition into a sleep state.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_suspend_late(struct device *dev)
|
|
|
|
{
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = pm_generic_suspend_late(dev);
|
2017-10-14 15:43:15 +00:00
|
|
|
return ret ? ret : acpi_dev_suspend(dev, device_may_wakeup(dev));
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_suspend_late);
|
|
|
|
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_suspend_noirq - Run the device driver's "noirq" suspend callback.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_suspend_noirq(struct device *dev)
|
|
|
|
{
|
2017-11-18 14:35:00 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
return 0;
|
2017-11-18 14:35:00 +00:00
|
|
|
|
|
|
|
ret = pm_generic_suspend_noirq(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
2017-11-18 14:35:00 +00:00
|
|
|
/*
|
|
|
|
* If the target system sleep state is suspend-to-idle, it is sufficient
|
|
|
|
* to check whether or not the device's wakeup settings are good for
|
|
|
|
* runtime PM. Otherwise, the pm_resume_via_firmware() check will cause
|
|
|
|
* acpi_subsys_complete() to take care of fixing up the device's state
|
|
|
|
* anyway, if need be.
|
|
|
|
*/
|
2020-04-18 16:52:19 +00:00
|
|
|
if (device_can_wakeup(dev) && !device_may_wakeup(dev))
|
|
|
|
dev->power.may_skip_resume = false;
|
2017-11-18 14:35:00 +00:00
|
|
|
|
|
|
|
return 0;
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_subsys_resume_noirq - Run the device driver's "noirq" resume callback.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
2019-07-01 10:54:10 +00:00
|
|
|
static int acpi_subsys_resume_noirq(struct device *dev)
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
{
|
2020-04-18 16:52:30 +00:00
|
|
|
if (dev_pm_skip_resume(dev))
|
2017-11-18 14:35:00 +00:00
|
|
|
return 0;
|
|
|
|
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
return pm_generic_resume_noirq(dev);
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_resume_early - Resume device using ACPI.
|
|
|
|
* @dev: Device to Resume.
|
|
|
|
*
|
|
|
|
* Use ACPI to put the given device into the full-power state and carry out the
|
|
|
|
* generic early resume procedure for it during system transition into the
|
2021-06-22 21:39:39 +00:00
|
|
|
* working state, but only do that if device either defines early resume
|
|
|
|
* handler, or does not define power operations at all. Otherwise powering up
|
|
|
|
* of the device is postponed to the normal resume phase.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*/
|
2019-07-01 10:54:10 +00:00
|
|
|
static int acpi_subsys_resume_early(struct device *dev)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
{
|
2021-06-22 21:39:39 +00:00
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-04-18 16:52:30 +00:00
|
|
|
if (dev_pm_skip_resume(dev))
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
return 0;
|
|
|
|
|
2021-06-22 21:39:39 +00:00
|
|
|
if (pm && !pm->resume_early) {
|
|
|
|
dev_dbg(dev, "postponing D0 transition to normal resume stage\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
ret = acpi_dev_resume(dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
return ret ? ret : pm_generic_resume_early(dev);
|
|
|
|
}
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
|
2021-06-22 21:39:39 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_resume - Resume device using ACPI.
|
|
|
|
* @dev: Device to Resume.
|
|
|
|
*
|
|
|
|
* Use ACPI to put the given device into the full-power state if it has not been
|
|
|
|
* powered up during early resume phase, and carry out the generic resume
|
|
|
|
* procedure for it during system transition into the working state.
|
|
|
|
*/
|
|
|
|
static int acpi_subsys_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!dev_pm_skip_resume(dev) && pm && !pm->resume_early) {
|
|
|
|
dev_dbg(dev, "executing postponed D0 transition\n");
|
|
|
|
ret = acpi_dev_resume(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret ? ret : pm_generic_resume(dev);
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_freeze - Run the device driver's freeze callback.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_freeze(struct device *dev)
|
|
|
|
{
|
|
|
|
/*
|
2019-07-01 10:44:25 +00:00
|
|
|
* Resume all runtime-suspended devices before creating a snapshot
|
|
|
|
* image of system memory, because the restore kernel generally cannot
|
|
|
|
* be expected to always handle them consistently and they need to be
|
|
|
|
* put into the runtime-active metastate during system resume anyway,
|
|
|
|
* so it is better to ensure that the state saved in the image will be
|
|
|
|
* always consistent with that.
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
*/
|
2019-07-01 10:44:25 +00:00
|
|
|
pm_runtime_resume(dev);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
return pm_generic_freeze(dev);
|
|
|
|
}
|
2014-05-15 13:40:23 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_freeze);
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
/**
|
2019-07-01 10:54:10 +00:00
|
|
|
* acpi_subsys_restore_early - Restore device using ACPI.
|
|
|
|
* @dev: Device to restore.
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
*/
|
2019-07-01 10:54:10 +00:00
|
|
|
int acpi_subsys_restore_early(struct device *dev)
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
{
|
2019-07-01 10:54:10 +00:00
|
|
|
int ret = acpi_dev_resume(dev);
|
2021-03-27 12:08:22 +00:00
|
|
|
|
2019-07-01 10:54:10 +00:00
|
|
|
return ret ? ret : pm_generic_restore_early(dev);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
}
|
2019-07-01 10:54:10 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
2019-07-01 10:54:29 +00:00
|
|
|
/**
|
|
|
|
* acpi_subsys_poweroff - Run the device driver's poweroff callback.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*
|
|
|
|
* Follow PCI and resume devices from runtime suspend before running their
|
|
|
|
* system poweroff callbacks, unless the driver can cope with runtime-suspended
|
|
|
|
* devices during system suspend and there are no ACPI-specific reasons for
|
|
|
|
* resuming them.
|
|
|
|
*/
|
|
|
|
int acpi_subsys_poweroff(struct device *dev)
|
|
|
|
{
|
|
|
|
if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
|
|
|
|
acpi_dev_needs_resume(dev, ACPI_COMPANION(dev)))
|
|
|
|
pm_runtime_resume(dev);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
2019-07-01 10:54:29 +00:00
|
|
|
return pm_generic_poweroff(dev);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
}
|
2019-07-01 10:54:29 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_subsys_poweroff);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
|
|
|
/**
|
2019-07-01 10:54:29 +00:00
|
|
|
* acpi_subsys_poweroff_late - Run the device driver's poweroff callback.
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
* @dev: Device to handle.
|
2019-07-01 10:54:29 +00:00
|
|
|
*
|
|
|
|
* Carry out the generic late poweroff procedure for @dev and use ACPI to put
|
|
|
|
* it into a low-power state during system transition into a sleep state.
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
*/
|
2019-07-01 10:54:29 +00:00
|
|
|
static int acpi_subsys_poweroff_late(struct device *dev)
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
{
|
2019-07-01 10:54:29 +00:00
|
|
|
int ret;
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
return 0;
|
|
|
|
|
2019-07-01 10:54:29 +00:00
|
|
|
ret = pm_generic_poweroff_late(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return acpi_dev_suspend(dev, device_may_wakeup(dev));
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-07-01 10:54:29 +00:00
|
|
|
* acpi_subsys_poweroff_noirq - Run the driver's "noirq" poweroff callback.
|
|
|
|
* @dev: Device to suspend.
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
*/
|
2019-07-01 10:54:29 +00:00
|
|
|
static int acpi_subsys_poweroff_noirq(struct device *dev)
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
{
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
return 0;
|
|
|
|
|
2019-07-01 10:54:29 +00:00
|
|
|
return pm_generic_poweroff_noirq(dev);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
}
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
|
|
|
|
|
|
|
static struct dev_pm_domain acpi_general_pm_domain = {
|
|
|
|
.ops = {
|
|
|
|
.runtime_suspend = acpi_subsys_runtime_suspend,
|
|
|
|
.runtime_resume = acpi_subsys_runtime_resume,
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
.prepare = acpi_subsys_prepare,
|
2017-10-03 07:11:06 +00:00
|
|
|
.complete = acpi_subsys_complete,
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
.suspend = acpi_subsys_suspend,
|
2021-06-22 21:39:39 +00:00
|
|
|
.resume = acpi_subsys_resume,
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
.suspend_late = acpi_subsys_suspend_late,
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 08:10:16 +00:00
|
|
|
.suspend_noirq = acpi_subsys_suspend_noirq,
|
|
|
|
.resume_noirq = acpi_subsys_resume_noirq,
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
.resume_early = acpi_subsys_resume_early,
|
ACPI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
acpi_subsys_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-26 00:00:19 +00:00
|
|
|
.freeze = acpi_subsys_freeze,
|
2019-07-01 10:54:29 +00:00
|
|
|
.poweroff = acpi_subsys_poweroff,
|
|
|
|
.poweroff_late = acpi_subsys_poweroff_late,
|
|
|
|
.poweroff_noirq = acpi_subsys_poweroff_noirq,
|
2019-07-01 10:54:10 +00:00
|
|
|
.restore_early = acpi_subsys_restore_early,
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
#endif
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2014-09-19 18:27:44 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_pm_detach - Remove ACPI power management from the device.
|
|
|
|
* @dev: Device to take care of.
|
|
|
|
* @power_off: Whether or not to try to remove power from the device.
|
|
|
|
*
|
|
|
|
* Remove the device from the general ACPI PM domain and remove its wakeup
|
|
|
|
* notifier. If @power_off is set, additionally remove power from the device if
|
|
|
|
* possible.
|
|
|
|
*
|
|
|
|
* Callers must ensure proper synchronization of this function with power
|
|
|
|
* management callbacks.
|
|
|
|
*/
|
|
|
|
static void acpi_dev_pm_detach(struct device *dev, bool power_off)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
|
|
|
|
if (adev && dev->pm_domain == &acpi_general_pm_domain) {
|
2016-01-07 15:46:13 +00:00
|
|
|
dev_pm_domain_set(dev, NULL);
|
2014-09-19 18:27:44 +00:00
|
|
|
acpi_remove_pm_notifier(adev);
|
|
|
|
if (power_off) {
|
|
|
|
/*
|
|
|
|
* If the device's PM QoS resume latency limit or flags
|
|
|
|
* have been exposed to user space, they have to be
|
|
|
|
* hidden at this point, so that they don't affect the
|
|
|
|
* choice of the low-power state to put the device into.
|
|
|
|
*/
|
|
|
|
dev_pm_qos_hide_latency_limit(dev);
|
|
|
|
dev_pm_qos_hide_flags(dev);
|
2017-07-21 12:40:49 +00:00
|
|
|
acpi_device_wakeup_disable(adev);
|
2014-09-19 18:27:44 +00:00
|
|
|
acpi_dev_pm_low_power(dev, adev, ACPI_STATE_S0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_pm_attach - Prepare device for ACPI power management.
|
|
|
|
* @dev: Device to prepare.
|
2012-11-26 09:03:06 +00:00
|
|
|
* @power_on: Whether or not to power on the device.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*
|
|
|
|
* If @dev has a valid ACPI handle that has a valid struct acpi_device object
|
|
|
|
* attached to it, install a wakeup notification handler for the device and
|
2012-11-26 09:03:06 +00:00
|
|
|
* add it to the general ACPI PM domain. If @power_on is set, the device will
|
|
|
|
* be put into the ACPI D0 state before the function returns.
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
*
|
|
|
|
* This assumes that the @dev's bus type uses generic power management callbacks
|
|
|
|
* (or doesn't use any power management callbacks at all).
|
|
|
|
*
|
|
|
|
* Callers must ensure proper synchronization of this function with power
|
|
|
|
* management callbacks.
|
|
|
|
*/
|
2012-11-26 09:03:06 +00:00
|
|
|
int acpi_dev_pm_attach(struct device *dev, bool power_on)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
{
|
2019-12-04 01:54:27 +00:00
|
|
|
/*
|
|
|
|
* Skip devices whose ACPI companions match the device IDs below,
|
|
|
|
* because they require special power management handling incompatible
|
|
|
|
* with the generic ACPI PM domain.
|
|
|
|
*/
|
|
|
|
static const struct acpi_device_id special_pm_ids[] = {
|
2021-05-14 19:08:51 +00:00
|
|
|
ACPI_FAN_DEVICE_IDS,
|
2019-12-04 01:54:27 +00:00
|
|
|
{}
|
|
|
|
};
|
2014-01-27 22:10:24 +00:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
2019-12-04 01:54:27 +00:00
|
|
|
if (!adev || !acpi_match_device_ids(adev, special_pm_ids))
|
2018-05-09 10:17:52 +00:00
|
|
|
return 0;
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
|
2015-07-27 15:03:57 +00:00
|
|
|
/*
|
|
|
|
* Only attach the power domain to the first device if the
|
|
|
|
* companion is shared by multiple. This is to prevent doing power
|
|
|
|
* management twice.
|
|
|
|
*/
|
|
|
|
if (!acpi_device_is_first_physical_node(adev, dev))
|
2018-05-09 10:17:52 +00:00
|
|
|
return 0;
|
2015-07-27 15:03:57 +00:00
|
|
|
|
2014-07-22 23:00:45 +00:00
|
|
|
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
|
2016-01-07 15:46:13 +00:00
|
|
|
dev_pm_domain_set(dev, &acpi_general_pm_domain);
|
2012-11-26 09:03:06 +00:00
|
|
|
if (power_on) {
|
|
|
|
acpi_dev_pm_full_power(adev);
|
2017-07-21 12:40:49 +00:00
|
|
|
acpi_device_wakeup_disable(adev);
|
2012-11-26 09:03:06 +00:00
|
|
|
}
|
2014-09-19 18:27:35 +00:00
|
|
|
|
|
|
|
dev->pm_domain->detach = acpi_dev_pm_detach;
|
2018-05-09 10:17:52 +00:00
|
|
|
return 1;
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 00:41:01 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_pm_attach);
|
2021-06-09 18:40:17 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_storage_d3 - Check if D3 should be used in the suspend path
|
|
|
|
* @dev: Device to check
|
|
|
|
*
|
|
|
|
* Return %true if the platform firmware wants @dev to be programmed
|
|
|
|
* into D3hot or D3cold (if supported) in the suspend path, or %false
|
|
|
|
* when there is no specific preference. On some platforms, if this
|
|
|
|
* hint is ignored, @dev may remain unresponsive after suspending the
|
|
|
|
* platform as a whole.
|
|
|
|
*
|
|
|
|
* Although the property has storage in the name it actually is
|
|
|
|
* applied to the PCIe slot and plugging in a non-storage device the
|
|
|
|
* same platform restrictions will likely apply.
|
|
|
|
*/
|
|
|
|
bool acpi_storage_d3(struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
u8 val;
|
|
|
|
|
2021-06-09 18:40:18 +00:00
|
|
|
if (force_storage_d3())
|
|
|
|
return true;
|
|
|
|
|
2021-06-09 18:40:17 +00:00
|
|
|
if (!adev)
|
|
|
|
return false;
|
|
|
|
if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
|
|
|
|
&val))
|
|
|
|
return false;
|
|
|
|
return val == 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_storage_d3);
|
|
|
|
|
2021-10-18 12:17:27 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_state_d0 - Tell if the device is in D0 power state
|
|
|
|
* @dev: Physical device the ACPI power state of which to check
|
|
|
|
*
|
|
|
|
* On a system without ACPI, return true. On a system with ACPI, return true if
|
|
|
|
* the current ACPI power state of the device is D0, or false otherwise.
|
|
|
|
*
|
|
|
|
* Note that the power state of a device is not well-defined after it has been
|
|
|
|
* passed to acpi_device_set_power() and before that function returns, so it is
|
|
|
|
* not valid to ask for the ACPI power state of the device in that time frame.
|
|
|
|
*
|
|
|
|
* This function is intended to be used in a driver's probe or remove
|
|
|
|
* function. See Documentation/firmware-guide/acpi/low-power-probe.rst for
|
|
|
|
* more information.
|
|
|
|
*/
|
|
|
|
bool acpi_dev_state_d0(struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
|
|
|
|
if (!adev)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return adev->power.state == ACPI_STATE_D0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_state_d0);
|
|
|
|
|
2013-05-16 20:29:28 +00:00
|
|
|
#endif /* CONFIG_PM */
|