Merge branch 'pm-sleep'

* pm-sleep:
  PM / hibernate: fixed typo in comment
  PM / sleep: unregister wakeup source when disabling device wakeup
  PM / sleep: Introduce command line argument for sleep state enumeration
  PM / sleep: Use valid_state() for platform-dependent sleep states only
  PM / sleep: Add state field to pm_states[] entries
  PM / sleep: Update device PM documentation to cover direct_complete
  PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
  PM / hibernate: Fix memory corruption in resumedelay_setup()
  PM / hibernate: convert simple_strtoul to kstrtoul
  PM / hibernate: Documentation: Fix script for unswapping
  PM / hibernate: no kernel_power_off when pm_power_off NULL
  PM / hibernate: use unsigned local variables in swsusp_show_speed()

16 files changed, 339 insertions, 143 deletions

diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 64c9276e9421..f4551816329e 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -7,19 +7,30 @@ Description:
                 subsystem.
 
 What:           /sys/power/state
-Date:           August 2006
+Date:           May 2014
 Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
-                The /sys/power/state file controls the system power state.
-                Reading from this file returns what states are supported,
-                which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
-                (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
-                (Suspend-to-Disk).
+                The /sys/power/state file controls system sleep states.
+                Reading from this file returns the available sleep state
+                labels, which may be "mem", "standby", "freeze" and "disk"
+                (hibernation).  The meanings of the first three labels depend on
+                the relative_sleep_states command line argument as follows:
+                 1) relative_sleep_states = 1
+                    "mem", "standby", "freeze" represent non-hibernation sleep
+                    states from the deepest ("mem", always present) to the
+                    shallowest ("freeze").  "standby" and "freeze" may or may
+                    not be present depending on the capabilities of the
+                    platform.  "freeze" can only be present if "standby" is
+                    present.
+                 2) relative_sleep_states = 0 (default)
+                    "mem" - "suspend-to-RAM", present if supported.
+                    "standby" - "power-on suspend", present if supported.
+                    "freeze" - "suspend-to-idle", always present.
 
                 Writing to this file one of these strings causes the system to
-                transition into that state. Please see the file
-                Documentation/power/states.txt for a description of each of
-                these states.
+                transition into the corresponding state, if available.  See
+                Documentation/power/states.txt for a description of what
+                "suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean.
 
 What:           /sys/power/disk
 Date:           September 2006
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 30a8ad0dae53..2b64fb221790 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         [KNL, SMP] Set scheduler's default relax_domain_level.
                         See Documentation/cgroups/cpusets.txt.
 
+        relative_sleep_states=
+                        [SUSPEND] Use sleep state labeling where the deepest
+                        state available other than hibernation is always "mem".
+                        Format: { "0" | "1" }
+                        0 -- Traditional sleep state labels.
+                        1 -- Relative sleep state labels.
+
         reserve=        [KNL,BUGS] Force the kernel to ignore some iomem area
 
         reservetop=     [X86-32]
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 47d46dff70f7..d172bce0fd49 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -2,6 +2,7 @@ Device Power Management
 
 Copyright (c) 2010-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
 Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu>
+Copyright (c) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
 
 Most of the code in Linux is device drivers, so most of the Linux power
@@ -326,6 +327,20 @@ the phases are:
         driver in some way for the upcoming system power transition, but it
         should not put the device into a low-power state.
 
+        For devices supporting runtime power management, the return value of the
+        prepare callback can be used to indicate to the PM core that it may
+        safely leave the device in runtime suspend (if runtime-suspended
+        already), provided that all of the device's descendants are also left in
+        runtime suspend.  Namely, if the prepare callback returns a positive
+        number and that happens for all of the descendants of the device too,
+        and all of them (including the device itself) are runtime-suspended, the
+        PM core will skip the suspend, suspend_late and suspend_noirq suspend
+        phases as well as the resume_noirq, resume_early and resume phases of
+        the following system resume for all of these devices.   In that case,
+        the complete callback will be called directly after the prepare callback
+        and is entirely responsible for bringing the device back to the
+        functional state as appropriate.
+
     2.  The suspend methods should quiesce the device to stop it from performing
         I/O.  They also may save the device registers and put it into the
         appropriate low-power state, depending on the bus type the device is on,
@@ -400,12 +415,23 @@ When resuming from freeze, standby or memory sleep, the phases are:
         the resume callbacks occur; it's not necessary to wait until the
         complete phase.
 
+        Moreover, if the preceding prepare callback returned a positive number,
+        the device may have been left in runtime suspend throughout the whole
+        system suspend and resume (the suspend, suspend_late, suspend_noirq
+        phases of system suspend and the resume_noirq, resume_early, resume
+        phases of system resume may have been skipped for it).  In that case,
+        the complete callback is entirely responsible for bringing the device
+        back to the functional state after system suspend if necessary.  [For
+        example, it may need to queue up a runtime resume request for the device
+        for this purpose.]  To check if that is the case, the complete callback
+        can consult the device's power.direct_complete flag.  Namely, if that
+        flag is set when the complete callback is being run, it has been called
+        directly after the preceding prepare and special action may be required
+        to make the device work correctly afterward.
+
 At the end of these phases, drivers should be as functional as they were before
 suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are
-gated on.  Even if the device was in a low-power state before the system sleep
-because of runtime power management, afterwards it should be back in its
-full-power state.  There are multiple reasons why it's best to do this; they are
-discussed in more detail in Documentation/power/runtime_pm.txt.
+gated on.
 
 However, the details here may again be platform-specific.  For example,
 some systems support multiple "run" states, and the mode in effect at
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 5f96daf8566a..e1bee8a4aaac 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -2,6 +2,7 @@ Runtime Power Management Framework for I/O Devices
 
 (C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
 (C) 2010 Alan Stern <stern@rowland.harvard.edu>
+(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
 1. Introduction
 
@@ -444,6 +445,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
   bool pm_runtime_status_suspended(struct device *dev);
     - return true if the device's runtime PM status is 'suspended'
 
+  bool pm_runtime_suspended_if_enabled(struct device *dev);
+    - return true if the device's runtime PM status is 'suspended' and its
+      'power.disable_depth' field