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. > > Or should the HCD's stop() routine be called, which > > will deallocate everything associated with the root hub? (That would make > > it easy to restart the HC later; just call the start() routine.) > > I thought about that at one point. But resume-from-poweroff > cases also need to restart the HC ... stop()/start() isn't really > necessary. (Though maybe only OHCI does that just now, > and even that's only after serious struggles with pmcore > code in 2.6, which doesn't like hot-unpluggable devices.) > > Also, automagic restarting wouldn't always be appropriate. > It shouldn't continue forever, for one thing... :) > > > > > 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. 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). Restarting a dead controller or doing usb_reset_device() on a root hub ought to work differently. 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. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
