On Friday 17 September 2004 12:57 pm, Alan Stern wrote: > 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.
Neh ... just trying to understand how behavior of disconnect() could matter. SInce it's not called except as part of HCD removal, those other things you were worried about aren't going to be happening. Unless you were going hypothetical and assuming someone started calling remove()! > 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. Sounds like you're thinking about generalizing this differently: as "hub died" plus special "is it root" case. I like that notion better without the special case ... :) > > 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? Trying to use swsusp: "echo 4 > /proc/acpi/sleep". Also, it can get rather confused if you suspend a USB controller's PCI device before calling swsusp. Then there's also the resume-then-resuspend step before poweroff... > > > 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 - Right, and so the question is what to do about it. Today this rare code path just tries to stop the HCD. Then it'd be up to the sysadmin what to do -- maybe type "rmmod HCD; modprobe HCD" on a non-USB keyboard, or maybe press the reset button. In the future usbcore might be able to just restart the controller, either by re-using the existing memory or: > - 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... There are dozens of "how to restart" policies. That one's much like the sysadmin would achieve by rmmod/modprobe. but automated, and applying only to the controller that died. I was thinking of a lighter weight reset option, with fewer opportunities for new faults. Maybe this just reflects me running into too many "rmmod hangs" or "modprobe hangs" failure modes. Differently 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. The USB stack would still be knowing, OK, minor difference ... It'd have to remember the device's bus, and call bus_rescan_devices(). Either way, the bus rescan might not give the device back to usbcore/khubd. > > 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. It's one of many policy choices. I just like the idea of turning this "rare" case into one that's more common (resume after poweroff), so the handling there sees reasonable amounts of testing ... and keeping it light weight to avoid adding new error cases. I don't much like "couldn't re-allocate memory", for example! > 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. The root hub should just wake up; how else can it handle the IRQ? If it were in a PM mode where the state couldn't change, it wouldn't have enabled wakeup before it went to sleep. - 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
