user/sven/linux.git/drivers/usb, branch v3.12.19

tty: Fix low_latency BUG

2014-05-05T12:24:38Z

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: Jiri Slaby

usbatm: Fix dynamic_debug / ratelimited atm_dbg and atm_rldbg macros

2014-05-05T09:15:36Z

commit 32e24930fb71c47a1366325b6f139e039cacaca4 upstream. Fix atm_dbg to use normal pr_debug not dynamic_pr_debug because dynamic_pr_debug may not be compiled in at all. Signed-off-by: Joe Perches Tested-by: Krzysztof Mazur Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

xhci: Fix resume issues on Renesas chips in Samsung laptops

2014-03-31T12:22:34Z

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: Jiri Slaby

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

2014-03-22T21:01:55Z

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: Jiri Slaby

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

2014-03-22T21:01:54Z

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: Jiri Slaby

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

2014-03-22T21:01:54Z

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: Jiri Slaby

usb: ohci: use amd_chipset_type to filter for SB800 prefetch

2014-03-12T12:25:33Z

commit 02c123ee99c793f65af2dbda17d5fe87d448f808 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates SB800 prefetch routine in AMD PLL quirk. And make it use the new chipset type to represent SB800 generation. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2 Signed-off-by: Huang Rui Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

usb: ehci: use amd_chipset_type to filter for usb subsystem hang bug

2014-03-12T12:25:32Z

commit 3ad145b62a15c86150dd0cc229a39a3120d462f9 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates USB subsystem hang symptom quirk which is observed on AMD all SB600 and SB700 revision 0x3a/0x3b. And make it use the new chipset type to represent. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2 Signed-off-by: Huang Rui Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types

2014-03-12T12:25:32Z

commit 22b4f0cd1d4d98f50213e9a37ead654e80b54b9d upstream. This patch abstracts out a AMD chipset type which includes southbridge generation and its revision. When os excutes usb_amd_find_chipset_info routine to initialize AMD chipset type, driver will know which kind of chipset is used. This update has below benifits: - Driver is able to confirm which southbridge generations and their revision are used, with chipset detection once. - To describe chipset generations with enumeration types brings better readability. - It's flexible to filter AMD platforms to implement new quirks in future. Signed-off-by: Huang Rui Cc: Andiry Xu Acked-by: Alan Stern Acked-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

USB: ftdi_sio: add Cressi Leonardo PID

2014-03-05T16:13:49Z

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: Jiri Slaby