Lines Matching refs:callback
62 callback, the PM core will invoke the corresponding driver callback stored in
65 The PM core always checks which callback to use in the order given above, so the
75 interrupts disabled. This implies that the callback routines in question must
80 The subsystem-level suspend callback, if present, is _entirely_ _responsible_
82 include executing the device driver's own ->runtime_suspend() callback (from the
84 callback in a device driver as long as the subsystem-level suspend callback
87 * Once the subsystem-level suspend callback (or the driver suspend callback,
92 RAM until the appropriate resume callback is executed for it. The runtime
93 PM status of a device after successful execution of the suspend callback is
96 * If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
100 * If the suspend callback returns an error code different from -EBUSY and
111 low-power state during the execution of the suspend callback, it is expected
115 The subsystem-level resume callback, if present, is _entirely_ _responsible_ for
117 include executing the device driver's own ->runtime_resume() callback (from the
119 callback in a device driver as long as the subsystem-level resume callback knows
122 * Once the subsystem-level resume callback (or the driver resume callback, if
128 * If the resume callback returns an error code, the PM core regards this as a
134 The idle callback (a subsystem-level one, if present, or the driver one) is
142 idle callback with the device as its argument.
144 The action performed by the idle callback is totally dependent on the subsystem
148 device in that case. If there is no idle callback, or if the callback returns
153 this circumstance). To prevent this (for example, if the callback routine has
240 callback
311 - execute the subsystem-level idle callback for the device; returns an
313 already being executed; if there is no callback or the callback returns 0
317 - execute the subsystem-level suspend callback for the device; returns 0 on
330 - execute the subsystem-level resume callback for the device; returns 0 on
338 - submit a request to execute the subsystem-level idle callback for the
343 - schedule the execution of the subsystem-level suspend callback for the
348 - schedule the execution of the subsystem-level suspend callback for the
358 - submit a request to execute the subsystem-level resume callback for the
408 necessary to execute the subsystem-level resume callback for the device
416 necessary to execute the subsystem-level resume callback for the device to
554 ->probe() callback will likely need to wake it up using one of the PM core's
561 request to execute the subsystem-level idle callback for the device at that
566 notifier callback in __device_release_driver(), which is necessary, because the
603 the subsystem-level system suspend callback is responsible for changing the
638 ->suspend() callback and decrements it after calling the ->resume() callback.
641 following the return of the ->resume() callback, the ->runtime_idle() callback
658 callback returns a positive number for a device, that indicates to the PM core
663 complete callback, which is then entirely responsible for handling the device
673 right before executing the subsystem-level .prepare() callback for it and
675 subsystem-level .suspend() callback for it. In addition to that the PM core
677 device right before executing the subsystem-level .suspend_late() callback
682 callback and right after executing the subsystem-level .complete() callback
692 - invoke the ->runtime_suspend() callback provided by the driver of this
696 - invoke the ->runtime_resume() callback provided by the driver of this
701 callback provided by its driver and return its result, or return 0 if not
706 callback provided by the device's driver and return its result, or return
710 - invoke the ->resume() callback provided by the driver of this device and,
714 - invoke the ->resume_noirq() callback provided by the driver of this device
718 callback provided by its driver and return its result, or return 0 if not
723 callback provided by the device's driver and return its result, or return
728 callback provided by its driver and return its result, or return 0 if not
733 callback provided by the device's driver and return its result, or return
738 callback provided by its driver and return its result, or return 0 if not
743 callback provided by the device's driver and return its result, or return
747 - invoke the ->restore() callback provided by the driver of this device and,
751 - invoke the ->restore_noirq() callback provided by the device's driver
761 poweroff and runtime suspend callback, and similarly for system resume, thaw,
833 autosuspend delay time has expired. If the ->runtime_suspend() callback
835 in the future (as it normally would be if the callback invoked
837 autosuspend. The ->runtime_suspend() callback can't do this rescheduling
839 suspending (i.e., while the callback is running).
902 the foo_runtime_suspend() callback may race with foo_read_or_write().
910 callback while holding its private lock. If the function returns a nonzero
911 value then the delay has not yet expired and the callback should return