On Wed, 14 Aug 2013, Oliver Neukum wrote: > On Wed, 2013-08-14 at 13:24 +0530, Vivek Gautam wrote: > > Hi all, > > > > > > Going through the power suspend/resume sequence of USB, got hit by a doubt. > > > > I am not able to figure out how the USB core driver takes care of > > It doesn't. All it does is enable the remote wakeup feature, if needed, and carry out the low-level port operations for suspend and resume. It also invokes the interface drivers' suspend and resume callbacks. > > devices and root-hubs across suspend/resume. Are the device contexts > > saved somewhere and then restored back on resume ? > > Usually not. The state of interfaces are the responsibility of interface > drivers (colloquially called device drivers). Most devices just don't > offer an API for saving state. The drivers recreate as opposed to > restore the state. Most of the time, the drivers don't do either. USB devices are required to preserve their state across a suspend; this is part of the USB spec. > > How does the suspend/resume sequence taken care by "drivers/usb/core/.." ? > > The generic driver core guarantees that suspend()/resume() are called > in the right sequence. > > > One more question here: > > If a hub on USB bus is getting re-enumerated, is it really necessary > > that its child devices shall also be re-enumerated ? Is there someway > > Yes. It depends on what you mean by "re-enumerated". It is indeed necessary to query the child devices for their descriptors. But it may not be necessary to assign addresses to the devices or use their descriptor values to create new data structures (if the descriptors haven't changed then we can keep using the old structures). > > out in which we can save the child-devices' context pointers and then > > once hub has been re-enumerated back, we restore back them. > > How do you know they are identical? What do you mean by "context pointer"? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
