Hi Oliver, On Wed, Aug 14, 2013 at 2:19 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: Thanks for you response. > 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. > >> 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. How does then PERSIST_ENABLED option work then ? With this option enabled, on a system resume, the USB device attached to the root-hub are not re-enumerated, right ? Possibly i am getting confused here. How would a usb_suspend_interface() and usb_suspend_device() differ. > >> 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. > >> 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? Is it that, from the interface only the device information is extracted ? Can't we catch hold of usb_device pointers of hub and child devices ? > > HTH > Oliver > > -- Best Regards Vivek -- 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
