On Tue, 21 Mar 2006, Franck Bui-Huu wrote: > 2006/3/20, Alan Stern <[EMAIL PROTECTED]>: > > > > You mean, why doesn't file_storage.c always delegate the job to the UDC > > driver when it unregisters? It does. You can see this by looking through > > the fsg_unbind() routine. It doesn't call usb_ep_disable() anywhere. > > well I think it does indirectly, consider the following sequence that > occurs when unloading g_file_storage module: > > usb_gadget_unregister_driver > unbind (fsg->state = FSG_STATE_IDLE) > +-> raise_exception(fsg, FSG_STATE_EXIT); > > [IO thread] > handle_exception > do_set_config > do_set_interface > +-> usb_ep_disable .... > > Here the last call to usb_ep_disable is useless since all endpoints > has been previously disabled by usb_gadget_unregister_driver.
You're correct; this pathway exists and it gets called during unregistration, where the usb_ep_disable is useless. However do_set_interface needs to call usb_ep_disable when it runs at other times, such as when a Set-Interface or Set-Configuration request is received. _Adding_ code to prevent it from calling usb_ep_disable during unregistration would make the driver longer without improving performance at all. It's better just to leave the useless call as it is. > > There are other times when the UDC driver might not disable endpoints, > > however. For example, when the cable is unplugged (a disconnect event). > > The gadget API doesn't specify whether endpoints are automatically > > disabled by the UDC driver when a disconnect occurs, so file_storage.c > > disables them by hand. The same thing happens when a Set-Configuration or > > Set-Interface request is received. > > IMHO, sometimes it's pretty hard to know how things should be done > that is what should be part of the gadget driver or part of the UDC > driver. For a gadget driver author it's not hard at all. You simply assume that the UDC driver does no more than what the Gadget API says it has to. That's the only assumption you can make, because some UDC drivers do indeed implement nothing more than this minimal functionality. For a UDC driver author there's more freedom. You can implement a minimal driver or add some extra features. However, there's no point in adding a feature that would (for example) disable all endpoints when a Set-Configuration request is received. Since every gadget driver has to disable them anyway, it would be a waste of time for the UDC driver to do it. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
