On Thursday 04 January 2007 4:17 am, Phil Endecott wrote:
>
> >> 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?
Depends what you mean by "loaded". Descriptors should all be
saved. Endpoints however would need to be deactivated, then
later reactivated according to the relevant device speed.
(Note by the way that the "simple"/may-need-to-vanish model
doesn't support altsettings. Just one config, all endpoints
always active. That's a common model...)
> 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.
Not re-enabling would be a bug. In this case, of the "insufficient
testing and usage" variety.
Should you feel like coming up with a patch to remove that "simple"
config mode from gadgetfs, please do so.
> 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.
Yes.
> 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.
That looks about right. If you don't submit a patch to remove
that "simple" mode, please submit patches to either fix it, or
at least make userspace fail cleanly if it tries to use that mode.
> 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?
By "older" is meant "before PXA 255 or PXA 250 revC" ... basically, they
fixed this by adding a new register ("CFR"). This is the same revision
that fixed some serious memory controller bugs (half-speed memory!) and
it's been years since that old hardware has shipped from Intel, much less
from their customers.
I'll update that comment to be more explicitly about ancient hardware
that new developers are highly unlikely to ever trip over.
- 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
