On 23 Jul 2004, David Meggy wrote: > Neither. Actually now that I think about it, the Windows approach makes > less sense. Windows makes a request larger than 8 bytes. Having only > an 8 byte fifo, I send 8 bytes. At this point I had to modify my code > so I wouldn't send anymore data, and it would wait to receive a ZLP to > end the transaction. I think Windows just wants 1 packet back, and > doesn't care what size it is.
I think the Windows approach does make sense, if you grant the assumption that some devices don't like to send less than the full device descriptor. Although it's not clear why they found it necessary to request a 64-byte transfer rather than 18 bytes. Kyle said some devices don't like an 18-byte request, but he didn't provide any details. And I don't see why you had to modify your code... You should send the first 8 bytes, then wait for another IN so you can send the second eight bytes. When you get an OUT instead of an IN you can pretty much do whatever you want (except crash) -- it doesn't matter because Windows does a port reset next. In your position, I would program the controller so that whenever a control-IN transaction gets an unexpectedly early OUT it replies with a protocol STALL, if that's feasible. > > >From what Kyle wrote, I gather that some devices can't handle > > get_descriptor requests unless they are asked to transfer the entire > > descriptor. Some devices may hang (or NAK) indefinitely, others may try > > to transfer more than they were asked to send. The approach he described > > is a way to work around this problem, by always asking for the entire > > descriptor even before the maxpacket size is known, then resetting the > > port to clear whatever error condition was provoked. > > This would break my gadget driver. As I don't think anyone is using > this in the field, that isn't a big deal. I would have to think about > how to solve the Windows case. How does this break your driver? You ought to be able to handle a port reset occurring at any time, even in the middle of a control transfer. If you can't handle that, your driver is already broken. When you come down to it, in fact the gadget driver doesn't have to handle these things at all. It's the controller driver's responsibility to manage control transfers. > No, as far as I can tell all approaches have problems with some > devices. I haven't done much USB work. How rare is the 8 byte fifo on > endpoint 0 for FS devices? I wonder if this is just a specific case > that MS screwed up. I don't think they screwed this up -- if they did then lots of devices wouldn't work with Windows. 8- and 64-byte maxpacket for ep0 are the two most common cases. Presumably earlier or cheaper controllers use the smallest possible fifos and later or more expensive ones use the largest possible. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
