linux-toradex.git/drivers/usb, branch v4.1.13

xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

2015-11-09T22:33:37+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

xhci: handle no ping response error properly

2015-11-09T22:33:37+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

USB: qcserial: add Sierra Wireless MC74xx/EM74xx

2015-11-09T22:33:37+00:00

commit f504ab1888026d15b5be8f9c262bf4ae9cacd177 upstream.

New device IDs shamelessly lifted from the vendor driver.

Signed-off-by: Bjørn Mork 
Acked-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: Add reset-resume quirk for two Plantronics usb headphones.

2015-10-22T21:43:23+00:00

commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 upstream.

These two headphones need a reset-resume quirk to properly resume to
original volume level.

Signed-off-by: Yao-Wen Mao 
Signed-off-by: Greg Kroah-Hartman

usb: Add device quirk for Logitech PTZ cameras

2015-10-22T21:43:23+00:00

commit 72194739f54607bbf8cfded159627a2015381557 upstream.

Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
ConferenceCam CC3000e Camera.
This fixes the failed camera enumeration on some boot, particularly on
machines with fast CPU.

Tested by connecting a Logitech PTZ Pro Camera to a machine with a
Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
while recording the kernel logs and taking camera picture after each boot.
Before the patch, more than 7% of the boots show some enumeration transfer
failures and in a few of them, the kernel is giving up before actually
enumerating the webcam. After the patch, the enumeration has been correct
on every reboot.

Signed-off-by: Vincent Palatin 
Signed-off-by: Greg Kroah-Hartman

USB: chaoskey read offset bug

2015-10-22T21:43:23+00:00

commit 1d5c47f555c5ae050fad22e4a99f88856cae5d05 upstream.

Rng reads in chaoskey driver could return the same data under
the certain conditions.

Signed-off-by: Alexander Inyukhin 
Signed-off-by: Greg Kroah-Hartman

usb: musb: cppi41: allow it to work again

2015-10-22T21:43:23+00:00

commit b0a688ddcc5015eb26000c63841db7c46cfb380a upstream.

since commit 33c300cb90a6 ("usb: musb: dsps:
don't fake of_node to musb core") we have been
preventing CPPI 4.1 from probing due to NULL
of_node. We can't revert said commit otherwise
a different regression would show up, so the fix
is to look for the parent device's (glue layer's)
of_node instead, since that's the thing which
is actually described in DTS.

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

usb: phy: phy-generic: Fix reset behaviour on legacy boot

2015-10-22T21:43:23+00:00

commit 762982db33b23029e98c844611e2e8beeb75bc0d upstream.

The gpio-desc migration done in v4.0 caused a regression
with legacy boots due to reversed reset logic.
e.g. omap3-beagle USB host breaks on legacy boot.

Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that
it matches the driver logic and pin behaviour.

Fixes: e9f2cefb0cdc ("usb: phy: generic: migrate to gpio_desc")
Tested-by: Fabio Estevam 
Signed-off-by: Roger Quadros 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: Use the USB_SS_MULT() macro to get the burst multiplier.

2015-10-22T21:43:23+00:00

commit ff30cbc8da425754e8ab96904db1d295bd034f27 upstream.

Bits 1:0 of the bmAttributes are used for the burst multiplier.
The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7
into use.

Use the existing USB_SS_MULT() macro instead to make sure the mult value
and hence max packet calculations are correct for USB3.1 devices.

Note that burst multiplier in bmAttributes is zero based and that
the USB_SS_MULT() macro adds one.

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

usb: chipidea: udc: using the correct stall implementation

2015-10-22T21:43:23+00:00

commit 56ffa1d154c7e12af16273f0cdc42690dd05caf5 upstream.

According to spec, there are functional and protocol stalls.

For functional stall, it is for bulk and interrupt endpoints,
below are cases for it:
- Host sends SET_FEATURE request for Set-Halt, the udc driver
needs to set stall, and return true unconditionally.
- The gadget driver may call usb_ep_set_halt to stall certain
endpoints, if there is a transfer in pending, the udc driver
should not set stall, and return -EAGAIN accordingly.
These two kinds of stall need to be cleared by host using CLEAR_FEATURE
request (Clear-Halt).

For protocol stall, it is for control endpoint, this stall will
be set if the control request has failed. This stall will be
cleared by next setup request (hardware will do it).

It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt"
test failure, meanwhile, this change has been verified by
USB2 CV Compliance Test and MSC Tests.

Cc: Alan Stern 
Cc: Felipe Balbi 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman