| .. SPDX-License-Identifier: GPL-2.0 | 
 | .. include:: <isonum.txt> | 
 |  | 
 | ============================= | 
 | Suspend/Hibernation Notifiers | 
 | ============================= | 
 |  | 
 | :Copyright: |copy| 2016 Intel Corporation | 
 |  | 
 | :Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 
 |  | 
 |  | 
 | There are some operations that subsystems or drivers may want to carry out | 
 | before hibernation/suspend or after restore/resume, but they require the system | 
 | to be fully functional, so the drivers' and subsystems' ``->suspend()`` and | 
 | ``->resume()`` or even ``->prepare()`` and ``->complete()`` callbacks are not | 
 | suitable for this purpose. | 
 |  | 
 | For example, device drivers may want to upload firmware to their devices after | 
 | resume/restore, but they cannot do it by calling :c:func:`request_firmware()` | 
 | from their ``->resume()`` or ``->complete()`` callback routines (user land | 
 | processes are frozen at these points).  The solution may be to load the firmware | 
 | into memory before processes are frozen and upload it from there in the | 
 | ``->resume()`` routine.  A suspend/hibernation notifier may be used for that. | 
 |  | 
 | Subsystems or drivers having such needs can register suspend notifiers that | 
 | will be called upon the following events by the PM core: | 
 |  | 
 | ``PM_HIBERNATION_PREPARE`` | 
 | 	The system is going to hibernate, tasks will be frozen immediately. This | 
 | 	is different from ``PM_SUSPEND_PREPARE`` below,	because in this case | 
 | 	additional work is done between the notifiers and the invocation of PM | 
 | 	callbacks for the "freeze" transition. | 
 |  | 
 | ``PM_POST_HIBERNATION`` | 
 | 	The system memory state has been restored from a hibernation image or an | 
 | 	error occurred during hibernation.  Device restore callbacks have been | 
 | 	executed and tasks have been thawed. | 
 |  | 
 | ``PM_RESTORE_PREPARE`` | 
 | 	The system is going to restore a hibernation image.  If all goes well, | 
 | 	the restored image kernel will issue a ``PM_POST_HIBERNATION`` | 
 | 	notification. | 
 |  | 
 | ``PM_POST_RESTORE`` | 
 | 	An error occurred during restore from hibernation.  Device restore | 
 | 	callbacks have been executed and tasks have been thawed. | 
 |  | 
 | ``PM_SUSPEND_PREPARE`` | 
 | 	The system is preparing for suspend. | 
 |  | 
 | ``PM_POST_SUSPEND`` | 
 | 	The system has just resumed or an error occurred during suspend.  Device | 
 | 	resume callbacks have been executed and tasks have been thawed. | 
 |  | 
 | It is generally assumed that whatever the notifiers do for | 
 | ``PM_HIBERNATION_PREPARE``, should be undone for ``PM_POST_HIBERNATION``. | 
 | Analogously, operations carried out for ``PM_SUSPEND_PREPARE`` should be | 
 | reversed for ``PM_POST_SUSPEND``. | 
 |  | 
 | Moreover, if one of the notifiers fails for the ``PM_HIBERNATION_PREPARE`` or | 
 | ``PM_SUSPEND_PREPARE`` event, the notifiers that have already succeeded for that | 
 | event will be called for ``PM_POST_HIBERNATION`` or ``PM_POST_SUSPEND``, | 
 | respectively. | 
 |  | 
 | The hibernation and suspend notifiers are called with :c:data:`pm_mutex` held. | 
 | They are defined in the usual way, but their last argument is meaningless (it is | 
 | always NULL). | 
 |  | 
 | To register and/or unregister a suspend notifier use | 
 | :c:func:`register_pm_notifier()` and :c:func:`unregister_pm_notifier()`, | 
 | respectively (both defined in :file:`include/linux/suspend.h`).  If you don't | 
 | need to unregister the notifier, you can also use the :c:func:`pm_notifier()` | 
 | macro defined in :file:`include/linux/suspend.h`. |