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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux