On Sat, 25 Sep 2004, David Brownell wrote: > 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.
We may have no option. Unless I'm mistaken, suspend-to-RAM puts most PCI devices into D3cold. What happens if the root fs is on a USB disk? On the other hand, if I am wrong and it only uses D3hot, then there's no problem doing what you say. > > > 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. There's no real difference between what root hubs do here and what external hubs do. Before the resume-from-idle, khubd hasn't been running (or hasn't been running for long, anyway) -- so there probably aren't any USB devices enabled except the root hubs. As each device is discovered and initialized, it needs to be reattached to the driver which owned it before. That's essentially what usb_reset_device() does now. Alan Stern ------------------------------------------------------- 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
