On Fri, 2004-07-23 at 07:36, Alan Stern wrote:
> On 22 Jul 2004, David Meggy wrote:
>
> > I needed a check for this when working on the national 9604 gadget
> > driver. The National chip only has an 8 byte fifo on end point 0.
> > Until the device is in the configured state I had to change wLength to
> > 8, if I read a greater value.
>
> I don't understand. Are you saying that ep0 uses different maxpacket
> values in the default/addressed states and the configured state? And that
> the value in the device descriptor is the correct maxpacket size in the
> configured state but is wrong for non-configured states?
>
> Or are you saying that ep0 always has a maxpacket size equal to 8 but
> sometimes the device descriptor includes an incorrect larger value?
>
> Either way, I don't see how the device could hope to work in general, and
> it certainly would be in violation of the USB spec.
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 haven't checked the USB spec. but I
> > think there is probably some logic behind MS's thinking and this is how
> > things are supposed to work.
>
> >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.
> On the other hand, Kyle also said that some devices don't work when asked
> to transfer 18 bytes in the initial get_descriptor, the implication being
> that they expect to see a 64-byte transfer request. Or maybe he meant
> that some devices didn't work like that in his particular setup.
>
> Either way, our best approach has got to be to use the current
> standards-complaint strategy initially, and if that fails fall back on the
> Windows-like strategy (insofar as we understand how it works). Do you
> have any suggestions for alternate approaches?
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.
David
--
~~~~~~~~~~~~~~~~~~~~~~~~
David Meggy
Engineering
Technical Solutions Inc.
Unit #1 7157 Honeyman St
Delta BC Canada, V4G 1E2
www.techsol.ca
eMail: [EMAIL PROTECTED]
Tel: 604 946 TECH (8324)
Fax: 604 946 6445
~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------------
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
