lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 29 Nov 2009 16:34:01 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	pm list <linux-pm@...ts.linux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Oliver Neukum <oliver@...kum.org>,
	Shaohua Li <shaohua.li@...el.com>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Francois Romieu <romieu@...zoreil.com>,
	Len Brown <lenb@...nel.org>
Subject: [RFC][PATCH 1/12] PM: Add flag for devices capable of generating run-time wake-up events

From: Rafael J. Wysocki <rjw@...k.pl>

Apparently, there are devices that can wake up the system from sleep
states and yet are incapable of generating wake-up events at run
time.  Thus, introduce a flag indicating if given device is capable
of generating run-time wake-up events.

Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
---
 Documentation/power/runtime_pm.txt |    7 +++++--
 include/linux/pm.h                 |    8 +++++---
 include/linux/pm_runtime.h         |   12 ++++++++++++
 3 files changed, 22 insertions(+), 5 deletions(-)

Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -179,9 +179,10 @@ typedef struct pm_message {
  *	This need not mean that the device should be put into a low power state.
  *	For example, if the device is behind a link which is about to be turned
  *	off, the device may remain at full power.  If the device does go to low
- *	power and if device_may_wakeup(dev) is true, remote wake-up (i.e., a
- *	hardware mechanism allowing the device to request a change of its power
- *	state, such as PCI PME) should be enabled for it.
+ *	power and is capable of generating run-time wake-up events, remote
+ *	wake-up (i.e., a hardware mechanism allowing the device to request a
+ *	change of its power state via a wake-up event, such as PCI PME) should
+ *	be enabled for it.
  *
  * @runtime_resume: Put the device into the fully active state in response to a
  *	wake-up event generated by hardware or at the request of software.  If
@@ -434,6 +435,7 @@ struct dev_pm_info {
 	unsigned int		idle_notification:1;
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
+	unsigned int		run_wake:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;
Index: linux-2.6/Documentation/power/runtime_pm.txt
===================================================================
--- linux-2.6.orig/Documentation/power/runtime_pm.txt
+++ linux-2.6/Documentation/power/runtime_pm.txt
@@ -71,9 +71,9 @@ what to do to handle the device).
     purpose).
 
 In particular, if the driver requires remote wakeup capability for proper
-functioning and device_may_wakeup() returns 'false' for the device, then
+functioning and device_run_wake() returns 'false' for the device, then
 ->runtime_suspend() should return -EBUSY.  On the other hand, if
-device_may_wakeup() returns 'true' for the device and the device is put
+device_run_wake() returns 'true' for the device and the device is put
 into a low power state during the execution of its bus type's
 ->runtime_suspend(), it is expected that remote wake-up (i.e. hardware mechanism
 allowing the device to request a change of its power state, such as PCI PME)
@@ -214,6 +214,9 @@ 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 run-time wake-up events
+
   enum rpm_status runtime_status;
     - the run-time PM status of the device; this field's initial value is
       RPM_SUSPENDED, which means that each device is initially regarded by the
Index: linux-2.6/include/linux/pm_runtime.h
===================================================================
--- linux-2.6.orig/include/linux/pm_runtime.h
+++ linux-2.6/include/linux/pm_runtime.h
@@ -50,6 +50,16 @@ static inline void pm_runtime_put_noidle
 	atomic_add_unless(&dev->power.usage_count, -1, 0);
 }
 
+static inline bool device_run_wake(struct device *dev)
+{
+	return dev->power.run_wake;
+}
+
+static inline void device_set_run_wake(struct device *dev, bool enable)
+{
+	dev->power.run_wake = enable;
+}
+
 #else /* !CONFIG_PM_RUNTIME */
 
 static inline int pm_runtime_idle(struct device *dev) { return -ENOSYS; }
@@ -73,6 +83,8 @@ static inline bool pm_children_suspended
 static inline void pm_suspend_ignore_children(struct device *dev, bool en) {}
 static inline void pm_runtime_get_noresume(struct device *dev) {}
 static inline void pm_runtime_put_noidle(struct device *dev) {}
+static inline bool device_run_wake(struct device *dev) { return false; }
+static inline void device_set_run_wake(struct device *dev, bool enable) {}
 
 #endif /* !CONFIG_PM_RUNTIME */
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ