Documentation/power/pci.rst

378 driver has to provide a pm->runtime_suspend() callback (see below), which is
379 run by pci_pm_runtime_suspend() as the first action.  If the driver's callback
392 It is expected that the device driver's pm->runtime_suspend() callback will
400 driver provides a pm->runtime_resume() callback (see below).  However, before
401 the driver's callback is executed, pci_pm_runtime_resume() brings the device
404 callback need not worry about the PCI-specific aspects of the device resume.
417 callback, if defined, and if that callback doesn't return error code (or is not
424 pm->runtime_idle() callback.
432 each phase involves executing the same subsystem-level callback for every device
452 driver's pm->prepare() callback if defined (i.e. if the driver's struct
457 suspend callback is executed, if present, and its result is returned.  Next, if
463 callback is executed, if defined, and its result is returned if it fails.
468 the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
477 configuration registers of the device are saved if the driver's callback hasn't
480 returns success.  Otherwise the device driver's pm->suspend_noirq() callback is
530 early resume callback is executed and its result is returned.  Otherwise, the
531 device driver's pm->resume_noirq() callback is executed, if defined, and its
539 Section 3), the driver's legacy resume callback is executed and its result is
541 its driver's pm->resume() callback is executed, if defined (the callback's
550 callback, if defined.
576 the device driver's pm->freeze() callback, if defined, instead of pm->suspend(),
606 callback, if defined, instead of pm->resume_noirq().
609 driver's pm->thaw() callback instead of pm->resume().  It is executed
717 The prepare() callback is executed during system suspend, during hibernation
722 This callback is only necessary if the driver's device has children that in
724 callback is to prevent new children of the device from being registered until
727 In addition to that the prepare() callback may carry out some operations
736 The suspend() callback is only executed during system suspend, after prepare()
739 This callback is expected to quiesce the device and prepare it to be put into a
741 not recommended) that a PCI driver's suspend() callback save the standard
755 While the suspend() callback is being executed, the driver's interrupt handler
758 carried out in this callback.
763 The suspend_noirq() callback is only executed during system suspend, after
775 The freeze() callback is hibernation-specific and is executed in two situations,
781 The role of this callback is analogous to the role of the suspend() callback
786 In that cases the freeze() callback should not prepare the device system wakeup
793 The freeze_noirq() callback is hibernation-specific.  It is executed during
800 The role of this callback is analogous to the role of the suspend_noirq()
801 callback described above and it very rarely is necessary to define
810 The poweroff() callback is hibernation-specific.  It is executed when the system
815 The role of this callback is analogous to the role of the suspend() and freeze()
819 the poweroff() callback should use pci_prepare_to_sleep() and
827 The poweroff_noirq() callback is hibernation-specific.  It is executed after
830 The role of this callback is analogous to the role of the suspend_noirq() and
840 The resume_noirq() callback is only executed during system resume, after the
842 be invoked while resume_noirq() is running, so this callback can carry out
854 The resume() callback is only executed during system resume, after
858 This callback is responsible for restoring the pre-suspend configuration of the
865 The thaw_noirq() callback is hibernation-specific.  It is executed after a
872 The role of this callback is analogous to the role of resume_noirq().  The
880 The thaw() callback is hibernation-specific.  It is executed after thaw_noirq()
884 This callback is responsible for restoring the pre-freeze configuration of
890 The restore_noirq() callback is hibernation-specific.  It is executed in the
895 This callback is analogous to resume_noirq() with the exception that it cannot
906 The restore() callback is hibernation-specific.  It is executed after
910 This callback is analogous to resume(), just like restore_noirq() is analogous
920 The complete() callback is executed in the following situations:
933 This callback is entirely optional, although it may be necessary if the
934 prepare() callback performs operations that need to be reversed.
939 The runtime_suspend() callback is specific to device runtime power management
944 This callback is responsible for freezing the device and preparing it to be
951 The runtime_resume() callback is specific to device runtime PM.  It is executed
956 This callback is responsible for restoring the normal functionality of the
964 The runtime_idle() callback is specific to device runtime PM.  It is executed
970 This callback is optional, but if it is not implemented or if it returns 0, the
972 cause the driver's runtime_suspend() callback to be executed.
974 3.1.18. Pointing Multiple Callback Pointers to One Routine
1014 value from pci_pm_prepare() only if the ->prepare callback provided by the
1055 the runtime_idle() callback to prevent the device from being suspended again
1056 every time right after the runtime_resume() callback has returned
1057 (alternatively, the runtime_suspend() callback will have to check if the
1065 probe callback provided by the device's driver.
1069 to decrement the device's runtime PM usage counter in its probe callback
1078 It is important to remember that the driver's runtime_suspend() callback
1090 When the driver's remove callback runs, it has to balance the decrementation
1092 if it has decremented the counter in its probe callback, it must run
1093 pm_runtime_get_noresume() in its remove callback.  [Since the core carries
1095 before running the driver's remove callback, the runtime PM of the device