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

xhci: Fix list corruption in urb dequeue at host removal

2016-02-15T20:42:39+00:00

[ Upstream commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 ]

xhci driver frees data for all devices, both usb2 and and usb3 the
first time usb_remove_hcd() is called, including td_list and and xhci_ring
structures.

When usb_remove_hcd() is called a second time for the second xhci bus it
will try to dequeue all pending urbs, and touches td_list which is already
freed for that endpoint.

Cc: 
Reported-by: Joe Lawrence 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms

2016-02-15T20:42:39+00:00

[ Upstream commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 ]

Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.

Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: set SSIC port unused only if xhci_suspend succeeds

2016-02-15T20:42:39+00:00

[ Upstream commit 92149c930cce1865d0d4aca2ab07c2b4b197b418 ]

XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers
in some Intel SoC chips.  With this quirk applied, SSIC port is set
to "unused" prior to xhci_suspend(). This may cause problem if host
fails to suspend.  In this case, the port is set to unused without
host further entering D3, and the port will not be usable anymore.

Cc: stable@vger.kernel.org
Signed-off-by: Zhuang Jin Can 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: add a quirk bit for ssic port unused

2016-02-15T20:42:39+00:00

[ Upstream commit 7e70cbffe236721051bbaff965e477df06dcb190 ]

Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround
for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci:
Workaround to get D3 working in Intel xHCI") share a single quirk bit
XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and
might happen on different hardwares. Need to separate them by adding a
quirk bit for the later.

Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: handle both SSIC ports in PME stuck quirk

2016-02-15T20:42:39+00:00

[ Upstream commit fa89537783cb442263fa5a14df6c7693eaf32f11 ]

Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI")
adds a workaround for a limitation of PME storm caused by SSIC port in
some Intel SoCs. This commit only handled one SSIC port, while there
are actually two SSIC ports in the chips. This patch handles both SSIC
ports. Without this fix, users still see PME storm.

Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Zhuang Jin Can 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM

2016-02-15T20:42:39+00:00

commit 2b7627b73e81e5d23d5ae1490fe8e690af86e053 upstream.

xhci_pme_quirk() is only used when CONFIG_PM is defined.
Compiling a kernel without PM complains about this function

[reworded commit message -Mathias]
Signed-off-by: Tomer Barletz 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Workaround to get D3 working in Intel xHCI

2016-02-15T20:42:39+00:00

[ Upstream commit abce329c27b315cfc01be1a305ee976ee13ed4cf ]

The xHCI in Intel CherryView / Braswell Platform requires
a driver workaround to get xHCI D3 working. Without this
workaround, xHCI might not enter D3.

Workaround is to configure SSIC PORT as "unused" before D3
entry and "used" after D3 exit. This is done through a
vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset
0x883c), in xhci suspend / resume callbacks.

Verified xHCI D3 works fine in CherryView / Braswell platform.

Signed-off-by: Rajmohan Mani 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: call BIOS workaround to enable runtime suspend on Intel Braswell

2016-02-15T20:42:38+00:00

[ Upstream commit c3c5819a350952439c3198aa46581f9e4c46557f ]

Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled
xhci from going to D3 state in runtime suspend. Driver needs to verify
it can deal with the hw by calling an ACPI _DSM method to get D3 enabled.

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

USB: whci-hcd: add check for dma mapping error

2016-01-22T17:24:45+00:00

[ Upstream commit f9fa1887dcf26bd346665a6ae3d3f53dec54cba1 ]

qset_fill_page_list() do not check for dma mapping errors.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

2015-11-15T17:51:51+00:00

[ Upstream commit fd7cd061adcf5f7503515ba52b6a724642a839c8 ]

We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.

Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:

commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.

Signed-off-by: Laura Abbott 
Cc: Takashi Iwai 
Cc: Oliver Neukum 
[Added more history to commit message -Mathias]
Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Sasha Levin