On Wed, 14 Aug 2013, Oliver Neukum wrote: > On Wed, 2013-08-14 at 14:46 +0530, Vivek Gautam wrote: > > Hi, > > > >> 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, The Persist mechanism is explained in Documentation/usb/persist.txt. > > on a system resume, the USB device attached to the root-hub are not > > re-enumerated, right ? Again, it depends on what you mean by "re-enumerated". > Exactly that way. You recreate the state of the device. > > > Possibly i am getting confused here. > > Well. There are two ways to make a device go to the same state > > a) you have primitives to save and restore that state > b) you recognize that the state is the result of a sequence > of operations. You repeat that sequence. > > That is the basic idea from a high level of abstraction. > > > How would a usb_suspend_interface() and usb_suspend_device() differ. > > Have a look at drivers/usb/core/generic.c Those two routines are part of drivers.c, not generic.c. Broadly speaking, usb_suspend_interface() notifies the interface drivers about the upcoming suspend, whereas usb_suspend_device() carries out the actual suspend operation. > > 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 ? > > We can. And that is how persist works. But it may fail. > Possibly I am misunderstanding you. The questions aren't very clear. 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
