On Sun, 27 Jun 2004, David Brownell wrote: > Hmm, maybe usbcore (== hub driver, wearing usbcore hat!) should > just set_configuration(hub,0) before disconnect() in at least > this special case.
That might raise other problems... > Thing is, the "don't talk to devices" applies _after_ disconnect() > returns, but it's only needed _during_ that call in the "device > link is gone" case ... which usbdev->state tests now catch. The > code doesn't do exactly that right now, though, partly to force > errors in some drivers that don't handle disconnect() right. In my opinion, the best approach is to agree that the hub driver's disconnect() method is allowed to use ep0 (provided of course that the hub is still plugged in). We could even go so far as to allow all drivers to do that, but the hub driver is the only one which really _needs_ to. Or maybe not. If usb_driver_release_interface() would always select altsetting 0 after unbinding the interface (something it ought to be doing right now!) then there's no problem, right? Whenever the hub driver is unbound from a hub, the hub would get either a Set-Configuration or Set-Interface command. Either of those should suffice to disable all its ports. The disadvantage is that there's no error recovery if something goes wrong. > > Then we're stuck with the problem of unbound interfaces that haven't been > > placed back in altsetting 0 because their device was suspended at the time > > of the unbinding. Should we try to select altsetting 0 for these > > interfaces when the device resumes? Or the next time the interface is > > probed? > > Hmm, I see. Tradeoff time. I'd say take whichever causes > least impact to device drivers ... didn't you originally > suggest taking the device out of suspend before unbind? :) I don't remember suggesting that. It isn't practical if there are any suspended hubs between the root and the device. My preference goes to installing altsetting 0 as soon as possible, which means when the device resumes. There could just be a little loop in one of the resume() routines that looks for unbound interfaces not in altsetting 0. > > My question is, exactly what does that functionality comprise? Doing the > > equivalent of stop, reset, start? > > I think that's it. More of a "restart" than a "reset", actually. But the HCDs already have "reset" and "start" methods, and they don't have a "restart" method. One would have to be added to each HCD. The major new feature would be that the root hub has to survive the "restart" process; you couldn't delete it and then create a new one. Maybe this could share code with the "host controller died" handler, which also has yet to be written. > >> Now that more people are > >>starting to understand the requirements, it's probably time to start > >>looking at merging that "hcd" glue into the top level. Maybe call > >>it "usb_host", maybe still call it "usb_bus". > > > > > > I've been waiting for this to happen; I find this extra "glue" layer to > > be very confusing. The sooner the better, as far as I'm concerned. > > Seems like 2.7 stuff to me, though if you were keen on starting > to submit a series of patches, I bet it could start sooner ... :) Have a heart -- I just finished a large series of patches! :-) Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
