On Wednesday 15 September 2004 10:54 am, Alan Stern wrote: > On Wed, 15 Sep 2004, David Brownell wrote: > > > > But what should happen to the root hub? It shouldn't be disconnected, > > > because the HCD will try to deregister it later on. > > > > Root hub disconnect is all special cased anyway ... it > > could be done so that's not an issue. There's no parent > > hub, so what would it disconnect from? > > usb_disconnect() does more than erase the parent->child pointer, even for > root hubs. It also disables the device, terminating all URBs and > disabling the endpoints. And it removes the device from usbfs and sysfs.
Are you saying there's a path whereby something other than the HCD remove( ) is now disconnecting the root hub? Where? > > > > Right now I'm > > > > trying to find out what's up with resume after suspend-to-disk, > > > > which is actually somewhat related (the root hub does get > > > > reset), but other than pmcore problems I think the main issue > > > > is root hub timers not getting restarted right. > > > > > > This gets into that whole tricky area of power-off resets > > > we discussed in > > > the spring. Are usb_devices supposed to be preserved across > > > suspend-to-disk? > > > > Nope, since they all get powered off. If the pmcore code > > worked sanely, we'd already be disconnecting every USB > > device on those paths. > > It sounds like hc_died should end up doing almost the same thing as a > poweroff-suspend: disconnect all the children and leave the root hub > quiescent and suspended. There wouldn't even be any harm in having > hc_died turn off all I/O, DMA, and IRQ access to the HC and stop all its > hardware clocks, just like a suspend. Possibly. I'm more curious about why the pmcore code sometimes ends up resuming children when their parent is still alive; there's some major wierdness. (And yes, I've also seen suspend-after-parent, so whatever bug does that is appropriately symmetric.) > So why not have the process-context part of hc_died do exactly that: call > through whatever PM invocation is needed to set the power level of the HC > to the equivalent of D3cold? Then the hcd glue layer could be made > responsible for disconnecting all the children (hcd-pci.c doesn't do that > now). My point was that disconnecting children during resume (or suspend) doesn't work sanely at all right now, because of pmcore self-deadlocking. There are actually other troubles too. Once that works, then we could start looking at HC death/resurrection as simple variants of HC poweroff-suspend/resume. Or not; but at any rate, I'd avoid tossing more problems into the mix without first isolating -- and probably fixing -- some existing ones. > Restarting a dead controller or doing usb_reset_device() on a root hub > ought to work differently. Why "ought"? If it's already in a power-off state, and there's already code that resumes from there, why "ought" that not be used? > The easiest thing might be to unbind the HC > from its driver, then rebind it. The procedure doesn't have to be > efficient, because it won't happen very often. That'd be a strange kind of "unbind", where the driver was still bound to the device strongly enough to know it exists! What if some other driver -- say, one that keeps unclaimed devices in a low power state -- bound to it first? Suspend/resume don't happen often either, and they'd be a better model for this. Assuming the pmcore code didn't jig out with hot-unplug scenarios, that is. - Dave > 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
