Lines Matching refs:callbacks

273 hibernation state ("suspend-to-disk").  Each phase involves executing callbacks
275 support all these callbacks and not all drivers use all the callbacks.  The
280 All phases use PM domain, bus, type, class or driver callbacks (that is, methods
282 dev->driver->pm).  These callbacks are regarded by the PM core as mutually
283 exclusive.  Moreover, PM domain callbacks always take precedence over all of the
284 other callbacks and, for example, type callbacks take precedence over bus, class
285 and driver callbacks.  To be precise, the following rules are used to determine
300 This allows PM domains and device types to override callbacks provided by bus
303 The PM domain, type, class and bus callbacks may in turn invoke device- or
380 If any of these callbacks returns an error, the system won't enter the desired
415 	the resume callbacks occur; it's not necessary to wait until the
456 These callbacks may return an error value, but the PM core will ignore such
466 callbacks.  These phases always run after tasks have been frozen and memory has
526 The poweroff, poweroff_late and poweroff_noirq callbacks should do essentially
527 the same things as the suspend, suspend_late and suspend_noirq callbacks,
607 defined in include/linux/pm.h, providing a set of power management callbacks
608 analogous to the subsystem-level and device driver callbacks that are executed
610 subsystem-level callbacks.  Specifically, if a device's pm_domain pointer is
613 analogously for all of the remaining callbacks.  In other words, power
614 management domain callbacks, if defined for the given device, always take
615 precedence over the callbacks provided by the device's subsystem (e.g. bus
619 needing to use the same device driver power management callbacks in many
621 support for power domains into subsystem-level callbacks, for example by
661 callbacks discussed above, because the callbacks occur too late or too early.
682 power states due to runtime power management.  The system sleep PM callbacks