On Saturday 25 September 2004 8:59 pm, Alan Stern wrote: > > 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.
That'd be a bug. STR isn't supposed to discard state like that; it's supposed to leave devices (low-)powered but able to resume quickly (give or take a few breaths), not turn them off wholesale. Otherwise it'd need to be called suspend-to-disk. :) > 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. That was the idea ... ;) > > I think the answer for (2) needles 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. There can be whole trees of devices sitting in USB suspend state, which will be enabled just fine by correctly resuming the tree. Heck, one of them may have just woken the system up ... :) > 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. Better yet, when the system uses resume() on those devices then no re-enumeration/probing is needed. But I still think the default handling of suspend should be disconnect() for drivers that don't provide even minimal suspend/resume handlers. So that in those cases, resuming should involve re-enumeration. - 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
