On Thu, 18 Aug 2005, David Brownell wrote: > Remember, the maxpacket size is a _hardware_ limitation and the > reason for the dance at fullspeed is that there are several > special failure modes there to elicit host and peripheral bugs.
Hmm... Depends on who you ask. I would have said that the reason for the fullspeed dance is because some devices won't work without it. That's different from eliciting bugs -- it's more like avoiding bugs. > > > - 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. > > See above: it's a hardware limitation. The MSFT dance is just > to dodge driver bugs while discovering that particular limitation. -----------^^^^^^ Device bugs? Usbcore bugs? Anyway, this means that if you skip doing the MSFT dance (by not rereading the ep0 maxpacket size) then you risk provoking one of those bugs. > Since it's hardware, that value isn't going to change. The maxpacket value isn't going to change. But the device's behavior might very well change, since it is controlled by buggy firmware. This is all theoretical, however. Until someone with one of those devices (mostly Sony digital cameras, as I recall) tries the patch, we won't know for sure. > > > - 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. > > Then again, the theory of this patch is that there are usbcore bugs, > and that could be one of them.... :) I don't see how sending a Set-Address request to a device that may already have changed its address could be considered a bug. At worst, it's a waste of a few hundred milliseconds. 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
