On 10/16/2015 03:29 AM, Rajmohan Mani wrote: > From: Rajmohan Mani <rajmohan.mani@xxxxxxxxx> > > Existing Intel xHCI controllers require a delay of 1 mS, > after setting the CMD_RESET bit in command register, before > accessing any HC registers. This allows the HC to complete > the reset operation and be ready for HC register access. > Without this delay, the subsequent HC register access, > may result in a system hang, very rarely. > > Verified CherryView / Braswell platforms go through over > 5000 warm reboot cycles (which was not possible without > this patch), without any xHCI reset hang. > > Signed-off-by: Rajmohan Mani <rajmohan.mani@xxxxxxxxx> > --- > drivers/usb/host/xhci.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index 9957bd9..385f9f5 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -175,6 +175,16 @@ int xhci_reset(struct xhci_hcd *xhci) > command |= CMD_RESET; > writel(command, &xhci->op_regs->command); > > + /* Existing Intel xHCI controllers require a delay of 1 mS, > + * after setting the CMD_RESET bit, and before accessing any > + * HC registers. This allows the HC to complete the > + * reset operation and be ready for HC register access. > + * Without this delay, the subsequent HC register access, > + * may result in a system hang very rarely. > + */ > + if (xhci->quirks & XHCI_INTEL_HOST) > + udelay(1000); > + > ret = xhci_handshake(&xhci->op_regs->command, > CMD_RESET, 0, 10 * 1000 * 1000); > if (ret) > -- > 1.9.1 Hi Rajmohan, Thanks for looking into this XHCI reset quirk. We ran this patch on a Stratus FT machine and it successfully reset ~1500 times over the weekend without any issue. Feel free to add: Tested-by: Joe Lawrence <joe.lawrence@xxxxxxxxxxx> -- Joe -- 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
