> 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! 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.) > 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. > Admittedly, I'm stressing extreme cases here for demonstration - my point > was simply it is both expected (due to the involved internal housekeeping) > and granted by the specs for a control transfer to be pretty NAK-friendly. > > 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! - Dave ------------------------------------------------------- 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
