On Wed, 12 Jan 2005, David Brownell wrote: > 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. > > Now for net2280, ep0 maxpacket == 64 so once you receive > 32 bytes, you know that IN stage terminated. And when > URB_SHORT_NOT_OK is set _and_ the URB buffer isn't full, > that eventually gets reported as -EREMOTEIO, which is > what that test insists on seeing. > > 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.
It's even trickier than that. If URB_SHORT_NOT_OK is set then you're not supposed to transmit any more to that endpoint until after the URB's completion handler has run. It might be possible to arrange this while still carrying out the STATUS stage, but it's easier just to skip the STATUS stage. I guess you could say that when URB_SHORT_NOT_OK is set, a short packet counts as a "Real Error". Alan Stern ------------------------------------------------------- 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
