On Sat, 4 Dec 2004, Pavel Machek wrote: > We probably could add char * to the suspend_message_t.. But I think > few well-defined states could be enough. How many selective states > make sense for the user? I don't know. For testing purposes it would be nice to be able to specify D1, D2, D3hot, or D3cold when suspending a PCI device, for example. > > It's possible that different drivers and different subsystems will have > > their own individual answers to this question. Should there be a specific > > return code for ->suspend() to indicate that a device's children must be > > suspended first? > > Perhaps code just should call upper layer and ask its children to be > suspended? I'm concerned about stack overflow. This should be done in a way that only requires a bounded amount of stack space. > What devices want their children suspended? All USB hubs, for one. But I imagine lots of devices would be unable to suspend safely if they had a non-suspended child. Wasn't that part of the reason for inventing the driver model in the first place -- to make sure that power-change events occur in the right order? When faced with a device like this, the sysfs code has a choice of suspending the children first or passing an error back to the user. The most flexible approach would be for the sysfs interface to somehow give the user three options: Always suspend all the children, down to the leaf nodes; Suspend the immediate children if the device requires it (recursively, of course); Return an error if some child needs to be suspended first. I don't have any good ideas for a way to provide these options to the user. > Hmm, I do not think selective suspend of storage wants low-level > hardware running. If you selective-suspend usb-storage, you want to > power down heads/motors/etc. It is just software stack that remains > ready... You're right, but this just shifts the problem down a level. So a suspend of a usb-storage device would cause the lower-level SCSI host and SCSI disk to suspend as well, but would still leave the gendisk device running so that new requests could still be received and cause an autoresume. Alan Stern
