linux-stable.git/drivers/usb/host, branch v4.9.35

usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk

2017-06-24T05:11:16+00:00

commit d2f48f05cd2a2a0a708fbfa45f1a00a87660d937 upstream.

When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[106390.583860] handle_tx_event: 913 callbacks suppressed

With this patch applied, I get no more printing of this message.

Signed-off-by: Corentin Labbe 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix USB 3.1 supported protocol parsing

2017-06-24T05:11:16+00:00

commit b72eb8435b25be3a1880264cf32ac91e626ba5ba upstream.

xHCI host controllers can have both USB 3.1 and 3.0 extended speed
protocol lists. If the USB3.1 speed is parsed first and 3.0 second then
the minor revision supported will be overwritten by the 3.0 speeds and
the USB3 roothub will only show support for USB 3.0 speeds.

This was the case with a xhci controller with the supported protocol
capability listed below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed
using lsusb.

     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
  10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00     //USB 3.1
  30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00     //USB 3.0
  50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00     //USB 2.0
  70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This patch fixes the issue by only owerwriting the minor revision if
it is higher than the existing one.

[reword commit message -Mathias]
Signed-off-by: YD Tseng 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: r8a66597-hcd: decrease timeout

2017-06-24T05:11:16+00:00

commit dd14a3e9b92ac6f0918054f9e3477438760a4fa6 upstream.

The timeout for BULK packets was 300ms which is a long time if other
endpoints or devices are waiting for their turn. Changing it to 50ms
greatly increased the overall performance for multi-endpoint devices.

Fixes: 5d3043586db4 ("usb: r8a66597-hcd: host controller driver for R8A6659")
Signed-off-by: Chris Brandt 
Signed-off-by: Greg Kroah-Hartman

usb: r8a66597-hcd: select a different endpoint on timeout

2017-06-24T05:11:16+00:00

commit 1f873d857b6c2fefb4dada952674aa01bcfb92bd upstream.

If multiple endpoints on a single device have pending IN URBs and one
endpoint times out due to NAKs (perfectly legal), select a different
endpoint URB to try.
The existing code only checked to see another device address has pending
URBs and ignores other IN endpoints on the current device address. This
leads to endpoints never getting serviced if one endpoint is using NAK as
a flow control method.

Fixes: 5d3043586db4 ("usb: r8a66597-hcd: host controller driver for R8A6659")
Signed-off-by: Chris Brandt 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-mem: allocate zeroed Scratchpad Buffer

2017-05-25T13:44:39+00:00

commit 7480d912d549f414e0ce39331870899e89a5598c upstream.

According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.

	...
	The following operations take place to allocate
       	Scratchpad Buffers to the xHC:
	...
		b. Software clears the Scratchpad Buffer to '0'

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton

2017-05-25T13:44:39+00:00

commit a0c16630d35a874e82bdf2088f58ecaca1024315 upstream.

Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: propagate return value of platform_get_irq()

2017-05-25T13:44:39+00:00

commit 4b148d5144d64ee135b8924350cb0b3a7fd21150 upstream.

platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: remove GFP_DMA flag from allocation

2017-05-25T13:44:39+00:00

commit 5db851cf20857c5504b146046e97cb7781f2a743 upstream.

There is no reason to restrict allocations to the first 16MB ISA DMA
addresses.

It is causing problems in a virtualization setup with enabled IOMMU
(x86_64). The result is that USB is not working in the VM.

Signed-off-by: Matthias Lange 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

ohci-pci: add qemu quirk

2017-05-25T13:44:36+00:00

commit 21a60f6e65181cad64fd66ccc8080d413721ba27 upstream.

On a loaded virtualization host (dozen guests booting at the same time)
it may happen that the ohci controller emulation doesn't manage to do
timely frame processing, with the result that the io watchdog fires and
considers the controller being dead, even though it's only the emulation
being unusual slow due to the load peak.

So, add a quirk for qemu and don't use the watchdog in case we figure we
are running on emulated ohci.  The virtual ohci controller masquerades
as apple ohci controller, but we can identify it by subsystem id.

Signed-off-by: Gerd Hoffmann 
Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci: print correct command ring address

2017-05-20T12:28:34+00:00

commit 6fc091fb0459ade939a795bfdcaf645385b951d4 upstream.

Print correct command ring address using 'val_64'.

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman