From: Thierry Reding <thierry.reding@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Stephen Warren <swarren@wwwdotorg.org>,
Alexandre Courbot <gnurou@gmail.com>,
Jon Hunter <jonathanh@nvidia.com>,
linux-usb@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org,
Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Subject: Re: [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset
Date: Wed, 4 May 2016 17:26:48 +0200 [thread overview]
Message-ID: <20160504152648.GA31420@ulmo.ba.sec> (raw)
In-Reply-To: <20160504145710.GA14708@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]
On Wed, May 04, 2016 at 07:57:10AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 04, 2016 at 04:39:59PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > 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 <treding@nvidia.com>
>
> Any reason you don't want this backported to stable kernels?
There's a brief note below the commit message that explains why I'm not
sure if there's a need to backport:
> 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.
So the bottom line is that I have no evidence that this fixes any real
issue, hence I'm not sure if it's worth bothering the stable kernel
maintainers with it.
While at it, adding Tuomas who wrote the original probe order fix.
Tuomas, does this patch look correct to you? Here's the patch in full if
you don't have it in your inbox:
http://patchwork.ozlabs.org/patch/618488/
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-05-04 15:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 14:39 [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset Thierry Reding
2016-05-04 14:40 ` [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice Thierry Reding
2016-05-04 17:22 ` Philipp Zabel
2016-05-04 20:16 ` Thierry Reding
2016-05-04 17:23 ` Stephen Warren
2016-05-04 20:25 ` Thierry Reding
2016-05-05 8:05 ` Hans de Goede
2016-05-05 16:00 ` Stephen Warren
2016-05-05 17:12 ` Hans de Goede
2016-05-05 17:05 ` Jon Hunter
2016-05-05 17:10 ` Jon Hunter
2016-05-04 14:57 ` [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset Greg Kroah-Hartman
2016-05-04 15:26 ` Thierry Reding [this message]
2016-05-05 16:05 ` Tuomas Tynkkynen
2016-05-04 17:14 ` Stephen Warren
2016-05-04 20:30 ` Thierry Reding
2016-05-05 7:39 ` Jon Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160504152648.GA31420@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=gnurou@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=swarren@wwwdotorg.org \
--cc=tuomas.tynkkynen@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox