It might be a good idea to add a generic PM state for devices that are in a low-performance mode but will automatically transfer (or be transferred) back to full-performance when the next request arrives. This came up in working on auto-suspend for the usb-storage driver. When a drive is auto-suspended we definitely do _not_ want to put all the descendant devices into a low-power state first. That would defeat the purpose -- if the disk device was suspended then its queues would be blocked and auto-resume would never get invoked. But on the face of it, this also violates the principle that a device should never be in a low-power state when its children are still active. Adding a new state could resolve this paradox. There's a related point involving auto-resume of USB hubs. Suppose a device auto-suspends, then its parent hub auto-suspends as well. When it comes time to auto-resume the device then the hub must resume also. One might think this could be accomplished by adding an auto-resume path to the hub_port_resume routine in the hub driver, but that approach won't work owing to locking restrictions. Instead usb_resume_device needs to resume all the devices along the path from the root hub down to the device as these devices are locked, i.e., during locktree. Although this point may appear USB-centric, in fact the concepts involved apply generally (although the locking principles used in the USB subsystem haven't been adopted by the rest of the kernel). Whenever interior device nodes are capable of auto-suspend and auto-resume, there needs to be a resume routine that will wake up everything along the path from the root to the requested device. Alan Stern
