On Thu, 6 Jan 2005, David Brownell wrote:
> > Your patch changes the initial descriptor read from 64 bytes to 18 bytes,
> > right? I'm almost certain that will break with some devices (although it
> > may help others).
>
> I think it'd work better with _most_ devices, considering that
> bugs handling short reads (like returning 18 bytes when asked
> for 64) are more common than ones handling full sized reads
> (like returning 18 bytes when asked for 18).
The best answer may be to make use_both_schemes=1 the default. I'm sure
I've seen log reports of devices that failed when initially asked for 18
bytes worth of the device descriptor and worked when asked for 64 bytes,
even though they only returned 18.
> > Anyway, the intent of the scheme was to duplicate the
> > Windows packet sequence, which always requests 64 bytes. The real
> > question is: If a device works under Windows, why doesn't it work under
> > Linux with the same sequence of packets?
>
> That's one question. You may recall that I submitted a patch a
> while back to retry the read in that case, rather than failing...
> you changed it to check much later, instead of retrying right away.
It's not _that_ much later. Only a port reset intervenes. And the
current code in gregkh-2.6 does retry immediately on length-0 reply or
STALL. Would you like to see it retry also if the second byte of the
reply is not equal to USB_DT_DEVICE? How does the patch below look?
> That's because I saw devices that failed without early retry;
> the short read confused the hardware (or firmware), and the
> data landing in that buffer needed more checks. The normal
> code for usb_get_descriptor() retries when it gets garbage;
> but in that code path, you don't retry.
The code _does_ retry, following a port reset. Anyway, if a short read
confuses the device, how does immediately repeating the short read manage
to unconfuse it?
> Another question is whether those devices will work better
> under Linux when not forcing short reads ... :)
That's why I think we should always use both schemes.
Alan Stern
===== drivers/usb/core/hub.c 1.222 vs edited =====
--- 1.222/drivers/usb/core/hub.c 2004-12-20 20:14:32 -05:00
+++ edited/drivers/usb/core/hub.c 2005-01-06 13:43:42 -05:00
@@ -2197,6 +2197,11 @@
(i ? HZ * USB_CTRL_GET_TIMEOUT : HZ));
if (r == 0 || r == -EPIPE)
continue;
+ if (r >= 2 && buf->bDescriptorType !=
+ USB_DT_DEVICE) {
+ r = -EPROTO;
+ continue;
+ }
if (r < 0)
break;
}
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
