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.
The only one that needs to right now, maybe. I really don't see anything wrong with supporting more graceful disconnect() handling models, where any driver can chat with the device if it's still present. Except possibly that some driver writers would start to depend on always being able to do that, which they can't.
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.
Erm, no resetting a hub to altsetting 1 just turns off the TT-per-port mode; you really need to use configuration 0 to disable downstream ports.
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.
Why wouldn't it be practical -- locking? That "check for unbound interfaces" bit might be appropriately simple, though.
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.
The only reason for a new method would then be preserving the root hub. Why would that be important? (Other than avoiding that self-deadlock in the PM code, which is just a bug.)
Maybe this could share code with the "host controller died" handler, which also has yet to be written.
What's there now is kind of iffy, actually. Luckily it's hardly used.
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! :-)
OK. I was just trying to be accomodating ... and I've not yet digested all of those much-anticipated patches, anyway! :)
- Dave
-------------------------------------------------------
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
