linux-stable.git/drivers/usb, branch v3.18.25

usb: musb: fix cppi channel teardown for isoch transfer

2015-12-03T04:24:46+00:00

[ Upstream commit b431ba8803666e56c1d178a421b3cbc36e8d3d33 ]

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 
Signed-off-by: Sasha Levin

usb: musb: cppi41: improve rx channel abort routine

2015-12-03T04:24:30+00:00

[ Upstream commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 ]

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 
Signed-off-by: Sasha Levin

USB: symbolserial: Correct transferred data size

2015-12-03T04:24:15+00:00

[ Upstream commit 8ae25a355b5969e12f3185e8cb8eb08b871c9084 ]

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 
Signed-off-by: Sasha Levin

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

2015-12-03T04:23:59+00:00

[ Upstream commit bc24937943d9f71a1e32b5dc4e2f0ef8fcc07b64 ]

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

Signed-off-by: Li Jun 
Signed-off-by: Sasha Levin

USB: usbtmc: add device quirk for Rigol DS6104

2015-12-03T03:58:22+00:00

[ Upstream commit f50420223071b6ff4b586308f5c27eec54694a81 ]

Recently we purchased the Rigol DS6104 and when I try to operate it from
my Linux pc, everything works well with the default usbtmc driver,
except when I want to download a big datachunk like a screenshot. This
bitmapfile has a size of 1152054 bytes but I receive a smaller file and
no new packets can be read.

When I took a look at the driver source, I found this "Rigol quirk" and
I added the id of the new DS series oscilloscopes to this list. I
compiled it and loaded the new driver and now everything seems to work
fine.

Signed-off-by: Teunis van Beelen 
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

xhci: handle no ping response error properly

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

[ Upstream commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 ]

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.

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

usb: host: ehci-sys: delete useless bus_to_hcd conversion

2015-10-28T02:14:42+00:00

[ Upstream commit 0521cfd06e1ebcd575e7ae36aab068b38df23850 ]

The ehci platform device's drvdata is the pointer of struct usb_hcd
already, so we doesn't need to call bus_to_hcd conversion again.

Cc: 
Signed-off-by: Peter Chen 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes

2015-10-28T02:14:42+00:00

[ Upstream commit b2fb5b1a0f50d3ebc12342c8d8dead245e9c9d4e ]

DWC3 uses bounce buffer to handle non max packet aligned OUT transfers and
the size of bounce buffer is 512 bytes. However if the host initiates OUT
transfers of size more than 512 bytes (and non max packet aligned), the
driver throws a WARN dump but still programs the TRB to receive more than
512 bytes. This will cause bounce buffer to overflow and corrupt the
adjacent memory locations which can be fatal.

Fix it by programming the TRB to receive a maximum of DWC3_EP0_BOUNCE_SIZE
(512) bytes.

Cc:  # 3.4+
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

USB: ftdi_sio: Added custom PID for CustomWare products

2015-10-28T02:14:41+00:00

[ Upstream commit 1fb8dc36384ae1140ee6ccc470de74397606a9d5 ]

CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
products.

Signed-off-by: Matthijs Kooijman 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin