linux-kernel - Re: [PATCH] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Aug 2013 10:18:52 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Julius Werner <jwerner@...omium.org>
Cc:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Benson Leung <bleung@...omium.org>,
	Felipe Balbi <balbi@...com>,
	"mathias.nyman@...ux.intel.com" <mathias.nyman@...ux.intel.com>,
	Josh Triplett <josh.triplett@...el.com>
Subject: Re: [PATCH] usb: xhci-plat: Enable USB 2.0 hardware LPM support for
 platform xHCs

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/