Lines Matching refs:callback

369 driver has to provide a pm->runtime_suspend() callback (see below), which is
370 run by pci_pm_runtime_suspend() as the first action.  If the driver's callback
383 It is expected that the device driver's pm->runtime_suspend() callback will
391 driver provides a pm->runtime_resume() callback (see below).  However, before
392 the driver's callback is executed, pci_pm_runtime_resume() brings the device
395 callback need not worry about the PCI-specific aspects of the device resume.
408 callback, if defined, and if that callback doesn't return error code (or is not
415 pm->runtime_idle() callback.
423 involves executing the same subsystem-level callback for every device belonging
442 driver's pm->prepare() callback if defined (i.e. if the driver's struct
447 suspend callback is executed, if present, and its result is returned.  Next, if
453 callback is executed, if defined, and its result is returned if it fails.
458 the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
467 configuration registers of the device are saved if the driver's callback hasn't
470 returns success.  Otherwise the device driver's pm->suspend_noirq() callback is
519 early resume callback is executed and its result is returned.  Otherwise, the
520 device driver's pm->resume_noirq() callback is executed, if defined, and its
528 Section 3), the driver's legacy resume callback is executed and its result is
530 its driver's pm->resume() callback is executed, if defined (the callback's
539 callback, if defined.
564 the device driver's pm->freeze() callback, if defined, instead of pm->suspend(),
594 driver's pm->thaw_noirq() callback, if defined, instead of pm->resume_noirq().
597 driver's pm->thaw() callback instead of pm->resume().  It is executed
702 The prepare() callback is executed during system suspend, during hibernation
707 This callback is only necessary if the driver's device has children that in
709 callback is to prevent new children of the device from being registered until
712 In addition to that the prepare() callback may carry out some operations
720 The suspend() callback is only executed during system suspend, after prepare()
723 This callback is expected to quiesce the device and prepare it to be put into a
725 not recommended) that a PCI driver's suspend() callback save the standard
739 While the suspend() callback is being executed, the driver's interrupt handler
742 carried out in this callback.
746 The suspend_noirq() callback is only executed during system suspend, after
757 The freeze() callback is hibernation-specific and is executed in two situations,
763 The role of this callback is analogous to the role of the suspend() callback
768 In that cases the freeze() callback should not prepare the device system wakeup
774 The freeze_noirq() callback is hibernation-specific.  It is executed during
781 The role of this callback is analogous to the role of the suspend_noirq()
782 callback described above and it very rarely is necessary to define
790 The poweroff() callback is hibernation-specific.  It is executed when the system
795 The role of this callback is analogous to the role of the suspend() and freeze()
799 the poweroff() callback should use pci_prepare_to_sleep() and
806 The poweroff_noirq() callback is hibernation-specific.  It is executed after
809 The role of this callback is analogous to the role of the suspend_noirq() and
818 The resume_noirq() callback is only executed during system resume, after the
820 be invoked while resume_noirq() is running, so this callback can carry out
831 The resume() callback is only executed during system resume, after
835 This callback is responsible for restoring the pre-suspend configuration of the
841 The thaw_noirq() callback is hibernation-specific.  It is executed after a
848 The role of this callback is analogous to the role of resume_noirq().  The
855 The thaw() callback is hibernation-specific.  It is executed after thaw_noirq()
859 This callback is responsible for restoring the pre-freeze configuration of
864 The restore_noirq() callback is hibernation-specific.  It is executed in the
869 This callback is analogous to resume_noirq() with the exception that it cannot
879 The restore() callback is hibernation-specific.  It is executed after
883 This callback is analogous to resume(), just like restore_noirq() is analogous
892 The complete() callback is executed in the following situations:
903 This callback is entirely optional, although it may be necessary if the
904 prepare() callback performs operations that need to be reversed.
908 The runtime_suspend() callback is specific to device runtime power management
913 This callback is responsible for freezing the device and preparing it to be
919 The runtime_resume() callback is specific to device runtime PM.  It is executed
924 This callback is responsible for restoring the normal functionality of the
931 The runtime_idle() callback is specific to device runtime PM.  It is executed
937 This callback is optional, but if it is not implemented or if it returns 0, the
939 cause the driver's runtime_suspend() callback to be executed.
977 the runtime_idle() callback to prevent the device from being suspended again
978 every time right after the runtime_resume() callback has returned
979 (alternatively, the runtime_suspend() callback will have to check if the
987 probe callback provided by the device's driver.
991 to decrement the device's runtime PM usage counter in its probe callback
1000 It is important to remember that the driver's runtime_suspend() callback
1012 When the driver's remove callback runs, it has to balance the decrementation
1014 if it has decremented the counter in its probe callback, it must run
1015 pm_runtime_get_noresume() in its remove callback.  [Since the core carries
1017 before running the driver's remove callback, the runtime PM of the device