aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2011-02-08 17:26:02 -0500
committerRafael J. Wysocki <rjw@sisk.pl>2011-03-14 19:43:14 -0400
commitcb8f51bdadb7969139c2e39c2defd4cde98c1ea8 (patch)
treea6d6e20878460d50b8f61d5fe3237818c54065eb /Documentation/power
parent4681b17154b3fd81f898802262985f662344e6ed (diff)
PM: Do not create wakeup sysfs files for devices that cannot wake up
Currently, wakeup sysfs attributes are created for all devices, regardless of whether or not they are wakeup-capable. This is excessive and complicates wakeup device identification from user space (i.e. to identify wakeup-capable devices user space has to read /sys/devices/.../power/wakeup for all devices and see if they are not empty). Fix this issue by avoiding to create wakeup sysfs files for devices that cannot wake up the system from sleep states (i.e. whose power.can_wakeup flags are unset during registration) and modify device_set_wakeup_capable() so that it adds (or removes) the relevant sysfs attributes if a device's wakeup capability status is changed. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Diffstat (limited to 'Documentation/power')
-rw-r--r--Documentation/power/devices.txt20
1 files changed, 10 insertions, 10 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 57080cd74575..dd9b49251db3 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -159,18 +159,18 @@ matter, and the kernel is responsible for keeping track of it. By contrast,
159whether or not a wakeup-capable device should issue wakeup events is a policy 159whether or not a wakeup-capable device should issue wakeup events is a policy
160decision, and it is managed by user space through a sysfs attribute: the 160decision, and it is managed by user space through a sysfs attribute: the
161power/wakeup file. User space can write the strings "enabled" or "disabled" to 161power/wakeup file. User space can write the strings "enabled" or "disabled" to
162set or clear the should_wakeup flag, respectively. Reads from the file will 162set or clear the "should_wakeup" flag, respectively. This file is only present
163return the corresponding string if can_wakeup is true, but if can_wakeup is 163for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set)
164false then reads will return an empty string, to indicate that the device 164and is created (or removed) by device_set_wakeup_capable(). Reads from the
165doesn't support wakeup events. (But even though the file appears empty, writes 165file will return the corresponding string.
166will still affect the should_wakeup flag.)
167 166
168The device_may_wakeup() routine returns true only if both flags are set. 167The device_may_wakeup() routine returns true only if both flags are set.
169Drivers should check this routine when putting devices in a low-power state 168This information is used by subsystems, like the PCI bus type code, to see
170during a system sleep transition, to see whether or not to enable the devices' 169whether or not to enable the devices' wakeup mechanisms. If device wakeup
171wakeup mechanisms. However for runtime power management, wakeup events should 170mechanisms are enabled or disabled directly by drivers, they also should use
172be enabled whenever the device and driver both support them, regardless of the 171device_may_wakeup() to decide what to do during a system sleep transition.
173should_wakeup flag. 172However for runtime power management, wakeup events should be enabled whenever
173the device and driver both support them, regardless of the should_wakeup flag.
174 174
175 175
176/sys/devices/.../power/control files 176/sys/devices/.../power/control files