It's true that we cannot _reliably_ block new submissions. But we can block them, by using the new refuse_request mechanism. (It's not reliable
Whereas today we make do by forcing the maxpacketsize to zero. While it's inelegant, I don't think I've heard of any problems coming from that approach.
because the driver can unblock them and because we wouldn't block endpoint 0 in the absence of a physical unplugging.) Given the proper circumstances, it would be possible for a driver with insufficient internal synchronization to successfully submit an URB after disconnect() returned.
Yes. Unreliable blocking is no blocking at all. We might catch a few buggy drivers but they are still buggy.
All drivers that unblock endpoints would be by definition buggy. That API should be purely internal to usbcore anyway; that's what it is today (effectively), since drivers aren't allowed to change the endpoint maxpacket sizes.
Likewise drivers that do much more with an interface (and endpoints) after return from disconnect() than dropping a refcount ... they're buggy too.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
