linux-toradex.git/drivers/usb, branch v3.12.51

xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

2015-11-12T13:09:00+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: Jiri Slaby

xhci: handle no ping response error properly

2015-11-12T13:08:59+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: Jiri Slaby

Revert "USB: Add device quirk for ASUS T100 Base Station keyboard"

2015-10-28T15:38:37+00:00

This reverts commit e25ecd21ffdbf1f8287103ccf97205fc30088344 in 3.12,
upstream commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 (USB: Add
device quirk for ASUS T100 Base Station keyboard).

It was applied twice to 3.12 and one backport is bogus.

Cc: Lu Baolu 
Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

USB: Add OTG PET device to TPL

2015-10-28T15:38:37+00:00

commit e5dff0e80463cc3fa236e898ef1491b40be70b19 upstream.

OTG device shall support this device for allowing compliance automated testing.
The modification is derived from Pavankumar and Vijayavardhans' previous work.

Signed-off-by: Macpaul Lin 
Cc: Pavankumar Kondeti 
Cc: Vijayavardhan Vennapusa 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

Revert "USB: quirks: add touchscreen that is dazzeled by remote wakeup"

2015-10-28T15:38:36+00:00

commit e0e6a356a0b41375b729c511caa99d3ec019640e upstream.

This reverts commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350.
The units on this was seen were prototypes and the issue is
not seen on younger units.

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

usb: core: implement AMD remote wakeup quirk

2015-10-28T15:38:35+00:00

commit 7868943db1668fba898cf71bed1506c19d6958aa upstream.

The following patch is required to resolve remote wake issues with
certain devices.

Issue description:
If the remote wake is issued from the device in a specific timing
condition while the system is entering sleep state then it may cause
system to auto wake on subsequent sleep cycle.

Root cause:
Host controller rebroadcasts the Resume signal > 100 µseconds after
receiving the original resume event from the device. For proper
function, some devices may require the rebroadcast of resume event
within the USB spec of 100µS.

Workaroud:
1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
devices are mouse or not. And get out the port id which attached a mouse
with Pixart controller.
2. Then reset the port which attached issue device during system resume
from S3.

[Q] Why the special devices are only mice? Would high speed devices
such as 3G modem or USB Bluetooth adapter trigger this issue?
- Current this sensitivity is only confined to devices that use Pixart
  controllers. This controller is designed for use with LS mouse
devices only. We have not observed any other devices failing. There
may be a small risk for other devices also but this patch (reset
device in resume phase) will cover the cases if required.

[Q] Shouldn’t the resume signal be sent within 100 us for every
device?
- The Host controller may not send the resume signal within 100us,
  this our host controller specification change. This is why we
require the patch to prevent side effects on certain known devices.

[Q] Why would clicking mouse INTENSELY to wake the system up trigger
this issue?
- This behavior is specific to the devices that use Pixart controller.
  It is timing dependent on when the resume event is triggered during
the sleep state.

[Q] Is it a host controller issue or mouse?
- It is the host controller behavior during resume that triggers the
  device incorrect behavior on the next resume.

This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
when they attached to platforms with AMD Yangtze chipset.

Signed-off-by: Huang Rui 
Suggested-by: Alan Stern 
Acked-by: Alan Stern 
Acked-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

usb: musb: fix cppi channel teardown for isoch transfer

2015-10-28T15:38:27+00:00

commit b431ba8803666e56c1d178a421b3cbc36e8d3d33 upstream.

After a few iterations of start/stop UVC camera streaming, the streaming
stops.

This patch adds 250us delay in the cppi channel abort path to let cppi
drain properly.

Using 50us delay seems to be too aggressive, some webcams are still
broken. 250us is the original value used in TI 3.2 kernel.

Signed-off-by: Bin Liu 
Signed-off-by: Felipe Balbi 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

usb: musb: cppi41: improve rx channel abort routine

2015-10-28T15:38:26+00:00

commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 upstream.

1. set AUTOREQ to NONE at the beginning of teardown;

2. add delay for dma pipeline to drain;

3. Do not set USB_TDOWN bit for RX teardown.

  The CPPI hw has an issue that when tearing down a RX channel, if
  another RX channel is receiving data, the CPPI will lockup.

  To workaround the issue, do not set the CPPI TD bit. The steps before
  this point ensures the CPPI channel will be torn down properly.

Signed-off-by: Bin Liu 
Signed-off-by: Felipe Balbi 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

USB: symbolserial: Correct transferred data size

2015-10-28T15:38:26+00:00

commit 8ae25a355b5969e12f3185e8cb8eb08b871c9084 upstream.

The scanner (here DS3508) always returns 64 bytes per urb buffer. The first
byte indicates the data length used in the current buffer. There even was
a comment describing this. But the comment also said that we'll send
everything in the buffer to the tty layer. That means sending the actual
barcode data and lots of trailing zeroes. This patch lets the driver only
send the real data.

Signed-off-by: Philipp Hachtmann 
Acked-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

usb: chipidea: debug: add runtime pm for register access

2015-10-28T15:38:25+00:00

commit bc24937943d9f71a1e32b5dc4e2f0ef8fcc07b64 upstream.

Add runtime pm operations for registers access to avoid system hang.

Signed-off-by: Li Jun 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby