On Monday 17 January 2005 1:07 pm, Alan Stern wrote: > On Sun, 16 Jan 2005, David Brownell wrote: > > > For what it's worth, I like the idea of avoiding all that complicated > > strange-read/extra-reset logic (to figure out ep0 maxpacketsize) except > > when it's absolutely necessry: only for full speed devices. > > > > The reason that stuff gets complicated is primarily because of hardware > > that misbehaves when faced with those strange read scenarios; and the > > extra reset is to recover from the misbehavior. But high speed (and low > > speed) devices don't need that strange read; ep0 for those speeds only > > has one value. Every device I've seen (or heard of) having those problems > > is running at full speed. > > 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". > in which case > retaining it as a backup for full-speed devices wouldn't be much effort. > (The only devices I can find reports of in the archives which _needed_ the > new scheme were running at full speed, so this approach makes sense.) They're also the only ones which _need_ the "strange read". > 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. - Dave ------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
