On Fri, 17 Sep 2004, David Brownell wrote: > > > 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?
No, I'm not saying that. I'm saying that "There's no parent hub, so what would it disconnect from?" incorrectly implies that usb_disconnect() does nothing more than remove the pointer from the parent device to the child. It just occurred to me that perhaps you were really asking about mechanisms. How do we tell khubd that it should shutdown or reset a root hub? One possible way is to use a special sentinel value in hub->nerrors. Normally one doesn't expect there to be any errors in the status URB for a root hub. So if khubd sees that nerrors is 9999 (for example) and that the hub is a root hub, it would know to do a poweroff-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.) Under what conditions do you see these strange behaviors? Do have any hints about what source files to look at to find the problem? > > 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. Okay. I wasn't aware that PM management was still in such bad shape. > > 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? My feeling (and I acknowledge that this may not be fully grounded in fact) is that when the HC dies or needs to be reset, it's because something we don't know about has gone badly wrong -- and therefore we should begin with a clean slate: release all the hooks, destroy all the data structures, deallocate all the memory, etc. To do otherwise might risk leaving in place whatever mechanism caused the original problem. Maybe this is just overly cautious... > > 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? Obviously I haven't given this a tremendous amount of thought. But suppose, for example, that when khubd wants to reset or resuscitate an HC that it calls the HCD's pci_driver.remove() routine, then the pci_driver.probe() routine. (And does something equivalent for non-PCI controllers.) The HC driver really _wouldn't_ know that the device exists during the intermediate interval. > 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. If people believe that my reasoning above isn't valid, and it's not necessary to perform such a thorough reset, then fine -- doing the equivalent of poweroff-suspend and resume would be almost as good. Alan Stern P.S.: While we're on the subject of root hubs... What is an HCD supposed to do when the root hub is suspended and a remote wakeup IRQ arrives? Maybe this calls for another sentinel value in hub->nerrors. ------------------------------------------------------- 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
