linux-stable.git/drivers/usb, branch linux-3.13.y

tty: Fix low_latency BUG

2014-04-22T23:49:20+00:00

commit a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream.

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

"Yay.. thats an annoying historical pain in the butt gone."
	-- Alan Cox

Reported-by: Beat Bolli 
Reported-by: Pavel Roskin 
Acked-by: David Sterba 
Cc: Grant Edwards 
Cc: Stanislaw Gruszka 
Cc: Hal Murray 
Signed-off-by: Peter Hurley 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix resume issues on Renesas chips in Samsung laptops

2014-03-31T17:05:16+00:00

commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.

Don Zickus  writes:

Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail).  This led to frustration as suspend/resume is a common use for
laptops.

Poking around, I applied the reset on resume quirk to this chipset and the
resume started working.  Reloading the xhci_hcd module had been the temporary
workaround.

Signed-off-by: Sarah Sharp 
Reported-by: Don Zickus 
Tested-by: Prarit Bhargava 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."

2014-03-24T04:44:09+00:00

commit e2ed511400d41e0d136089d5a55ceab57c6a2426 upstream.

This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304.

This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.

USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.

The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.

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

usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests

2014-03-24T04:44:08+00:00

commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream.

The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.

Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman

usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e

2014-03-24T04:44:08+00:00

commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream.

We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.

Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman

USB: ftdi_sio: add Cressi Leonardo PID

2014-03-07T06:06:24+00:00

commit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream.

Hello,

the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.

Signed-off-by: Joerg Dorchain 
Signed-off-by: Greg Kroah-Hartman

usb: ehci: fix deadlock when threadirqs option is used

2014-03-07T06:06:24+00:00

commit a1227f3c1030e96ebc51d677d2f636268845c5fb upstream.

ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().

This change can be reverted when hrtimer callbacks become threaded.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: add delay during suspend to prevent erroneous wakeups

2014-03-07T06:06:24+00:00

commit 3e8d6d85adedc59115a564c0a54b36e42087c4d9 upstream.

High-speed USB connections revert back to full-speed signalling when
the device goes into suspend.  This takes several milliseconds, and
during that time it's not possible to tell reliably whether the device
has been disconnected.

On some platforms, the Wake-On-Disconnect circuitry gets confused
during this intermediate state.  It generates a false wakeup signal,
which can prevent the controller from going to sleep.

To avoid this problem, this patch adds a 5-ms delay to the
ehci_bus_suspend() routine if any ports have to switch over to
full-speed signalling.  (Actually, the delay was already present for
devices using a particular kind of PHY power management; the patch
merely causes the delay to be used more widely.)

Signed-off-by: Alan Stern 
Reviewed-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8

2014-03-07T06:06:24+00:00

commit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream.

This interface is to be handled by the qmi_wwan driver.

CC: Hans-Christoph Schemmel 
CC: Christian Schmiedl 
CC: Nicolaus Colberg 
CC: David McCullough 
Signed-off-by: Aleksander Morgado 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: bcm63xx_udc: fix build failure on DMA channel code

2014-03-07T06:06:24+00:00

commit 2d1f7af3d60dd09794e0738a915d272c6c27abc5 upstream.

Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
changed the ENETDMA[CS] macros such that they are no longer macros, but
actual register offset definitions. The bcm63xx_udc driver was not
updated, and as a result, causes the following build error to pop up:

 CC      drivers/usb/gadget/u_ether.o
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
a function

Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
take an extra channel argument, and use the channel width
(ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
doing again what the macro implicitely did for us.

Cc: Kevin Cernekee 
Cc: Jonas Gorski 
Signed-off-by: Florian Fainelli 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman