On Sat, 9 Aug 2003, Oliver Neukum wrote: > > I'm not sure about your first example. Configuration changes would take > > place immediately under my scheme, but unbinding the old interface drivers > > and probing the new interfaces would be deferred. Is anything wrong with > > That is deadly. Drivers would work on the wrong interfaces. You cannot > block ep 0, so blocking endpoints immediately won't help you. You > need to unbind before you send the crucial control message.
That makes sense. What about if the set-config message fails? Go ahead and rebind anyway, using the old configuration? > > that? When the config change is initiated through usbfs the deferral is > > unnecessary, but when it's initiated by a driver the deferral is > > essential. It's not clear to me how to distinguish the two cases within > > usb_set_configuration(), or if we even need to. > > It is needed. In the second case you should defer for one interface only. So we need some way to determine which driver is making the request. How should we do that? Change the API? Or better yet, implement some callback notification scheme alerting drivers to config changes/device resets? If you trust the drivers to respect the notification then deferring the unbind isn't a problem. But that sounds like too big a change to make for now. Changing the API is less work, since usb_set_configuration() and usb_reset_device() are only used in a few places. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
