Alan Stern wrote:
On Tue, 10 Dec 2002, David Brownell wrote:Hm, this patch doesn't solve anything :(As in, "no effect" or "the big issue didn't go away"? If "no effect", then I wonder why storage is distinguishing that case at all. But it seems like it ought to handle the -EREMOTEIO short read cass like the other one. - DaveI agree completely that usb-storage needs to handle -EREMOTEIO if that is a possible error code indicating a short transfer. It makes me wonder if
Short _read_ transfers only.
Check Documentation/usb/error-codes.txt ... the reason storage didn't seethere are any other status codes that we need to handle... There isn't a complete list of possible status codes and their meanings, is there? I didn't see one in include/linux/usb.h or drivers/usb/core/urb.c.
this one before is that the sglist primitives don't treat reads specially.
The -EPIPE handling could stand a minor tweak ... it assumes that if
the pipe isn't bulk, it's control, but interrupt endpoints can halt too.
So test "if (usb_pipecontrol(...))" instead of "!usb_pipebulk(...)".
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
