Hi, Alan, Maybe other USB controller does not need this delay. However, our silicon errata point out, in the USBDR controller, the PORTCx[SUSP] bit changes immediately when the application sets it and not when the port is actually suspended, so the application must wait for at least 10 milliseconds after a port indicates that it is suspended to ensure the port has entered SUSPEND status before initiating this port resume using the Force Port Resume (which is one bit for NXP silicon, not-EHCI compatible). I will add more comment to understand why we need this delay in next version.
Best Regards Jerry Huang -----Original Message----- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, November 25, 2016 12:54 AM To: Sriram Dash <sriram.d...@nxp.com> Cc: Jerry Huang <jerry.hu...@nxp.com>; gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; julia.law...@lip6.fr; Ramneek Mehresh <ramneek.mehr...@nxp.com>; Suresh Gupta <suresh.gu...@nxp.com> Subject: RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 On Thu, 24 Nov 2016, Sriram Dash wrote: > >From: Changming Huang [mailto:jerry.hu...@nxp.com] As per USB > >specification, in the 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 The USB core guarantees that there won't be any data transactions in progress when a root hub is suspended. There might possibly be an SOF transaction, but that doesn't take more than a few microseconds at most. Certainly nowhere near 10 ms! Given that we already perform a 150-us delay, is this change really needed? Alan Stern
