On Friday 24 September 2004, Alan Stern wrote: > > > I mean, how should the implementation work? There's actually two > > problems. (1) How should we preserve the existence of devices across a > > per-device power-off suspend (i.e., not system-wide)? (2) How should we > > reinitialize devices during the resume-from-idle that occurs after a > > memory image is restored?
(1) Don't. (2) Root hubs do the right thing, usbcore just reacts. > > For (1), I think the hub driver will have to remember devices > > attached to powered-off ports instead of just calling usb_disconnect() > > right away. When the port power is turned back on, we could allow say 5 > > seconds for the device to reconnect. When it reconnects we should check > > whether the descriptors have changed, just like we do for a device reset. > > If it doesn't reconnect after 5 seconds, then we call usb_disconnect(). I disagree. If it's powered off, just disconnect() to get rid of it. When the user reconnects that disk tomorrow, let usermode code notice that it's now morphed to reiser5, and sort out the details! And if it stayed suspended, it never went away -- no problem. If it didn't stay suspended, it's by definition a disconnect(). The caller -- perhaps sysadmin through sysfs -- had the option to choose a "suspend", and instead chose a "disconnect". It only makes sense to respect that choice. > > For (2), we should probably do a reset of the root hubs and let > > the mechanism in (1) take care of the remaining details. For this purpose > > a device attached to a hub that is reset can be treated the same as a > > powered-off device. Except that I don't think there's really a generic answer about whether the root hubs can maintain their ports in suspend state or not ... why shouldn't a desktop system be able to use USB wakeup to get out of some suspend-to-disk invocation? Many motherboards can easily supply that much power. Though to be sure, some others just turn off power to USB ... :) I think the answer for (2) needs to be that the root hub itself sees how it came back from resume. That's what OHCI does now (modulo a glitch I noticed, sigh). It's a funky state not part of the OHCI spec. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
