Hi Anand, Gadiyar, Anand wrote: > Alan Stern wrote: > >> On Mon, 7 Jun 2010, Gadiyar, Anand wrote: >> >>> Hi all, >>> >>> On the OMAP3, we have a new hardware bug that causes the >>> EHCI controller to lock up under heavy stress. The only >>> known way to recover is to soft-reset the controller. >>> >>> I'm trying to implement some kind of recovery mechanism >>> for the ehci-omap driver. Is there a way to inform the >>> USB core that the root-hub and down-stream devices have >>> been reset and need to be re-enumerated? >>> >> There's usb_hc_died(). It tells the core that the controller has >> stopped working. The core then removes all devices below the root hub >> and marks the root hub as non-operational (the state is set to >> USB_STATE_NOTATTACHED). But there is no re-enumeration; from that >> point on the root hub is unusable. >> >> This may not be exactly what you want. Perhaps a better match would be >> usb_reset_device(), but that routine specifically excludes root hubs. >> You might be able to adjust it in some way, though. >> >> Another alternative is simply to unregister the hcd and then >> re-register it. >> >> > > (Sorry, hit send before completing the mail) > > Thanks! As a quick test, I built the driver as a module. And > in the remove path, we soft-reset the controller anyway. > > as I was the one who originally reported this problem, I can tell you that soft-reset of EHCI is not enough. I had to reset UHH to recover - sometimes losing EHCI for good, but I guess that was something else in the end. (I assume we are discussing the issue "Advisory 3.1.1.198 USB Host EHCI May Stall when Running High Peak-bandwidth Demanding Use Cases" from http://www.ti.com/litv/pdf/sprz278e). Regards, Alexander -- 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
