On Fri, 3 Dec 2004, David Brownell wrote: > On Monday 29 November 2004 9:16 am, Pavel Machek wrote: > > > > 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. This does bring to mind two other questions, however. One is simple enough, just a reminder that we need to have (somewhere -- maybe not in the PM core) a resume routine that will do a selective resume on all devices along the path to a given device. The need for this becomes apparent when you consider using my hub-autosuspend and usb-storage-autosuspend patches in concert. 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? Alan Stern
