[Moved thread to linux-usb-devel as it seems more appropriate. For
newcomers to this thread: Pete has identified (at least) one device that
doesn't reset its bulk pipe data toggles when it receives a SET_INTERFACE
request, although it accepts the request okay. This causes a problem
because usbcore assumes that the toggles get cleared, so the device is
out-of-synch with the system.]
On Mon, 24 Jan 2005, Pete Zaitcev wrote:
> On Wed, 12 Jan 2005 11:34:51 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > usb_gettoggle(us->pusb_dev, usb_pipeendpoint(us->recv_bulk_pipe), 0)
> > usb_gettoggle(us->pusb_dev, usb_pipeendpoint(us->send_bulk_pipe), 1)
>
> > Assuming the theory turns out to be true, it indicates a problem not in
> > usb-storage but in usbcore. We might need to reset all bulk and interrupt
> > pipes in an interface whenever a SET_INTERFACE is issued.
>
> OK. I have done it, but with ub instead, with the following patch:
>
> --- linux-2.6.11-rc2/drivers/block/ub.c 2005-01-22 14:54:09.000000000
> -0800
> +++ linux-2.6.11-rc2-lem/drivers/block/ub.c 2005-01-24 17:40:19.000000000
> -0800
> @@ -1905,12 +1905,14 @@
> * this point.
> */
>
> +#if 0 /* P3: experiment */
> /*
> * This is needed to clear toggles. It is a problem only if we do
> * `rmmod ub && modprobe ub` without disconnects, but we like that.
> */
> ub_probe_clear_stall(sc, sc->recv_bulk_pipe);
> ub_probe_clear_stall(sc, sc->send_bulk_pipe);
> +#endif
>
> /*
> * The way this is used by the startup code is a little specific.
> @@ -2084,6 +2086,15 @@
> */
> del_timer_sync(&sc->work_timer);
>
> +#if 1 /* P3: experiment */
> + {
> + int t0, t1;
> + t0 = usb_gettoggle(sc->dev,
> usb_pipeendpoint(sc->recv_bulk_pipe), 0);
> + t1 = usb_gettoggle(sc->dev,
> usb_pipeendpoint(sc->send_bulk_pipe), 1);
> + printk("ub: exit with toggle %d %d\n", t0, t1);
> + }
> +#endif
> +
> /*
> * At this point there must be no commands coming from anyone
> * and no URBs left in transit.
>
> Result: If at rmmod time it prints "1 1", then the next modprobe will have
> difficulties (the ub in 2.6.10 retries and is able to continue). If at rmmod
> time it prints "0 0", then next modprobe happens without incident. I wasn't
> able to make it to end with "1 0" or "0 1".
>
> So, Alan, it looks you were right, but what is the outcome? Do you have a
> patch to address this?
Not yet. It's not obvious what is the right thing to do. Resetting pipes
after every altsetting change would be a waste for the majority of devices
that handle things correctly. Can we settle for resetting the pipes only
after SET_INTERFACE requests that don't change the altsetting value, or
for interfaces that only have one altsetting? Even these will add
unnecessary overhead in many cases...
Note that usbcore already has code to do these resets, in
messages.c:usb_set_interface(). But it only runs if the device rejects
the SET_INTERFACE and has only one altsetting.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
