On Thu, 20 Jan 2005, David Brownell wrote: > > I tend to agree with Pete, although I would hold off on disposing of the > > old scheme until we're quite sure about the new one. David favors keeping > > the old scheme for use with low- and high-speed devices, > > Actually that's not what I described. The schemes had THREE intentional > differences ... which may explain why the new one gives such wierd problems, > though some of that may be the missing 10msec delay after reset. > > - What kind of "strange read" to issue: 8 bytes, 64 bytes, or whatever. > (I still like "18 bytes", on the grounds that except for full speed ep0 > maxpacket sizes of 8 and 16 bytes, it's never "strange".) > > - Whether to issue an extra reset or not, after the "strange read". > > - Whether to read the device descriptor when the device is using address > zero (new scheme), or whether to assign an address first (old scheme). > > What I described was "either scheme, _without_ strange read".
Okay, I get it. Although I think that some badly-designed devices won't work with a "strange read" of other than 64 bytes. (And of course, a compliant device will work almost no matter what we do.) If we learn after the "strange read" that it really wasn't "strange" after all (like ep0maxpacket of 32 or 64) then the extra reset probably isn't needed. It's hard to be certain of that, although if leaving out the reset works with the devices described in the linux-usb-users archives then it will most likely work in general. > > I also would like to see the backoff to the old scheme working, however it > > may be that when these high-speed devices change their speed they require > > a port-power cycle before going back to high speed. If we eliminate the > > new scheme for high-speed devices this becomes a moot point. > > Erm, I've never heard any report of high speed devices that need a port > power cycle. I've only seen that need with old/cheap lowspeed devices. > > The way the high speed "chirp" works is that on initial connect, signaling > looks like full speed ... but the reset includes extra information that > kicks in high speed signaling. Suspend uses full speed signaling, resume > goes back to high speed. > > So far as I know, we've never had problems with the high speed resets. > Though the omission Pete noted (10msec delay after reset) seems likely > to have been causing some problems on the host side; that's not a device > problem, it's a (new?) host-side one. You appear to have misunderstood what I was saying. Pete described a device that, after failing to initialize correctly at high speed a couple of times, decided to remain at full speed following the next reset. (Perhaps it was so discombobulated that it didn't send the high-speed "chirp".) I was speculating about what would be needed to get the device operating back at high speed again. Evidently a reset alone isn't enough; maybe a power cycle would be do the trick. Adding a 10 or 20 ms delay after resetting is a necessary first step. Beyond that there are so many possibilities it's hard to keep them straight. The one (only?) advantage of the current "new" scheme is that it faithfully copies what Windows does. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
