On Monday 11 October 2004 8:00 pm, Alan Stern wrote: > On Mon, 11 Oct 2004, David Brownell wrote: > > > Control endpoints are bi-directional (with a single queue), > > so it should never be necessary to disable two directions > > for a control endpoint (like ep0). > > That's true in theory. The practice gets a little confused, particularly > when you reflect that control URBs have _two_ direction indicators: one in > urb->pipe and another in urb->setup_packet->bRequestType.
An HCD should only look at what's in the pipe thing. > > Secondarily, yes that's (currently) the first/only request that > > has been issued to that device, so it's also not possible that > > the HC or HCD cached state for ep0 IN transactions. > > Again true (currently, but not after the initialization change). It's not > clear what cached state could be changed by the SET-ADDRESS request -- > apart from the obvious candidate, the device address. Do you think the > EHCI/OHCI driver or hardware was somehow getting confused by the address > change? The address gets stored into the QH, and the HCDs need special casing already to change out of address zero. Confusion has been observed in that area before. > More generally, do you have any idea how this patch helps solve > those "not accepting address" errors? Or why things used to work better > than they do now? I didn't have a time to track it down. The specific scenario was hooking up a low speed device through an external hub, using OHCI. The hub enumerated fine ... and it went through the bit of code where it adjusted ep0 maxpacket size. The mouse did not enumerate, getting set_address failures. I remember this device always reporting an error on the first SET_ADDRESS. By process of elimination, there was some state stuck somewhere after that first error ... and the obvious "scrub it out" patch made the mouse enumerate. Yet I didn't notice any relevant changes in the OHCI code for the last many months. > 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. - Dave > > 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
