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

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

xhci: handle no ping response error properly

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

commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.

If a host fails to wake up a isochronous SuperSpeed device from U1/U2
in time for a isoch transfer it will generate a "No ping response error"
Host will then move to the next transfer descriptor.

Handle this case in the same way as missed service errors, tag the
current TD as skipped and handle it on the next transfer event.

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

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

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

commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream.

If the difference is big enough between the bytes asked and received
in a bulk transfer we can get a short transfer event pointing to a TRB in
the middle of the TD. We don't want to handle the TD yet as we will anyway
receive a new event for the last TRB in the TD.

Hold off from finishing the TD and removing it from the list until we
receive an event for the last TRB in the TD

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

xhci: change xhci 1.0 only restrictions to support xhci 1.1

2015-10-13T02:46:10+00:00

commit dca7794539eff04b786fb6907186989e5eaaa9c2 upstream.

Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
check the hci version in code, some of these checks were implemented as
hci_version == 1.0, which will not work with new xhci 1.1 controllers.

xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
checks to hci_version >= 1.0

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

usb: xhci: Clear XHCI_STATE_DYING on start

2015-10-13T02:46:10+00:00

commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 upstream.

For whatever reason if XHCI died in the previous instant
then it will never recover on the next xhci_start unless we
clear the DYING flag.

Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings