On Mon, 11 Oct 2004, David Brownell wrote: > > I'm worried that this patch will no longer be adequate when the > > initialization sequence changes. If I knew exactly what needed to be > > fixed, I'd be a lot more confident... > > I know the feeling, believe me! On the other hand, usbcore > should be scrubbing out that state anyway. It's not the kind of > API glitch that HCDs should need to notice, and scrubbing it > out will let me finally eliminate some ugly code from the > OHCI and EHCI drivers.
There's already code in hub_port_init to scrub ep0 for full-speed devices when the ep0 maxpacket value is different from the initial guess. I can make that unconditional, for all devices. Would that be okay? And should it go only where it is now (following the 8-byte descriptor fetch) or should it also go directly after the SET-ADDRESS call? I've been planning on doing something like this anyway. Some devices enumerate more reliably under UHCI without full-speed bandwidth reclamation. The easiest way to set that up is to put control messages for devices in the DEFAULT state on the low-speed control queue (which isn't subject to bandwidth reclamation). It then would become necessary to scrub the endpoint state so that later the messages could go on the full-speed control queue. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
