linux-toradex.git/drivers/usb/host, branch v4.4.85

usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume

2017-08-16T20:40:30+00:00

commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream.

Certain HP keyboards would keep inputting a character automatically which
is the wake-up key after S3 resume

On some AMD platforms USB host fails to respond (by holding resume-K) to
USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures
that resume is signaled for at least 20 ms (TDRSMDN), which is defined in
USB 2.0 spec. The result is that the keyboard is out of function.

In SNPS USB design, the host responds to the resume request only after
system gets back to S0 and the host gets to functional after the internal
HW restore operation that is more than 1 second after the initial resume
request from the USB device.

As a workaround for specific keyboard ID(HP Keyboards), applying port reset
after resume when the keyboard is plugged in.

Signed-off-by: Sandeep Singh 
Signed-off-by: Shyam Sundar S K 
cc: Nehal Shah 
Reviewed-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix NULL pointer dereference when cleaning up streams for removed host

2017-07-27T22:06:05+00:00

commit 4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream.

This off by one in stream_id indexing caused NULL pointer dereference and
soft lockup on machines with USB attached SCSI devices connected to a
hotpluggable xhci controller.

The code that cleans up pending URBs for dead hosts tried to dereference
a stream ring at the invalid stream_id 0.
ep->stream_info->stream_rings[0] doesn't point to a ring.

Start looping stream_id from 1 like in all the other places in the driver,
and check that the ring exists before trying to kill URBs on it.

Reported-by: rocko r 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: fix 20000ms port resume timeout

2017-07-27T22:06:05+00:00

commit a54408d0a004757789863d74e29c2297edae0b4d upstream.

A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 20000ms while waiting to get the final port event
interrupt for resume -> U0 state change.

This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.

The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.

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

usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk

2017-06-26T05:13:10+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: r8a66597-hcd: decrease timeout

2017-06-26T05:13:10+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-26T05:13:10+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-25T12:30:12+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-25T12:30:12+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-25T12:30:12+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

usb: host: xhci: print correct command ring address

2017-05-20T12:26:58+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