> > Consider queuing 4 1K URBs. The device decides to only send us 2.5K of > > data, which will complete the first 2 URBs and then terminate the 3rd on a > > short packet. > > > > But that's not an error. So the 4th URB will still run. And, since these > > are all queued up, the code doesn't have a chance to cancel the 4th URB > > fast enough. > > Is there a problem with treating it as an error ?
See my previous note -- I think that the host controller drivers should be aborting all those queued URBs in case of error, but suspect they don't. So turning one scatter/gather list into a set of queued URBs would naturally submit each of those URBs in the "short read packet is an error" mode. > We should introduce a third parameter to the completion handlers to indicate > the URB that caused them to be called. > In principle queueing URBs is more flexible as you could submit whole > sequences as one. I'm not sure what you mean here. There are two queuing mechanisms in usbcore that are visible to device drivers. Bulk queuing is what we're talking about here. Then there's the urb->next queuing, which AFAIK only works in a restricted mode for ISO requests. As I understand. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
