Device Power ManagementDevice power management encompasses two areas - the ability to savestate and transition a device to a low-power state when the system isentering a low-power state; and the ability to transition a device toa low-power state while the system is running (and independently ofany other power management activity). MethodsThe methods to suspend and resume devices reside in struct bus_type: struct bus_type {       ...       int             (*suspend)(struct device * dev, u32 state);       int             (*resume)(struct device * dev);};Each bus driver is responsible implementing these methods, translatingthe call into a bus-specific request and forwarding the call to thebus-specific drivers. For example, PCI drivers implement suspend() andresume() methods in struct pci_driver. The PCI core is simplyresponsible for translating the pointers to PCI-specific ones andcalling the low-level driver.This is done to a) ease transition to the new power management methodsand leverage the existing PM code in various bus drivers; b) allowbuses to implement generic and default PM routines for devices, and c)make the flow of execution obvious to the reader. System Power ManagementWhen the system enters a low-power state, the device tree is walked ina depth-first fashion to transition each device into a low-powerstate. The ordering of the device tree is guaranteed by the order inwhich devices get registered - children are never registered beforetheir ancestors, and devices are placed at the back of the list whenregistered. By walking the list in reverse order, we are guaranteed tosuspend devices in the proper order. Devices are suspended once with interrupts enabled. Drivers areexpected to stop I/O transactions, save device state, and place thedevice into a low-power state. Drivers may sleep, allocate memory,etc. at will. Some devices are broken and will inevitably have problems poweringdown or disabling themselves with interrupts enabled. For thesespecial cases, they may return -EAGAIN. This will put the device on alist to be taken care of later. When interrupts are disabled, beforewe enter the low-power state, their drivers are called again to puttheir device to sleep. On resume, the devices that returned -EAGAIN will be called to powerthemselves back on with interrupts disabled. Once interrupts have beenre-enabled, the rest of the drivers will be called to resume theirdevices. On resume, a driver is responsible for powering back on eachdevice, restoring state, and re-enabling I/O transactions for thatdevice. System devices follow a slightly different API, which can be found in	include/linux/sysdev.h	drivers/base/sys.cSystem devices will only be suspended with interrupts disabled, andafter all other devices have been suspended. On resume, they will beresumed before any other devices, and also with interrupts disabled.Runtime Power ManagementMany devices are able to dynamically power down while the system isstill running. This feature is useful for devices that are not beingused, and can offer significant power savings on a running system. In each device's directory, there is a 'power' directory, whichcontains at least a 'state' file. Reading from this file displays whatpower state the device is currently in. Writing to this file initiatesa transition to the specified power state, which must be a decimal inthe range 1-3, inclusive; or 0 for 'On'.The PM core will call the ->suspend() method in the bus_type objectthat the device belongs to if the specified state is not 0, or->resume() if it is. Nothing will happen if the specified state is the same state thedevice is currently in. If the device is already in a low-power state, and the specified stateis another, but different, low-power state, the ->resume() method willfirst be called to power the device back on, then ->suspend() will becalled again with the new state. The driver is responsible for saving the working state of the deviceand putting it into the low-power state specified. If this wassuccessful, it returns 0, and the device's power_state field isupdated. The driver must take care to know whether or not it is able toproperly resume the device, including all step of reinitializationnecessary. (This is the hardest part, and the one most protected byNDA'd documents). The driver must also take care not to suspend a device that iscurrently in use. It is their responsibility to provide their ownexclusion mechanisms.The runtime power transition happens with interrupts enabled. If adevice cannot support being powered down with interrupts, it mayreturn -EAGAIN (as it would during a system power managementtransition),  but it will _not_ be called again, and the transactionwill fail.There is currently no way to know what states a device or driversupports a priori. This will change in the future. Driver Detach Power ManagementThe kernel now supports the ability to place a device in a low-powerstate when it is detached from its driver, which happens when itsmodule is removed. Each device contains a 'detach_state' file in its sysfs directorywhich can be used to control this state. Reading from this filedisplays what the current detach state is set to. This is 0 (On) bydefault. A user may write a positive integer value to this file in therange of 1-4 inclusive. A value of 1-3 will indicate the device should be placed in thatlow-power state, which will cause ->suspend() to be called for thatdevice. A value of 4 indicates that the device should be shutdown, so->shutdown() will be called for that device. The driver is responsible for reinitializing the device when themodule is re-inserted during it's ->probe() (or equivalent) method. The driver core will not call any extra functions when binding thedevice to the driver.