Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757346AbcKXQxz (ORCPT ); Thu, 24 Nov 2016 11:53:55 -0500 Received: from netrider.rowland.org ([192.131.102.5]:57435 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1756864AbcKXQxy (ORCPT ); Thu, 24 Nov 2016 11:53:54 -0500 Date: Thu, 24 Nov 2016 11:53:52 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Sriram Dash cc: Jerry Huang , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "julia.lawall@lip6.fr" , Ramneek Mehresh , Suresh Gupta Subject: RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 959 Lines: 22 On Thu, 24 Nov 2016, Sriram Dash wrote: > >From: Changming Huang [mailto:jerry.huang@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