On Thursday 06 January 2005 7:03 am, Alan Stern wrote:
> On Wed, 5 Jan 2005, David Brownell wrote:
>
> > I'd be interested in knowing if the following patch makes much
> > of a difference ... I suspect it'd help other cases a bit better,
> > where the "-EPROTO" error suggests that the oversized read had a
> > somewhat impolite failure mode. Though this case ("-ETIMEDOUT")
> > might be affected too; who knows.
>
> 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).
> 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.
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.
Another question is whether those devices will work better
under Linux when not forcing short reads ... :)
> > It may also be worth noting that usb_control_msg() has a rather
> > atypical failure status. Normally one expects that when software
> > reads N bytes successfully then gets an error, the return from
> > the read is N not an error code ... usb_control_msg() returns
> > the error code instead. I've seen some devices that act a lot
> > happier if that's changed to return N, like any normal read;
> > so usb_internal_control_msg() would
> >
> > return length ? length : retv;
> >
> > I forget why I never submitted a patch to do that.
>
> Are there are drivers that actually care about this?
Care about getting error reports when they could have gotten
a success report? Sure. Though as I said, it's devices
that are the issue ... ones that trigger errors in those
paths (at least sometimes) are going to make drivers unhappy.
Most driver (and usbcore!) code doesn't cope well with control
requests failing.
> What about the usbfs API?
See how read() is defined; that's a better match for the
return statement I showed. As a rule, usbfs has never
behaved well in the face of faults reported during control
transfers... changing that should be an improvement.
> The initial descriptor read in the hub driver is very careful to
> ignore the return code and only pay attention to the data buffer.
Only on the "new scheme" branch; but there it doesn't use
logic like usb_get_descriptor() does, to retry the descriptor
fetch immediately when the hardware or firmware got confused.
- Dave
-------------------------------------------------------
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
