Hi! > > > USB should really pass down suspend_message_t parameter it got from > > > higher levels. > > > > It does, but PM_SUSPEND_DISK is kind of not-very-useful. > > > > For systems that don't provide VBUS current during the > > upcoming system sleep state, it'd be more appropriate > > to just disconnect() the drivers. > > > > Some systems don't even provide VBUS current during > > PM_SUSPEND_MEM. > > > > So the information that's relevant to the USB device > > drivers seems rather unrelated to anything provided > > through the "echo foo > /sys/power/state" request. > > The suspend_message_t parameter is not related to the "foo" in your > example. For a userspace-initiated power-level change like this, the > parameter would be something more like PM_SELECTIVE_SUSPEND. The "foo" > would be passed in some other form, maybe as a "flags" argument. 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? > The other matter is less clear. Should selective suspends be recursive -- > that is, should they affect everything below the specified device? The > usb-storage patch provides an example where we don't want that to happen; > the device is suspended but the SCSI layers beneath it remain active so > that the device can autoresume when a request arrives. > > 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? What devices want their children suspended? 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... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
