On Fri, 7 Jan 2005, David Brownell wrote:
> > The best answer may be to make use_both_schemes=1 the default.
>
> That'd likely reduce the number of problem reports, but I suspect
> it'd still be masking some fixable problems.
Probably.
> > 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.
>
> I don't recall any such reports, but then the developers of
> firmware bugs can be rather creative ... ;)
IIRC these were posted to linux-usb-users. They were for Sony video
cameras or something like that. In fact, they were part of my motivation
for writing the new-scheme patch originally.
> That patch looked OK, but I might prefer one that also validated
> the ep0 maxpacket size too. (The patch I sent _only_ validated
> that field.) How about something more like
>
> if (r < 8 || buf->bDescriptorType != USB_DT_DEVICE) {
> r = -EPROTO;
> continue;
> }
> switch (buf->bMaxPacketSize0) {
> case 8: case 16: case 32: case 64: break;
> default:
> r = -EPROTO;
> continue;
> }
>
> No real point in accepting a read of 3 bytes and then relying
> on the non-existent 8th byte ... or relying on obviously borked
> data in that byte!
Okay, I'll submit a patch. Note that the check you wrote isn't entirely
correct, because it allows things like 8-byte maxpacket for a high-speed
connection. The one at the end of the initialization routine _is_
correct.
> > > 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.
>
> Yes, I think that'd be a less troublesome default.
>
> But I also think we need to make all the control transfers
> during the init sequence be more robust.
It may help. But most of the problem reports I've seen involved transfers
getting an error rather than stalling or sending incorrect data.
Alan Stern
-------------------------------------------------------
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
