Dear Stephen Warren, > On 06/19/2012 02:47 AM, Jim Lin wrote: > > A known hardware issue of USB1 port where bit 1 (connect status > > change) of PORTSC register will be set after issuing Port Reset > > (like "usb reset" in u-boot command line). > > This will be treated as an error and stops later device enumeration. > > > > Therefore we add a definition in header file and a callback function > > to clear that bit after Port Reset in order to proceed later device > > enumeration. > > > > CONFIG_USB_EHCI_SUBMIT_ROOT_POST_CALLBACK
We did such fix in the past by adding weak function. Check ehci-hcd.c > > This style of fix (adding an optional callback from the USB core) seems > like the idea to me. Thanks. > > However, I'm a little worried that it implements the bug workaround at a > different time to the Linux kernel. The kernel does: > > * Assert reset to the port > * Poll the port for enable (any time delays are here) > * Clear the CSC bit > > So, the CSC bit is cleared a long time after the port is reset. > > However, this U-Boot patch does: > > * Assert reset to the port > * Clear the CSC bit > * Wait a long time; 200mS > * Check the port is enabled > > So, the CSC bit is cleared immediately after the port is reset. > > Is this U-Boot fix still guaranteed to solve the problem? In your > testing, how many times did you test without this fix, and what was the > failure percentage. How many times did you test with the fix, and what > was the failure percentage? > > I think it'd be safer to execute the callback from inside > hub_port_reset() right before the call to usb_get_port_status(). That > would make the time when CSC gets cleared much more equivalent between > the Linux kernel and U-Boot. The implementation of the callback function > could probably be a lot simpler to (e.g. doesn't need to check which > feature is being set etc.) Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot