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.
>
> 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.
Thanks
--
Franck
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
