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/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
