David Brownell wrote:
> 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.
OK, I'll change over to configuring after connection like usb.c does.
I don't want to be the only person trying to use a buggy interface.
But first I'll describe the remaining issue that I found with the
configure-before-connection approach.
>> I am unsure about what should happen to the endpoint configurations
>> during DISCONNECT/CONNECT, especially if the speed changes.
What was intended to happen to a configuration loaded before
connection, after disconnection?
It seems to me that, in order to make it as simple as possible for the
user program, the configuration should be retained over
disconnect/reconnect. That doesn't happen because in net2280.c
ep_reset() sets ep->desc to NULL, and nothing in gadgetfs re-enables it
on the next connect. Also, f_op is not changed back to
ep_config_operations, so the user program cannot re-write the
descriptors (unless it closes and re-opens maybe?). A subtlety is that
the new connection may be at a different speed than the last one.
I made this work by hacking the following into gadgetfs_disconnect():
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
data = ep->driver_data;
if (data->state == STATE_EP_ENABLED) {
data->state = STATE_EP_DEFER_ENABLE;
}
}
i.e. it returns all enabled endpoints to the DEFER state, so on the
next connect the existing code in gadgetfs_setup() will call
ep_enable() with the appropriate descriptor for the new speed. This
seems to work for my test program which now gets beyond the initial
CONNECT/DISCONNECT/CONNECT that I always see, though it's quite
possible that this broke testusb #10 as described yesterday.
As I said above, I'm now going to try the configure-on-connection
approach so I don't really need to fix this. I'd be quite happy for
this deferred configuration mode to be removed. I initially used this
method after reading this "don't do it this way" comment in usb.c:
/* Kernel is normally waiting for us to finish reconfiguring
* the device.
*
* Some hardware can't, notably older PXA2xx hardware. (With
* racey and restrictive config change automagic.) To handle
* such hardware, don't write code this way ...
instead, keep
* the endpoints always active and don't rely on seeing any
* config change events, either this or SET_INTERFACE.
*/
Hmmm, does that need updating?
Cheers,
Phil.
-------------------------------------------------------------------------
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
