From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Julius Werner <jwerner@chromium.org>
Cc: Paul Zimmerman <Paul.Zimmerman@synopsys.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vincent Palatin <vpalatin@chromium.org>,
Benson Leung <bleung@chromium.org>, Felipe Balbi <balbi@ti.com>,
"mathias.nyman@linux.intel.com" <mathias.nyman@linux.intel.com>,
Josh Triplett <josh.triplett@intel.com>
Subject: Re: [PATCH] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs
Date: Thu, 29 Aug 2013 10:18:52 -0700 [thread overview]
Message-ID: <20130829171852.GB5538@xanatos> (raw)
In-Reply-To: <CAODwPW_nPvS3Y9J2J9nU49uuDSB0kVirnKTF7HejfcYJEhgsUw@mail.gmail.com>
On Wed, Aug 28, 2013 at 04:08:12PM -0700, Julius Werner wrote:
> > So the 2.41a has BESL support, but may not set the BLC flag. What
> > happens if we use the HIRD encoding instead? Will things break? It
> > seems like we would need to disable USB 2.0 LPM on that host all
> > together, if it expects BESL encoding, but advertises HIRD encoding.
>
> Wait a second, just for clarity: are you saying that BESL-capable
> controllers do not support the old HIRD mechanism and thus just break
> on non-BESL aware OSes?
Yes.
> I would've assumed that they somehow notice if software doesn't write
> to the new register and automatically fall back to HIRD... it seems
> like a weird decision to break hardware backwards compatibility like
> that (after all, it would mean that Linux 3.10 and older would also
> break on LynxPoint systems right now).
Let me dig this older state out of my brain. ISTR yelling at the xHCI
spec architect for breaking hosts for this very reason (originally the
BLC flag was not in the spec at all)...
If a host supports the HIRD encoding, it sets Hardware LMP Capability
(HLC), bit 19, in the USB 2.0 port protocol register. That bit is set
whether the host supports HIRD or BESL encoding. Bit 20 (BLC) is set if
the host supports BESL.
When the driver goes to write a value in the USB2 Port Hardware LPM
Control Register, if the driver is only aware of the HIRD
specifications, it will use the HIRD encodings in bits 13:10, regardless
of whether the host has BESL support instead of HIRD support. If the
driver has support for BESL and the host has BESL support, it will use
the BESL encodings in those bits instead. If you take a look at Table
13: BESL/HIRD Encoding from the xHCI spec version including errata to
08/14/2012, you'll see the numbers written into bits 13:10 mean
different timeouts, based on whether the host supports HIRD or BESL.
So, basically, if the xHCI driver only supports HIRD and is loaded on a
host that supports BESL, then the driver will write a timeout value in
bits 13:10 that means something different than what the driver thinks it
means. This could lead to issues with USB 2.0 devices that support Link
PM.
Yes, this is broken. Distros that want to run on hosts that have BESL
support need to have the BESL patches from Mathias.
Sarah Sharp
next prev parent reply other threads:[~2013-08-29 17:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-20 23:21 [PATCH] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs Julius Werner
2013-08-21 18:40 ` Sarah Sharp
2013-08-21 21:43 ` Julius Werner
2013-08-22 0:45 ` Sarah Sharp
2013-08-22 2:12 ` Greg Kroah-Hartman
2013-08-22 4:22 ` Julius Werner
2013-08-22 5:11 ` Paul Zimmerman
2013-08-26 19:14 ` Sarah Sharp
2013-08-26 19:37 ` Paul Zimmerman
2013-08-26 19:53 ` Paul Zimmerman
2013-08-28 21:51 ` Sarah Sharp
2013-08-28 22:15 ` Paul Zimmerman
2013-08-28 23:08 ` Julius Werner
2013-08-29 17:18 ` Sarah Sharp [this message]
2013-08-29 18:06 ` Julius Werner
2013-08-29 18:40 ` Paul Zimmerman
2013-11-06 20:33 ` Julius Werner
2013-12-02 21:50 ` Julius Werner
2013-08-29 17:42 ` Sarah Sharp
2013-08-29 18:11 ` Paul Zimmerman
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=20130829171852.GB5538@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=Paul.Zimmerman@synopsys.com \
--cc=balbi@ti.com \
--cc=bleung@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=josh.triplett@intel.com \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=vpalatin@chromium.org \
/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