On Sun, 9 Jan 2005, Nigel Cunningham wrote: > Hi guys. > > I've just joined the list in the hope that I might be able to provide > some help in getting USB suspend/resume more reliable, or at least get > better understanding regarding what the issues are.
Thanks for helping. > > You can't. You only know after initialisation whether there is an image > > to read back. > > With Suspend2, I could provide a means by which you can check if we're > going to resume. As you rightly say, Suspend would need to initialise > before it could give an answer, but it should be possible. With the > built in swsusp, it's not so simple, but again, it should be possible. It might improve things. In general it's safest to reset the controller before using it, but we don't want to reset when resuming if we don't have to, because resetting will break existing connections. Now that I think of it, even if we don't reset there's still a potential problem involving the hub driver in the boot kernel. If it gets far enough along to see that there are already some devices connected, it will reset those devices -- again, something we need to avoid if a resume is coming up. The safest thing would be for the boot kernel to disable all USB support. That won't work so well if the memory image is stored on a USB drive, though. In fact, I can't think of any way to handle that case. To access the image the boot kernel will be _forced_ to reinitialize the drive, and doing so will destroy the device state (USB device address, for instance) preserved during the suspend. > > > If the HCD was build as a module then it may not be loaded at all while > > > the startup kernel is running. I forget the details of how this works; > > > can the module be loaded from an initrd or equivalent before the image is > > > restored? > > > > IIRC you can't. > > You can with suspend2. I think swsusp may have had initrd support added > recently (there have certainly been patches). I don't think this matters much. Relying on the difference between static vs. modular build to decide what the resume strategy should be seems rather fragile. We should be able to do the right thing, regardless of whether the boot kernel loaded the driver. > Suspend can potentially preserve information from the boot kernel. We > should come up with a generic mechanism to do this, though - if it's > something that might be helpful in more than one case. Offhand I can't think of any use for such information. Maybe something will turn up, though... Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
