lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri,  4 Mar 2016 10:23:05 -0800
From:	Douglas Anderson <dianders@...omium.org>
To:	johnyoun@...opsys.com, balbi@...nel.org,
	Heiko Stuebner <heiko@...ech.de>
Cc:	linux@...ewoehner.de, caesar.upstream@...il.com,
	huangtao@...k-chips.com, repk@...plefau.lt, stefan.wahren@...e.com,
	Julius Werner <jwerner@...omium.org>,
	Douglas Anderson <dianders@...omium.org>,
	gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

>From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent.  Let's add it.

In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
could never reproduce the problems on my board, this might also allow us
to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
dr_mode").

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---
 drivers/usb/dwc2/core.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 5e5a0f135b5a..8710b2d3e770 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 		}
 	} while (!(greset & GRSTCTL_AHBIDLE));
 
+	/*
+	 * Sleep for 10-15 ms after the reset to let it finish.
+	 *
+	 * It's been confirmed on at least one version of the controller
+	 * that this is a requirement that this is a requirement in order for
+	 * everything to settle.  Specifically if you:
+	 * - change GNPTXFSIZ or HPTXFSIZ before the reset
+	 * - do the reset
+	 * - read GNPTXFSIZ or HPTXFSIZ in a loop
+	 * ...you'll find that it takes almost exactly 10 ms for the registers
+	 * to return to their reset defaults.
+	 *
+	 * Note that it's possible that this 10 ms is the time referred to
+	 * in "Host Initialization" where it says to "Wait at least 10 ms for
+	 * the reset process to complete".  In "Device Initialization" there
+	 * is also talk of a reset lasting 10 ms.  That may be the source of
+	 * this delay.
+	 */
+	usleep_range(10000, 15000);
+
 	return 0;
 }
 
-- 
2.7.0.rc3.207.g0ac5344

Powered by blists - more mailing lists