On Tuesday 02 January 2007 11:04 am, Phil Endecott wrote: > Dear All, > > I may have found a problem with 'deferred configuration' mode in > gadgetfs. Or, more likely, I have misunderstood something or found an > error that you already know about... > > Normally, activate_ep_files() creates inodes for the per-endpoint files > with f_op set to ep_config_operations. The endpoint descriptors are > then written to these files and are processed by ep_config(). This > will call usb_ep_enable() and if all is OK it will change f_op to > ep_io_operations, so endpoint reads and writes call ep_read() and > ep_write respectively, transfering real data. > > However, endpoint descriptors can be written before the device is > connected, in which case the speed of the connection is not known; to > cope with this the code in ep_config() can postpone actual > configuration.
This is a consequence of wanting a _really_ simple model for userspace drivers to use, as well as the more capable one: - Simple: configure everything in one config, go. - More capable: wait till SET_CONFIGURATION and/or SET_INTERFACE to figure out what the host wants, configure appropriately, go. The latter is what "usb.c" uses, and the other mode probably doesn't get much testing lately ... maybe it should be removed. > It does this by setting the endpoint state to > STATE_EP_DEFER_ENABLE. Subsequently, endpoints in this state are > checked for in gadgetfs_setup(), which is called in response to a > CONNECT message, and usb_ep_enable() is called from there. However, in > this case, f_op is not changed over to ep_io_operations, and endpoint > reads and writes do not go to ep_read() and ep_write(). Whoops! > I can see two possibilities for how this should work: > > 1. f_op could be changed over in ep_config() even in the deferred > case. This would happen if value equalled 0 in the deferred case; > currently as far as I can see it equals len. I am experimenting with > this change, and my test program seems to get a bit further than it > used to. That makes sense; test "value >= 0" not "value == 0". I think not doing that in the first place was probably just a bug. > 2. f_op could be changed over in gadgetfs_setup(), immediately after > the call to usb_ep_enable() there. 3. remove that defer_enable mode. > I am unsure about what should happen to the endpoint configurations > during DISCONNECT/CONNECT, especially if the speed changes. I worry > about this particularly as I always see CONNECT/DISCONNECT/CONNECT when > my test program starts - is this normal??? The disconnect is probably associated with a usb reset during enumeration; normal. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
