On Fri, 18 May 2012, Chen Peter-B29397 wrote: > Hi Ming, > > I have debugged it at this afternoon, your description for this problem > is correct, the ehci_reset override the ehci->command which is assigned > at ehci_init, and ehci->command at ehci_init is correct. > > My opinion for this fix is just remove the > " ehci->command = ehci_readl(ehci, &ehci->regs->command);" at ehci_reset. > Even someone called ehci_reset to reset controller, it can still use command > value assigned at ehci_init. Yes, I see the problem. And you are right; the value assigned during ehci_init() should not be overridden. However... The value assigned in ehci_init() is not fully correct. That routine does not examine the default value in the USBCMD register before making its own settings. (It can't -- the USBCMD register may contain random garbage because the controller hasn't been reset at this point.) This means that ehci_init() can't handle hardware updates. New versions of the hardware may define bits in USBCMD that the code doesn't know about. Those bits would be set properly by default when a hardware reset occurs, but then ehci_init() would wipe them out. It looks like a bunch of code needs to be moved from ehci_init() to ehci_reset() -- everything involved in computing ehci->command. The idea is that once the controller has been reset, we first set ehci->command to the value in the USBCMD register (as is done now). Then we can modify the bits we know about (as the code in ehci_init() does) while leaving the other bits alone. I'm too busy to work on this until next week. Would one of you like to write a patch to do it? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
