driver-api/pm/devices.rst

272 executing callbacks for every device before the next phase begins.  Not all
273 buses or classes support all these callbacks and not all drivers use all the
274 callbacks.  The various phases always run after tasks have been frozen and
279 All phases use PM domain, bus, type, class or driver callbacks (that is, methods
281 ``dev->class->pm`` or ``dev->driver->pm``).  These callbacks are regarded by the
282 PM core as mutually exclusive.  Moreover, PM domain callbacks always take
283 precedence over all of the other callbacks and, for example, type callbacks take
284 precedence over bus, class and driver callbacks.  To be precise, the following
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
350 	that if a device has system-sleep callbacks but does not support runtime
419 If any of these callbacks returns an error, the system won't enter the desired
457 	soon as the ``->resume`` callbacks occur; it's not necessary to wait
464 	``->resume_early``, and ``->resume`` callbacks may have been
501 These callbacks may return an error value, but the PM core will ignore such
511 more phases for hibernation, with a different set of callbacks.  These phases
572 The ``->poweroff``, ``->poweroff_late`` and ``->poweroff_noirq`` callbacks
574 and ``->suspend_noirq`` callbacks, respectively.  A notable difference is
651 callbacks discussed above, because the callbacks occur too late or too early.
710 of power management callbacks analogous to the subsystem-level and device driver
711 callbacks that are executed for the given device during all power transitions,
712 instead of the respective subsystem-level callbacks.  Specifically, if a
716 remaining callbacks.  In other words, power management domain callbacks, if
717 defined for the given device, always take precedence over the callbacks provided
721 needing to use the same device driver power management callbacks in many
723 support for power domains into subsystem-level callbacks, for example by
728 runtime PM callbacks may be invoked with disabled interrupts (see
751 power states due to runtime power management.  The system sleep PM callbacks
769 from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
770 invoking device drivers' ``->suspend`` callbacks (or equivalent).
778 suspend upfront in their ``->suspend`` callbacks, but that may not be really
786 ``->suspend_noirq`` callbacks provided by the driver if the device remains in
791 be valid in general.]  If the middle-layer system-wide PM callbacks are present
792 for the device then they are responsible for skipping these driver callbacks;
794 determine whether they need to skip the driver callbacks by testing the return
798 and ``->thaw_early`` callbacks are skipped in hibernation if the device remained
800 middle-layer callbacks are present for the device, they are responsible for
818 "early" resume callbacks to be skipped if the device can be left in suspend
823 not affected by ``DPM_FLAG_MAY_SKIP_RESUME`` at all.  [All callbacks are
825 and whether or not any driver callbacks
834 has a reason to prevent the driver's "noirq" and "early" resume callbacks from
843 for the driver's "noirq" and "early" resume callbacks to be skipped.  Whether or
848 callbacks should be skipped and the device's runtime PM status will be set to
859 callbacks are skipped, its system-wide "noirq" and "early" resume callbacks, if
863 callbacks back-to-back with its ``->runtime_suspend`` one (without the
864 intervening ``->runtime_resume`` and system-wide suspend callbacks) and the
870 system-wide suspend-resume callbacks of the driver are present, for example.]
873 system-wide "noirq" and "early" resume callbacks may be skipped while its "late"
874 and "noirq" suspend callbacks may have been executed (in principle, regardless