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

xhci: Fix list corruption in urb dequeue at host removal

2016-02-27T14:28:46+00:00

commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 upstream.

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.

Reported-by: Joe Lawrence 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

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

2016-02-27T14:28:46+00:00

commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 upstream.

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

Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

Revert "xhci: don't finish a TD if we get a short-transfer event mid TD"

2016-02-27T14:28:46+00:00

commit a6835090716a85f2297668ba593bd00e1051e662 upstream.

This reverts commit e210c422b6fd ("xhci: don't finish a TD if we get a
short transfer event mid TD")

Turns out that most host controllers do not follow the xHCI specs and never
send the second event for the last TRB in the TD if there was a short event
mid-TD.

Returning the URB directly after the first short-transfer event is far
better than never returning the URB. (class drivers usually timeout
after 30sec). For the hosts that do send the second event we will go
back to treating it as misplaced event and print an error message for it.

The origial patch was sent to stable kernels and needs to be reverted from
there as well

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xhci: refuse loading if nousb is used

2016-02-13T10:34:04+00:00

commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream.

The module should fail to load.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: xhci_hcd_init() registers the PCI driver, so
 check before doing that rather than at the end of the function]
Signed-off-by: Ben Hutchings

usb: xhci: fix config fail of FS hub behind a HS hub with MTT

2015-12-30T02:26:00+00:00

commit 096b110a3dd3c868e4610937c80d2e3f3357c1a9 upstream.

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

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

2015-12-30T02:25:59+00:00

commit f9fa1887dcf26bd346665a6ae3d3f53dec54cba1 upstream.

qset_fill_page_list() do not check for dma mapping errors.

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

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

xhci: Workaround to get Intel xHCI reset working more reliably

2015-12-30T02:25:56+00:00

commit a5964396190d0c40dd549c23848c282fffa5d1f2 upstream.

Existing Intel xHCI controllers require a delay of 1 mS,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.

Verified CherryView / Braswell platforms go through over
5000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang.

Signed-off-by: Rajmohan Mani 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xhci: Add XHCI_INTEL_HOST quirk

2015-12-30T02:25:56+00:00

Extracted from commit e3567d2c15a7 ("xhci: Add Intel U1/U2 timeout policy.")

Signed-off-by: Ben Hutchings

xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

2015-11-17T15:54:44+00:00

commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.

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]
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

xhci: Switch Intel Lynx Point LP ports to EHCI on shutdown.

2015-11-17T15:54:43+00:00

commits c09ec25d3684cad74d851c0f028a495999591279 and
0a939993bff117d3657108ca13b011fc0378aedb upstream.

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
"xhci: Fix spurious wakeups after S5 on Haswell"

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

Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown."
commit c09ec25d3684cad74d851c0f028a495999591279 is not fully correct

It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown.
On some Lynx Point machines it causes spurious interrupt,
which wake the system: bugzilla.kernel.org/show_bug.cgi?id=76291

On Lynx Point-LP on the contrary switching ports to EHCI seems to be
necessary to fix these spurious interrupts.

Signed-off-by: Denis Turischev 
Reported-by: Wulf Richartz 
Cc: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

[bwh: Combined the above commits and backported to 3.2: adjust context to
 apply after "xhci: Limit the spurious wakeup fix only to HP machines" and
 "xhci: no switching back on non-ULT Haswell"]
Signed-off-by: Ben Hutchings