From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754627AbcEDROz (ORCPT ); Wed, 4 May 2016 13:14:55 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:52460 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752827AbcEDROx (ORCPT ); Wed, 4 May 2016 13:14:53 -0400 Subject: Re: [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset To: Thierry Reding References: <1462372800-30900-1-git-send-email-thierry.reding@gmail.com> Cc: Alan Stern , Greg Kroah-Hartman , Alexandre Courbot , Jon Hunter , linux-usb@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org From: Stephen Warren Message-ID: <572A2E0A.8040408@wwwdotorg.org> Date: Wed, 4 May 2016 11:14:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1462372800-30900-1-git-send-email-thierry.reding@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2016 08:39 AM, Thierry Reding wrote: > From: Thierry Reding > > There are three EHCI controllers on Tegra SoCs, each with its own reset > line. However, the first controller contains a set of UTMI configuration > registers that are shared with its siblings. These registers will only > be reset as part of the first controller's reset. For proper operation > it must be ensured that the UTMI configuration registers are reset > before any of the EHCI controllers are enabled, irrespective of the > probe order. > > Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to > broken USB") introduced code that ensures the first controller is always > reset before setting up any of the controllers, and is never again reset > afterwards. > > This code, however, grabs the wrong reset. Each EHCI controller has two > reset controls attached: 1) the USB controller reset and 2) the UTMI > pads reset (really the first controller's reset). In order to reset the > UTMI pads registers the code must grab the second reset, but instead it > grabbing the first. > > Signed-off-by: Thierry Reding > --- > Stephen, Alex, Jon, have you ever encountered cases where UTMI might not > have worked correctly? It seems that this code was pulsing the wrong > reset line and therefore the UTMI pads would never be reset unless the > first USB controller was probed before all others. I've never seen any > such problems myself, so I'm unsure about whether it's worth Cc'ing the > patch to stable@vger.kernel.org. I don't think I recall seeing USB issues like that, although I don't use USB a huge amount. Perhaps the issue just never happens because we always have USB1 enabled, and it's physically present in the DTB first, so it always happens to get probed first?