On Thu, 6 Jan 2005, David Brownell wrote: > > In any case this isn't under our control. > > Devices are resumed in the same order they were detected initially. I > > think the only way to solve this problem is to find a workaround for EHCI > > controllers that act weird when they resume. > > The problem could well be in UHCI instead, or BIOS.
I don't see how. Nothing in the UHCI driver is aware of the existence of that flip-flop or does anything to change it. It's entirely under control of the EHCI driver. Is it possible that the hardware or the BIOS is changing the flip-flop? That's why I suggested seeing what happens when ehci-hcd isn't loaded; if some other component changed the flip-flop you would expect the test to fail in the same way. Instead it succeeded. > 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 also possible that the flip-flop is changed during the suspend operation rather than the resume operation. Perhaps Oliver can add some debugging lines to print the values of the regs->port_status[] entries in those three loops (one in ehci_hub_suspend and two in ehci_hub_resume). Alan Stern ------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
