Alan Stern wrote:
I'm not sure I see the issue. The hub disconnect() routine should shut down all (hub-managed) children before it returns, and disconnect all those devices from the usb device trees.
Yes it should. On the other hand, disconnect() routines aren't supposed to talk to their devices. Usbcore goes so far as to disable all endpoints in an interface (other than ep0) before calling disconnect().
Hmm, maybe usbcore (== hub driver, wearing usbcore hat!) should just set_configuration(hub,0) before disconnect() in at least this special case.
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.
But disconnect/poweroff is a different case; we already know that driver disconnect() must work with dead devices, so unbind() ought to work for suspended devices.
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? :)
(A related matter is the question of what it should mean to reset a root hub. It's not entirely clear what an HCD would need to do or whether the existing HCDs support the necessary functionality.)
I think the functionality is all there, with the reset/start/stop calls, but not at the generic "usb_bus" level.
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.
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 ... :)
- 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
