- not communicate with the CPU(s) and RAM until its bus type's
- ->runtime_resume() callback is executed for it. The run-time PM status of
- a device after successful execution of its bus type's ->runtime_suspend()
- callback is 'suspended'.
-
- * If the bus type's ->runtime_suspend() callback returns -EBUSY or -EAGAIN,
- the device's run-time PM status is supposed to be 'active', which means that
- the device _must_ be fully operational afterwards.
-
- * If the bus type's ->runtime_suspend() callback returns an error code
- different from -EBUSY or -EAGAIN, the PM core regards this as a fatal
- error and will refuse to run the helper functions described in Section 4
- for the device, until the status of it is directly set either to 'active'
- or to 'suspended' (the PM core provides special helper functions for this
- purpose).
-
-In particular, if the driver requires remote wakeup capability for proper
-functioning and device_run_wake() 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 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)
-will be enabled for the device. Generally, remote wake-up should be enabled
-for all input devices put into a low power state at run time.
-
-The ->runtime_resume() callback is executed by the PM core for the bus type of
-the device being woken up. The bus type's callback is then _entirely_
-_responsible_ for handling the device as appropriate, which may, but need not
-include executing the device driver's own ->runtime_resume() callback (from the
-PM core's point of view it is not necessary to implement a ->runtime_resume()
-callback in a device driver as long as the bus type's ->runtime_resume() knows
-what to do to handle the device).
-
- * Once the bus type's ->runtime_resume() callback has completed successfully,
- the PM core regards the device as fully operational, which means that the
- device _must_ be able to complete I/O operations as needed. The run-time
- PM status of the device is then 'active'.
-
- * If the bus type's ->runtime_resume() callback returns an error code, the PM
- core regards this as a fatal error and will refuse to run the helper
- functions described in Section 4 for the device, until its status is
- directly set either to 'active' or to 'suspended' (the PM core provides
- special helper functions for this purpose).
-
-The ->runtime_idle() callback is executed by the PM core for the bus type of
-given device whenever the device appears to be idle, which is indicated to the
-PM core by two counters, the device's usage counter and the counter of 'active'
-children of the device.
+ not communicate with the CPU(s) and RAM until the subsystem-level resume
+ callback is executed for it. The run-time PM status of a device after
+ successful execution of the subsystem-level suspend callback is 'suspended'.
+
+ * If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
+ the device's run-time PM status is 'active', which means that the device
+ _must_ be fully operational afterwards.
+
+ * If the subsystem-level suspend callback returns an error code different
+ from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
+ refuse to run the helper functions described in Section 4 for the device,
+ until the status of it is directly set either to 'active', or to 'suspended'
+ (the PM core provides special helper functions for this purpose).
+
+In particular, if the driver requires remote wake-up 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
+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 low
+power state during the execution of the subsystem-level suspend callback, it is
+expected that remote wake-up will be enabled for the device. Generally, remote
+wake-up should be enabled for all input devices put into a low power state at
+run time.
+
+The subsystem-level resume callback is _entirely_ _responsible_ for handling the
+resume of the device as appropriate, which may, but need not include executing
+the device driver's own ->runtime_resume() callback (from the PM core's point of
+view it is not necessary to implement a ->runtime_resume() callback in a device
+driver as long as the subsystem-level resume callback knows what to do to handle
+the device).
+
+ * Once the subsystem-level resume callback has completed successfully, the PM
+ core regards the device as fully operational, which means that the device
+ _must_ be able to complete I/O operations as needed. The run-time PM status
+ of the device is then 'active'.
+
+ * If the subsystem-level resume callback returns an error code, the PM core
+ regards this as a fatal error and will refuse to run the helper functions
+ described in Section 4 for the device, until its status is directly set
+ either to 'active' or to 'suspended' (the PM core provides special helper
+ functions for this purpose).
+
+The subsystem-level idle callback is executed by the PM core whenever the device
+appears to be idle, which is indicated to the PM core by two counters, the
+device's usage counter and the counter of 'active' children of the device.