> 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? 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.
> Your second example, usb_set_interface() would remain practically
> unchanged. It doesn't require unbinding anything, so it doesn't have to
> do anything fancy. The only alteration is that I would like to separate
> out the actual message-sending -- usb_set_interface_physical() -- so that
> it could be shared by usb_reset_device() in the device-didn't-morph path.
>
> Actually, that suggests an unanswered question. What should we do if the
> device didn't morph, and we can restore the prior configuration, but for
> some reason we can't restore an interface's prior altsetting?
Unbind and reprobe.
Regards
Oliver
-------------------------------------------------------
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
