On Mon, 14 Oct 2002, David Brownell wrote: > > No. The USB spec (section 9.2.6.4) grants up to 500 msec for every single > > DATA IN packet in a control transfer. I don't mean the packet would take > > that long to go over the wire, but it's acceptable to source/sink one > > packet every 500 msec. This means one would see a lot of NAK's meanwhile. > > Which made me wonder why USB_CTRL_GET_TIMEOUT defaults to three seconds > (or four given CONFIG_USB_LONG_TIMEOUT) not five!
Good question - no idea! >From the specs we should IMHO have USB_CTRL_SET_TIMEOUT fixed to five seconds. I've no idea how to implement the one packet every 500 msec requirement. OTOH the length of the IN request is known in advance (from the initial 8 byte read) and with given maxPacketLen one could calculate the number of packets and therefore a total timeout for any particular transfer. #define GET_TIMEOUT(len, maxp) (((len)+(maxp)-1)/(maxp)/2) But all such changes have some risk to break existing "real world" kind of devices. And I don't see a need here to do so if they are working now. > And how they concluded Ceiling(N packets * 1/2 second) == 5 seconds ... that's > a max of ten packets. I think there was serious fudging going on there, to > try and come up with a rationale for picking five seconds. (As arbitrary > as any rationale for invading iRaq, but that's offtopic.) The 500 msec interpacket timeout and the 5 sec total timeout are for different directions, see below. > > While there is a global upper limit of 5 sec for the whole control > > transfer if it's DATA OUT, the specs don't mention any upper limit if the > > DATA stage is directed to the host. > > Err, I think you mean if the DATA stage is directed to the DEVICE. > IN == to host. OUT == to device. I'd expect the same constraints > to apply. Unfortunately not (9.2.6.4): The "5 sec total" is to the device (OUT), the "one packet every 500 msec" is to the host (IN). > > I'm just wondering whether I could add such a pathologic device mode to > > the usbtest firmware to see what would happen ;-) > > Hey, I thought you were trying to avoid writing EP0 implementation code! Yes, I was. Meanwhile, collecting stuff for the firmware source release provided enough code fragments so we can have EP0 from the beginning. In fact it's already passing test9 (and fails most others - but that's a different story...) Martin ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
