linux-stable.git/drivers/usb/host, branch linux-3.17.y

Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"

2014-12-06T23:57:31+00:00

commit 9b41ebd3cf0f68d8cad779d3eeba336f78262e43 upstream.

commit ff8cbf250b44 ("xhci: clear root port wake on bits if controller isn't")
can cause device detection error if runtime PM is enabled, and S3 wake
is disabled. Revert it.
https://bugzilla.kernel.org/show_bug.cgi?id=85701

This commit got into stable and should be reverted from there as well.

Signed-off-by: Lu Baolu 
Reported-by: Dmitry Nezhevenko 
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: rework root port wake bits if controller isn't allowed to wakeup

2014-12-06T23:57:26+00:00

commit a1377e5397ab321e21b793ec8cd2b6f12bd3c718 upstream.

When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.

The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.

Signed-off-by: Lu Baolu 
Suggested-by: Alan Stern 
Acked-by: Alan Stern 
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: xhci: Reset a halted endpoint immediately when we encounter a stall.

2014-12-06T23:57:26+00:00

commit 8e71a322fdb127814bcba423a512914ca5bc6cf5 upstream.

If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.

Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.

Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.

Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Tested-by: Felipe Balbi 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: xhci: don't start a halted endpoint before its new dequeue is set

2014-12-06T23:57:25+00:00

commit c3492dbfa1050debf23a5b5cd2bc7514c5b37896 upstream.

A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.

As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.

Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.

Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
Tested-by: Felipe Balbi 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Disable streams on Asmedia 1042 xhci controllers

2014-11-14T18:10:36+00:00

commit 2391eacbd00b706ff4902db7dbee21e33b6f1850 upstream.

Streams seem to be broken on the Asmedia 1042. An uas capable Seagate disk
which is known to work fine with other controllers causes the system to freeze
when connected over usb-3 with this controller, where as it works fine with
uas in usb-2 ports, indicating a problem with streams.

This is a bit bigger hammer then I would like to use for this, but for now it
will have to make do. I've ordered a pci-e usb controller card with an Asmedia
1042, once that arrives I'll try to get streams to work (with a quirk flag if
necessary) and then we can re-enable them. For now this at least makes uas
capable disk enclosures work again by forcing fallback to the usb-storage
driver.

Reported-by: Bogdan Mihalcea 
Cc: Bogdan Mihalcea 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

xhci: no switching back on non-ULT Haswell

2014-11-14T18:10:36+00:00

commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream.

The switch back is limited to ULT even on HP. The contrary
finding arose by bad luck in BIOS versions for testing.
This fixes spontaneous resume from S3 on some HP laptops.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

usb: Remove references to non-existent PLAT_S5P symbol

2014-11-14T18:10:35+00:00

commit cd6e245a2d061a8367e37aaece32cf3fc922de80 upstream.

The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). There are still
some references left, fix that by replacing them with ARCH_S5PV210.

Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
Reported-by: Paul Bolle 
Acked-by: Jingoo Han 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: unlink QHs even after the controller has stopped

2014-09-19T21:59:17+00:00

Old code in ehci-hcd tries to expedite disabling endpoints after the
controller has stopped, by destroying the endpoint's associated QH
without first unlinking the QH.  This was necessary back when the
driver wasn't so careful about keeping track of the controller's
state.

But now we are careful about it, and the driver knows that when the
controller isn't running, no unlinking delay is needed.  Furthermore,
skipping the unlink step will trigger a BUG() in qh_destroy() when the
preceding QH is released, because the link pointer will be non-NULL.

Removing the lines that skip the unlinking step and go directly to
QH_STATE_IDLE fixes the problem.

Signed-off-by: Alan Stern 
Reported-by: Joe Lawrence 
Tested-by: Joe Lawrence 
CC: 
Signed-off-by: Greg Kroah-Hartman

xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices

2014-09-11T21:23:52+00:00

Resuming from hibernate (S4) will restart and re-initialize xHC.
The device contexts are freed and will be re-allocated later during device reset.

Usb core will disable link pm in device resume before device reset, which will
try to change the max exit latency, accessing the device contexts before they are re-allocated.

There is no need to zero (disable) the max exit latency when disabling hw lpm
for a freshly re-initialized xHC. So check that device context exists before
doing anything. The max exit latency will be set again after device reset when usb core
enables the link pm.

Reported-by: Imre Deak 
Tested-by: Imre Deak 
Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix OOPS in xhci error handling code

2014-09-11T21:23:52+00:00

The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent()
is out of memory. This is a result of two things:
1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if
it's not NULL, but doesn't set it to NULL after the free.
2. xhci_mem_cleanup() is called twice on resume, once for normal
restart and once from xhci_mem_init() if dma_alloc_coherent() fails,
resulting in a free of xhci->lpm_command that has already been freed.
The fix is to set xhci->lpm_command to NULL after freeing it.

Signed-off-by: Al Cooper 
Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman