• Sarah Sharp's avatar
    usb: Don't enable USB 2.0 Link PM by default. · de68bab4
    Sarah Sharp authored
    How it's supposed to work:
    --------------------------
    
    USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
    support.  USB 3.0 devices certified by the USB-IF are required to
    support it if they are plugged into a USB 2.0 only port, or a USB 2.0
    cable is used.  USB 2.0 Link PM requires both a USB device and a host
    controller that supports USB 2.0 hardware-enabled LPM.
    
    USB 2.0 Link PM is designed to be enabled once by software, and the host
    hardware handles transitions to the L1 state automatically.  The premise
    of USB 2.0 Link PM is to be able to put the device into a lower power
    link state when the bus is idle or the device NAKs USB IN transfers for
    a specified amount of time.
    
    ...but hardware is broken:
    --------------------------
    
    It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
    setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
    actually implement it correctly.  This manifests as the USB device
    refusing to respond to transfers when it is plugged into a USB 2.0 only
    port under the Haswell-ULT/Lynx Point LP xHCI host.
    
    These devices pass the xHCI driver's simple test to enable USB 2.0 Link
    PM, wait for the port to enter L1, and then bring it back into L0.  They
    only start to break when L1 entry is interleaved with transfers.
    
    Some devices then fail to respond to the next control transfer (usually
    a Set Configuration).  This results in devices never enumerating.
    
    Other mass storage devices (such as a later model Western Digital My
    Passport USB 3.0 hard drive) respond fine to going into L1 between
    control transfers.  They ACK the entry, come out of L1 when the host
    needs to send a control transfer, and respond properly to those control
    transfers.  However, when the first READ10 SCSI command is sent, the
    device NAKs the data phase while it's reading from the spinning disk.
    Eventually, the host requests to put the link into L1, and the device
    ACKs that request.  Then it never responds to the data phase of the
    READ10 command.  This results in not being able to read from the drive.
    
    Some mass storage devices (like the Corsair Survivor USB 3.0 flash
    drive) are well behaved.  They ACK the entry into L1 during control
    transfers, and when SCSI commands start coming in, they NAK the requests
    to go into L1, because they need to be at full power.
    
    Not all USB 3.0 devices advertise USB 2.0 link PM support.  My Point
    Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
    have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM.  I
    suspect that means the device isn't certified.
    
    What do we do about it?
    -----------------------
    
    There's really no good way for the kernel to test these devices.
    Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
    distros will have to enable it by writing 1 to the sysfs file
    /sys/bus/usb/devices/../power/usb2_hardware_lpm.  Rip out the xHCI Link
    PM test, since it's not sufficient to detect these buggy devices, and
    don't automatically enable LPM after the device is addressed.
    
    This patch should be backported to kernels as old as 3.11, that
    contain the commit a558ccdc "usb: xhci:
    add USB2 Link power management BESL support".  Without this fix, some
    USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
    on Haswell-ULT systems.
    Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: stable@vger.kernel.org
    de68bab4
driver.c 52.7 KB