> No timer. This should be detected by checking the packets > sent by the device. There are basically two cases when > reading any IN (*) packet (not just control transfers): > > - Peripheral sends N = maxpacket bytes ... this particular > packet wasn't "short", so the transfer proceeds (unless > urb->transfer_buffer was just filled). > > - Peripheral sends N < maxpacket bytes ... this one was > short, the transfer terminates.
Ah, yes, forgot this case. Clearly, all the real devices tested until now have either returned the requested amount of data or URB_SHORT_NOT_OK flag in the urb has been clear. > The tricky bit with control transfers is that at this point > it's time to move from the control DATA stage into the > control STATUS stage (OUT DATA1 zero-length packet), even > if urb->status will later be reporting a "short" fault. > But if you got a Real Error (-EPIPE/stall, etc) you'd be > skipping that STATUS stage. > > The _really_ tricky bit is that if your HCD skips the > DATA stage it'll usually work. Except ... that some > peripherals will misbehave (badly) when you do that, > leading to some mysterious failures later on, but only > with certain devices. Thanks for this info. Currently the driver skips the STATUS stage for data underrun. Will fix it. Thanks to anyone who wrote the usbtest suite (you, David :) There is a copyright missing in the drivers/usb/misc/usbtest.c Olav ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
