-----Original Message----- From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] Sent: Thursday, September 19, 2013 7:03 PM To: Mehresh Ramneek-B31383 Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: [PATCH]fsl/usb: Workarourd for USB erratum-A005697 On Thu, 19 Sep 2013, Ramneek Mehresh wrote: > As per USB specification, in Suspend state the status bit does not > change until the port is suspended. However, there may be a delay in > suspending a port if there is a transaction currently in progress on > the bus. > > In the USBDR controller, the PORTSCx[SUSP] bit changes immediately > when the application sets it and not when the port is actually > suspended > > Workaround for this issue involves waiting for a minimum of 10ms to > allow the controller to go into SUSPEND state before proceeding ahead Why is this workaround needed? Does anything go wrong if it isn't applied? [Ramneek]: This workaround is needed because we have this issue with the controller. In some protocols like HNP, a notification needs to be sent to another OTG device as soon as current controller port goes into SUSPEND state. However, this notification could be false if the port is still transmitting some data and the controller informs system s/w that the port is already in suspend state. > --- a/drivers/usb/host/ehci-hub.c > +++ b/drivers/usb/host/ehci-hub.c > @@ -284,6 +284,8 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) > else if ((t1 & PORT_PE) && !(t1 & PORT_SUSPEND)) { > t2 |= PORT_SUSPEND; > set_bit(port, &ehci->bus_suspended); > + if (ehci_has_fsl_susp_errata(ehci)) > + usleep_range(10000, 20000); > } Notice that there's no delay here for other controller types. Why does USBDR need a delay? [Ramneek] USBDR has this issue where it sets SUSPEND status bit even before it is in SUSPEND state. It has been guaranteed that the port will definitely go into SUSPEND state in 10ms. 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
