On Fri, 25 Nov 2005, David Brownell wrote: > > > Also, what you wrote is a little mixed up. Normally usb_suspend_device > > > calls driver->suspend, not the other way around. > > > > No. usb_generic_suspend() does it. (the PM core callback in the bus_type > > structure). It calls usb_suspend_device() when there is no driver (or > > rather, the generic driver) or calls the driver's->suspend() when there > > is a driver. > > Remember that "usb_device" suspend is managed only by usbcore, > and drivers themselves connect to a "usb_interface" of which > several generally exist. > > Don't even _think_ of usb_suspend_device() as anything more than > an internal "helper" routine. Yes, called by the "generic" suspend > routine that understands the difference between the two types of > usb devie nodes: usb_device, usb_interface.
That's right. What I said before was wrong, sorry. > > - If a device has a driver, it should call usb_suspend_device() itself > > from it's suspend() routine or the hub port won't be suspended (and thus > > the device). Or did I miss another code path ? > > No, there's a missing "autosuspend" mechanism. That's what would > suspend USB devices after all of their interfaces are suspended > (possibly because they have no driver) ... as part of runtime PM, > rather than as part of system-wide sleep state transitions. More importantly, Ben missed a very major point: USB devices _don't have_ drivers (other than the "generic driver"). Interfaces do. > > - If a device wants to suspend itself > > That concept is nonsense. A driver may choose to suspend its device. > > And for USB, the drivers are bound to usb_interface objects, not to > usb_device objects. So drivers suspend usb_interface->dev ... and > usbcore is then responsible for suspending usb_device->dev, not the > driver for one of the device's interfaces. Yes. Except that usbcore doesn't do that yet, so the only way to accomplish it is to have your driver do it, for now. For testing purposes, there's nothing wrong with that. > > (that is suspend the hub port > > it's connected to, whatever it is, a hub or a root hub) at any time for > > local power management (for example, usb storage could do that if no > > request have been issued for a while, usb serial could do that when no > > port is openeed, etc etc ...), it should call usb_suspend_device(). > > No, never. Drivers work with their interfaces, and that's it. > > There are a couple exceptions, notably anything calling usb_reset_device() > (for DFU firmware updates or for usb-storage fault recovery), but we're > trying to steer drivers away from such exceptions. A similar exception is usb_reset_interface. Both of these represent layering violations, with a host of associated complications. For example, see the contortions needed in usb_lock_device_for_reset. In any case, even when you do want to suspend a USB device you should not call usb_suspend_device. You should use the whole PM stack, which means calling dpm_runtime_suspend. Don't try to short-circuit parts of it. > > > When the infrastructure is in place, it will automatically take care of > > > suspending the device once all the interfaces are suspended. For now, > > > however, that's your responsibility. > > I'd say it differently: For now don't try that at all. Because in addition > to an autosuspend mechanism being missing, so is autoresume. That's not quite true. usbcore is aware of remote wakeup signals and will automatically take care of resuming the device and all its interfaces. Remember, though, that everything you do will be experimental and subject to change once the runtime PM infrastructure is ready. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
