On Saturday 24 July 2004 11:36, Alan Stern wrote: > 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.
Actually not all hardware seems like it will handle the "early status" transaction termination (for a GET like this, getting OUT not IN) the way that the USB specification says it should. A better way to handle the early OUT is just to ACK it; there's no real point in trying to stall it (even if the hardware can!). The host just for some reason changed its mind about how much data it expected; or the peripheral side driver got confused. Either way, there's no good reason to report an error to the host. > > > >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. Happens sometimes when that descriptor fetch is handled by the hardware rather than by firmware ... and the hardware is buggy. > 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. Buggy hardware could misbehave in such cases ... > > 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 I'd say instead: it's hard for host software to accommodate all possible hardware bugs. If the hardware works correctly, it's easy to make the host side software behave. > > 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. FIFO size can be smaller to shave transistor count. For example PXA uses a 16 byte FIFO ... but I seem to recall IN having a separate FIFO than OUT, so that's 32 bytes worth of transistors, one quarter as many as 64 byte FIFOs would need. I forget the details, GOKU only uses 8 bytes of ep0 FIFO but that was to make it work better. OMAP can configure how much FIFO to use, it currently configures 64 but that can be shrunk for configurations that need lots of FIFO memory for other purposes. - Dave ------------------------------------------------------- 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
