On Wed, 17 Aug 2005, David Brownell wrote: > The attached patch is compile-tested, and tweaks a bunch of things > that might be causing trouble in the enumeration paths. Maybe some > of the tweaks will help, and we could get this fixed for 2.6.13...
> - Only interrogate full speed devices about ep0 maxpacket size. Your patch needs to reset udev->descriptor.bMaxPacketSize0 back to 0 at the time the "read/64" error message is logged. Otherwise the device might not be interrogated the next time through the loop. Do you think there might be low- or high-speed devices out there that won't work without the Microsoft initialization sequence? Just asking -- I can't recall ever hearing of any. > - Once we know the ep0 maxpacket size we're using, don't bother > trying to read it again. This might cause trouble for the full-speed devices that _do_ require the Microsoft sequence. Can't tell without testing. > - After a set_address() error, reset the port. Failures in that > request leave the device's address indeterminate. Is this maybe getting to be too much retrying? The current code tries to set the address twice, with no intervening reset, on the theory that a failure indicates the device did _not_ change its address. If this turns out to be wrong, the caller's loop processing will do some more retries anyway. On the whole, I think that routine already does enough resets. Also, you don't check for speed changes following the reset. Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
