linux-stable.git/drivers/usb/host, branch v3.10.85

usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function

2015-08-03T16:29:45+00:00

commit 3496810663922617d4b706ef2780c279252ddd6a upstream.

virt_dev->num_cached_rings counts on freed ring and is not updated
correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
is added into cache and then num_rings_cache is incremented as below:
		virt_dev->ring_cache[rings_cached] =
			virt_dev->eps[ep_index].ring;
		virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, current index should be decremented
first and then corresponding ring buffer value should be taken from ring
cache.

But In function xhci_endpoint_init(), the num_rings_cached index is
accessed before decrement.
		virt_dev->eps[ep_index].new_ring =
			virt_dev->ring_cache[virt_dev->num_rings_cached];
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
		virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
		virt_dev->num_rings_cached--;
		virt_dev->eps[ep_index].new_ring =
			virt_dev->ring_cache[virt_dev->num_rings_cached];
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

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

xhci: gracefully handle xhci_irq dead device

2015-06-06T06:19:56+00:00

commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream.

If the xHCI host controller has died (ie, device removed) or suffered
other serious fatal error (STS_FATAL), then xhci_irq should handle this
condition with IRQ_HANDLED instead of -ESHUTDOWN.

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

xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256

2015-06-06T06:19:56+00:00

commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.

Our event ring consists of only one segment, and we risk filling
the event ring in case we get isoc transfers with short intervals
such as webcams that fill a TD every microframe (125us)

With 64 TRB segment size one usb camera could fill the event ring in 8ms.
A setup with several cameras and other devices can fill up the
event ring as it is shared between all devices.
This has occurred when uvcvideo queues 5 * 32TD URBs which then
get cancelled when the video mode changes. The cancelled URBs are returned
in the xhci interrupt context and blocks the interrupt handler from
handling the new events.

A full event ring will block xhci from scheduling traffic and affect all
devices conneted to the xhci, will see errors such as Missed Service
Intervals for isoc devices, and  and Split transaction errors for LS/FS
interrupt devices.

Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring
size, which is welcome as for most isoc transfer we had to dynamically
expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo
queues.

The default size used to be 64 TRBs per segment

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

xhci: fix isoc endpoint dequeue from advancing too far on transaction error

2015-06-06T06:19:55+00:00

commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream.

Isoc TDs usually consist of one TRB, sometimes two. When all goes well we
receive only one success event for a TD, and move the dequeue pointer to
the next TD.

This fails if the TD consists of two TRBs and we get a transfer error
on the first TRB, we will then see two events for that TD.

Fix this by making sure the event we get is for the last TRB in that TD
before moving the dequeue pointer to the next TD. This will resolve some
of the uvc and dvb issues with the
"ERROR Transfer event TRB DMA ptr not part of current TD" error message

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

usb: host: oxu210hp: use new USB_RESUME_TIMEOUT

2015-05-13T12:15:42+00:00

commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: host: sl811: use new USB_RESUME_TIMEOUT

2015-05-06T19:56:23+00:00

commit 08debfb13b199716da6153940c31968c556b195d upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci: use new USB_RESUME_TIMEOUT

2015-05-06T19:56:23+00:00

commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Acked-by: Mathias Nyman 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: host: isp116x: use new USB_RESUME_TIMEOUT

2015-05-06T19:56:23+00:00

commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: host: r8a66597: use new USB_RESUME_TIMEOUT

2015-05-06T19:56:22+00:00

commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 upstream.

While this driver was already using a 50ms resume
timeout, let's make sure everybody uses the same
macro so it's easy to fix later should anything
go wrong.

It also gives a more "stable" expectation to Linux
users.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-04-19T08:10:49+00:00

commit 227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d upstream.

When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.

However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set,  an "Event Ring is Full" event
will be posted to the last entry of the event ring,  but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring.  That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.

This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").

Signed-off-by: Lu Baolu 
Tested-by: Alistair Grant 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman