On Tue, 27 Jul 2004, David Brownell wrote:
> Periodically I think about changing how Linux does this -- to do exactly
> that: request 18 bytes of device descriptor right away to determine
> ep0 maxpacket, and assume it's 64 bytes at first (usually is!) rather
> than just 8 bytes. But I lack time to tweak such stuff.
>
> The downside of what Linux does today is exactly what Kyle noticed:
> certain hardware and/or firmware mislikes that initial short request,
> (in fact, misliking _all_ short requests seems to be the pattern)
> and things go haywire. On the other hand, changing it could just
> cause problems with _different_ hardware and that might not be
> a net win. Such a patch would IMO be a good experiment to try
> in the MM tree for a while. (Failures wouldn't be subtle ...)
I did write a first pass at such a patch while you were away; by now you
may have seen it. In general I think this part of hub_port_init() could
stand to be cleaned up. For instance, consider the outer loop on i:
for (i = 0; i < GET_DESCRIPTOR_TRIES; ++i) {
Nobody seems to have pointed it out, but it's nearly impossible for that
loop to succeed on any iteration after the first one. The reason is
simple enough. If the call to hub_set_address() fails each time through
in the inner j-loop then the i-loop isn't repeated. If it succeeds, then
on the next iteration through the i-loop hub_set_address() is virtually
guaranteed to fail, since it will try to send a SET_ADDRESS message to the
device at address 0 when in fact the device already is using a non-0
address. The only way it could succeed would be if the device returned a
positive acknowledgement to the first SET_ADDRESS but nevertheless
didn't start using the new address.
> > Is anyone familar with this scenario? Any suggestions on how to
> > handle it? An initial get_descriptor of 18 bytes breaks other devices,
> > so that is not an option.
>
> What other devices does it break though? The only possible trouble
> would be hardware that doesn't respond correctly to the SETUP
> request that'd start the next request ... I don't happen to know about
> any such hardware, and that particular breakage would cause
> trouble in many other situations too.
>
> Fetching 18 bytes, with initial maxpacket guess of 64 bytes,
> should have three cases:
>
> - real maxpacket 64 -- nothing to change, no more fetches
> - real maxpacket 32 -- need to patch ep0 maxpacket, but
> also no more fetches needed
> - real maxpacket 16 or 8 -- patch ep0 maxpacket, then need
> to fetch the rest of the descriptor ... and relies on SETUP to
> work correctly (starting new control request)
>
> If there's hardware that misbehaves on that next SETUP, it's
> theoretically possible it'd also break on the RESET that'd
> follow such misbehavior. But that'd all be inside the
> hub_port_init() code, and I have a hard time thinking that
> anyone ought to care about hardware that's so deeply
> broken _both_ of those things will fail!
I think the best approach may be to Talk Like Windows, which means using a
64-byte GET_DESCRIPTOR followed by a reset. Any device which can't handle
that won't work with Windows 2000 either (as shown by my tests). And it
actually did succeed in getting one person's device to work, see
http://marc.theaimsgroup.com/?l=linux-usb-users&m=109076418720851&w=2
In my patch, the current Linux technique gets used the first time
hub_port_init() is called and the Windows technique is used the second
time. That seemed like a reasonable compromise, although given that two
different algorithms are being used it might be a good idea to try more
than just two times! It also might help to try increasing the time delay
after the port reset, although this is merely conjecture based on the
source code for the Mac OS-X hub driver (which is freely available).
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
