On Thursday 06 January 2005 11:11 am, Alan Stern wrote: > > The only thing that a quick scan of the ehci resume > > code suggested might be a problem is the line of code > > in ehci-hub.c::ehci_resume() that checks for whether > > the PORT_SUSPEND bit is set. Maybe that should be > > checking for (PORT_SUSPEND|PORT_OWNER)? > > I guess that might work. Is there any reason why PORT_SUSPEND would be > set if PORT_OWNER was set?
It's just a hypothesis -- that if a companion controller is using the port (PORT_OWNER set) that's as good a reason to avoid reset as if EHCI is using it, and we've seen an honest-to-gosh resume. Although I didn't need that with an OHCI companion controller, I'd not rule out having missed that particular test case (out of hundreds) ... or that maybe Intel hardware acts a bit differently than what I used. - Dave ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
