On Tue, 2007-07-24 at 13:52 -0700, Pete Zaitcev wrote: > 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.
That fact is actually exploited. If the device cannot return its operation mode, it needs primary firmware and reset. If the device cannot report its firmware version, it needs secondary firmware. It's not a big deal to add checks in those two cases. The code dealing with uninitialized devices should be extra robust. I would prefer not to add extra checks for the usb_control_msg() that don't not normally fail, but if the USB API doesn't protect me from short and zero reads/writes, I have no choice but to add those checks. > > 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. Oh well, I guess I'll need to write a wrapper around usb_control_msg(). But in the long term, it would be great to have a flag to indicate that I want the exact number of bytes. Something like URB_SHORT_NOT_OK. > > 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. Indeed, EOF would cause a zero read without an error. > 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...) Actually, it's a USB 1.1 device, so I guess it's UHCI. Anyway, thanks for clarification! -- Regards, Pavel Roskin ------------------------------------------------------------------------- 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
