Re: usb_control_msg() reads 0 bytes in Linux 2.6.23-rc1

Pete Zaitcev <[email protected]>
Newsgroups gmane.linux.usb.devel
Organization Red Hat, Inc.
Message-ID <[email protected]>
On Tue, 24 Jul 2007 16:28:15 -0400, Pavel Roskin <[email protected]> wrote:

> It turns out usb_control_msg() returns 0 in two cases where it returns
> -EPIPE in Linux 2.6.22.

This is significant. EPIPE is a "stall", but zero bytes is zero bytes.
Normally they do not mix. If a device stalls a request, it's different
from returning no bytes of data. Actually, I'm wondering if your tests
were clean enough... If you load firmware, a device can alter its behaviour
drastically, and switch from stalls to empty replies or normal replies
or whatever.

> Return value 0 is not expected to be an error,
> which prevents second stage of the firmware download, normally triggered
> by an error reading the firmware version.

Well, as you are aware now, it's a separate condition which you have
to check. A device can return zero bytes, or one byte, or whatever.
If it's not supposed to do that, you have to take some corrective action,
like a reset.

> However, I think it's wrong to return 0 if more than 0 bytes were
> requested.  usb_control_msg() is synchronous, and the caller is supposed
> to wait for the data.  If the function returns and the data is not
> there, it should be an error IMHO.

I disagree, and in any case it's too late to do anything about it.

BTW, read(2) can return short reads in many circumstances where
you opened a character device without O_NONBLOCK. Consider a synchronous
link. You issue a read for maximum packet size, and then receive the
actual number of bytes, or even a zero.

Please keep in mind that all this discussion about short reads has
nothing to do with your real problem (e.g. the device which used to
reply with a stall stopped to do so, or it continues to reply with a
stall token, but EHCI fails to report the stall up the stack...)

-- Pete

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.