summaryrefslogtreecommitdiffstats
path: root/Documentation/power
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2017-06-24 01:58:53 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2017-06-28 01:52:52 +0200
commitde3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8 (patch)
treed74445102cc3ff9680422c69603d575646420b8d /Documentation/power
parent0847684cfc5f0e9f009919bfdcb041d60e19b856 (diff)
downloadlinux-de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8.tar.gz
linux-de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8.tar.bz2
linux-de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8.zip
PM / core: Drop run_wake flag from struct dev_pm_info
The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system wakeup signaling has always been rather artificial. The only practical reason for it to exist at the core level was that ACPI and PCI treated those two cases differently, but that's not the case any more after recent changes. For this reason, get rid of the run_wake flag and, when applicable, use device_set_wakeup_capable() and device_can_wakeup() instead of device_set_run_wake() and device_run_wake(), respectively. 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>
Diffstat (limited to 'Documentation/power')
-rw-r--r--Documentation/power/runtime_pm.txt7
1 files changed, 2 insertions, 5 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index ee69d7532172..0fde3dcf077a 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -105,9 +105,9 @@ knows what to do to handle the device).
In particular, if the driver requires remote wakeup capability (i.e. hardware
mechanism allowing the device to request a change of its power state, such as
-PCI PME) for proper functioning and device_run_wake() returns 'false' for the
+PCI PME) for proper functioning and device_can_wakeup() returns 'false' for the
device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
-device_run_wake() returns 'true' for the device and the device is put into a
+device_can_wakeup() returns 'true' for the device and the device is put into a
low-power state during the execution of the suspend callback, it is expected
that remote wakeup will be enabled for the device. Generally, remote wakeup
should be enabled for all input devices put into low-power states at run time.
@@ -253,9 +253,6 @@ defined in include/linux/pm.h:
being executed for that device and it is not practical to wait for the
suspend to complete; means "start a resume as soon as you've suspended"
- unsigned int run_wake;
- - set if the device is capable of generating runtime wake-up events
-
enum rpm_status runtime_status;
- the runtime PM status of the device; this field's initial value is
RPM_SUSPENDED, which means that each device is initially regarded by the