+Resume From Hibernation
+-----------------------
+Resuming from hibernation is, again, more complicated than resuming from a sleep
+state in which the contents of main memory are preserved, because it requires
+a system image to be loaded into memory and the pre-hibernation memory contents
+to be restored before control can be passed back to the image kernel.
+
+In principle, the image might be loaded into memory and the pre-hibernation
+memory contents might be restored by the boot loader. For this purpose,
+however, the boot loader would need to know the image kernel's entry point and
+there's no protocol defined for passing that information to boot loaders. As
+a workaround, the boot loader loads a fresh instance of the kernel, called the
+boot kernel, into memory and passes control to it in a usual way. Then, the
+boot kernel reads the hibernation image, restores the pre-hibernation memory
+contents and passes control to the image kernel. Thus, in fact, two different
+kernels are involved in resuming from hibernation and in general they are not
+only different because they play different roles in this operation. Actually,
+the boot kernel may be completely different from the image kernel. Not only
+the configuration of it, but also the version of it may be different.
+The consequences of this are important to device drivers and their subsystems
+(bus types, device classes and device types) too.
+
+Namely, to be able to load the hibernation image into memory, the boot kernel
+needs to include at least the subset of device drivers allowing it to access the
+storage medium containing the image, although it generally doesn't need to
+include all of the drivers included into the image kernel. After the image has
+been loaded the devices handled by those drivers need to be prepared for passing
+control back to the image kernel. This is very similar to the preparation of
+devices for creating a hibernation image described above. In fact, it is done
+in the same way, with the help of the ->pm.prepare(), ->pm.freeze() and
+->pm.freeze_noirq() callbacks, but only for device drivers included in the boot
+kernel (whose versions may generally be different from the versions of the
+analogous drivers from the image kernel).
+
+Should the restoration of the pre-hibernation memory contents fail, the boot
+kernel would carry out the procedure of "thawing" devices described above, using
+the ->pm.thaw_noirq(), ->pm.thaw(), and ->pm.complete() callbacks provided by
+subsystems and device drivers. This, however, is a very rare condition. Most
+often the pre-hibernation memory contents are restored successfully and control
+is passed to the image kernel that is now responsible for bringing the system
+back to the working state.
+
+To achieve this goal, among other things, the image kernel restores the
+pre-hibernation functionality of devices. This operation is analogous to the
+resuming of devices after waking up from the memory sleep state, although it
+involves different device notifications which are the following:
+
+ 1 bus->pm.restore_noirq(dev), if implemented; may call the device driver's
+ ->pm.restore_noirq() method, depending on the bus type in question.
+
+ 2 bus->pm.restore(dev), if implemented; usually calls the device driver's
+ ->pm.restore() method.
+
+ 3 type->pm.restore(dev), if implemented; may call the device driver's
+ ->pm.restore() method if not called by the bus type or class.
+
+ 4 class->pm.restore(dev), if implemented; may call the device driver's
+ ->pm.restore() method if not called by the bus type or device type.
+
+ 5 bus->pm.complete(dev), if implemented; may call the device driver's
+ ->pm.complete() method.
+
+The roles of the ->pm.restore_noirq() and ->pm.restore() callbacks are analogous
+to the roles of the corresponding resume callbacks, but they must assume that
+the device may have been accessed before by the boot kernel. Consequently, the
+state of the device before they are called may be different from the state of it
+right prior to calling the resume callbacks. That difference usually doesn't
+matter, so the majority of device drivers can set their resume and restore
+callback pointers to the same routine. Nevertheless, different callback
+pointers are used in case there is a situation where it actually matters.