summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2018-06-04tty: serial: fsl_lpuart: lock port on console writetoradex_vf_4.1-nextStefan Agner
The console write code is not entirely race free (e.g. the operations to disabling the UART interrupts are not atomic) hence locking is required. This has been become apparent with the PREEMPT RT patchset applied: With the fully preemptible kernel configuration the system often ended up in a freeze already at startup. Disable interrupts and lock using read_lock_irqsave. Try to lock in the sysrq/oops case, but don't bother if locking fails. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2018-06-04tty: serial: fsl_lpuart: fix del_timer_sync() vs timer routine deadlockNikita Yushchenko
Problem found via lockdep: - lpuart_set_termios() calls del_timer_sync(&sport->lpuart_timer) while holding sport->port.lock - sport->lpuart_timer routine is lpuart_timer_func() that calls lpuart_copy_rx_to_tty() that acquires same lock. To fix, move Rx DMA stopping out of lock, as it already is in other places in the same file. While at it, also make Rx DMA start/stop code to look the same is in other places in the same file. Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Tested-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 54a44d54be3a7394ebea42bbffd67819e0f3f89a)
2018-05-30tty: serial: fsl_lpuart: Fix Tx DMA edge caseAaron Brice
In the case where head == 0 on the circular buffer, there should be one DMA buffer, not two. The second zero-length buffer would break the lpuart driver, transfer would never complete. Signed-off-by: Aaron Brice <aaron.brice@datasoft.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15Merge tag 'v4.1.39' into toradex_vf_4.1-nexttoradex_vf_4.1Stefan Agner
Linux 4.1.39
2017-03-15tty: serial: fsl_lpuart: resync with 4.9 kernelBhuvanchandra DV
This commit resyncs the driver changes with 4.9 kernel version of the driver. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15Merge tag 'v4.1.32' into toradex_vf_4.1-nextStefan Agner
Linux 4.1.32
2017-03-15Merge tag 'v4.1.24' into toradex_vf_4.1-nextStefan Agner
Linux 4.1.24
2017-03-15tty: serial: fsl_lpuart: enable UART DMA by defaultStefan Agner
The new DMA implementation uses larger buffer sizes and avoids overflows in most situations. Enable DMA by default again. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
2017-03-15tty: serial: fsl_lpuart: Fix broken 8m/s1 supportBhuvanchandra DV
Fix broken 8m/s1 support. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15tty: serial: fsl-lpuart: Update suspend/resume for DMA modeBhuvanchandra DV
When DMA mode is enabled one need to make sure the DMA channels are idle before entering suspend mode especially when UART ports which are set as wakeup source and console port with no_console_suspend is set. This patch takes care of gracefully releasing DMA channels for the above two cases and start the DMA at resume. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15tty: serial: fsl-lpuart: Use scatter/gather DMA for TxBhuvanchandra DV
Drop PIO to DMA switching and use scatter/gather DMA for Tx path to improve performance. Some part of the code is borrowed from imx serial driver. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15tty: serial: fsl-lpuart: Use cyclic DMA for RxBhuvanchandra DV
The initial approach of DMA implementatin for RX is inefficient due to switching from PIO to DMA, this leads some times to overrun on lpuart ports with small FIFO. To address these issues this patch uses a cyclic DMA for receiver path. Some part of the code is borrowed from atmel serial driver. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> [updated DMA RX buffer size calculation] Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15Revert "tty: serial: fsl_lpuart: avoid TX FIFO overflow"Stefan Agner
This reverts commit ff81e6ebb2df8a12f95dfa77eb0f4540e8b1e217. Cleanup before backporting the better solution from the 4.4 kernel. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
2017-03-15pinctrl: freescale: imx: implement gpio_disable_free for VybridStefan Agner
The Freescale Vybrid SoC has GPIO capabilities as part of the IOMUXC. To enable GPIO's, the gpio_request_enable callback has been implemented, however the corresponding gpio_disable_free callback is missing. So far, disabling (unexporting) a GPIO left the pin in its last state. Implement a proper gpio_disable_free function which clears the three enable bits which influence the state (IBE, OBE and PUE). Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
2017-03-15iio: adc: vf610: Add IIO buffer support for Vybrid ADCSanchayan Maity
This patch adds support for IIO buffer to the Vybrid ADC driver. IIO triggered buffer infrastructure along with iio sysfs trigger is used to leverage continuous sampling support provided by the ADC block. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-15touchscreen: fusion_F0710A: Reset controller if clear interrupt operation failsSanchayan Maity
Add support for resetting the controller using the gpio reset pin if interrupt could not be cleared. If clearing the interrupt fails, the interrupt line stays high and no further interrupts are generated resulting in a non functioning touchscreen until next reboot, when we reset the controller again in probe. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
2017-03-06Fix missing sanity check in /dev/sgAl Viro
[ Upstream commit 137d01df511b3afe1f05499aea05f3bafc0fb221 ] What happens is that a write to /dev/sg is given a request with non-zero ->iovec_count combined with zero ->dxfer_len. Or with ->dxferp pointing to an array full of empty iovecs. Having write permission to /dev/sg shouldn't be equivalent to the ability to trigger BUG_ON() while holding spinlocks... Found by Dmitry Vyukov and syzkaller. [ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the underlying issue. - Linus ] Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Reported-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursorMichel Dänzer
[ Upstream commit d74c67dd7800fc7aae381f272875c337f268806c ] The crtc_h/vdisplay fields may not match the CRTC viewport dimensions with special modes such as interlaced ones. Fixes the HW cursor disappearing in the bottom half of the screen with interlaced modes. Fixes: 6b16cf7785a4 ("drm/radeon: Hide the HW cursor while it's out of bounds") Cc: stable@vger.kernel.org Reported-by: Ashutosh Kumar <ashutosh.kumar@amd.com> Tested-by: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm/dp/mst: fix kernel oops when turning off secondary monitorPierre-Louis Bossart
[ Upstream commit bb08c04dc867b5f392caec635c097d5d5fcd8c9f ] 100% reproducible issue found on SKL SkullCanyon NUC with two external DP daisy-chained monitors in DP/MST mode. When turning off or changing the input of the second monitor the machine stops with a kernel oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly. This issue is traced to an inconsistent control flow in drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the same time as 'req_payload.num_slots' is set to zero, but the pointer is dereferenced even when req_payload.num_slot is zero. The problematic dereference was introduced in commit dfda0df34 ("drm/mst: rework payload table allocation to conform better") and may impact all versions since v3.18 The fix suggested by Chris Wilson removes the kernel oops and was found to work well after 10mn of monkey-testing with the second monitor power and input buttons Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990 Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.") Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v3.18+ Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06[media] siano: make it work again with CONFIG_VMAP_STACKMauro Carvalho Chehab
[ Upstream commit f9c85ee67164b37f9296eab3b754e543e4e96a1c ] Reported as a Kaffeine bug: https://bugs.kde.org/show_bug.cgi?id=375811 The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. On Kernel 4.9, the default is to not accept DMA on stack anymore on x86 architecture. On other architectures, this has been a requirement since Kernel 2.2. So, after this patch, this driver should likely work fine on all archs. Tested with USB ID 2040:5510: Hauppauge Windham Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06mmc: core: fix multi-bit bus width without high-speed modeAnssi Hannula
[ Upstream commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 ] Commit 577fb13199b1 ("mmc: rework selection of bus speed mode") refactored bus width selection code to mmc_select_bus_width(). However, it also altered the behavior to not call the selection code in non-high-speed modes anymore. This causes 1-bit mode to always be used when the high-speed mode is not enabled, even though 4-bit and 8-bit bus are valid bus widths in the backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed Modes in JEDEC 84-B50). This results in a significant regression in transfer speeds. Fix the code to allow 4-bit and 8-bit widths even without high-speed mode, as before. Tested with a Zynq-7000 PicoZed 7020 board. Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()Boris Ostrovsky
[ Upstream commit 74470954857c264168d2b5a113904cf0cfd27d18 ] rx_refill_timer should be deleted as soon as we disconnect from the backend since otherwise it is possible for the timer to go off before we get to xennet_destroy_queues(). If this happens we may dereference queue->rx.sring which is set to NULL in xennet_disconnect_backend(). Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: stable@vger.kernel.org Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06scsi: aacraid: Fix INTx/MSI-x issue with older controllersDave Carroll
[ Upstream commit 8af8e1c22f9994bb1849c01d66c24fe23f9bc9a0 ] commit 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang") caused a problem on older controllers which do not support MSI-x (namely ASR3405,ASR3805). This patch conditionalizes the previous patch to controllers which support MSI-x Cc: <stable@vger.kernel.org> # v4.7+ Fixes: 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang") Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: Dave Carroll <david.carroll@microsemi.com> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06target: Fix COMPARE_AND_WRITE ref leak for non GOOD statusNicholas Bellinger
[ Upstream commit 9b2792c3da1e80f2d460167d319302a24c9ca2b7 ] This patch addresses a long standing bug where the commit phase of COMPARE_AND_WRITE would result in a se_cmd->cmd_kref reference leak if se_cmd->scsi_status returned non SAM_STAT_GOOD. This would manifest first as a lost SCSI response, and eventual hung task during fabric driver logout or re-login, as existing shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref to reach zero. To address this bug, compare_and_write_post() has been changed to drop the incorrect !cmd->scsi_status conditional that was preventing *post_ret = 1 for being set during non SAM_STAT_GOOD status. This patch has been tested with SAM_STAT_CHECK_CONDITION status from normal target_complete_cmd() callback path, as well as the incoming __target_execute_cmd() submission failure path when se_cmd->execute_cmd() returns non zero status. Reported-by: Donald White <dew@datera.io> Cc: Donald White <dew@datera.io> Tested-by: Gary Guo <ghg@datera.io> Cc: Gary Guo <ghg@datera.io> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06target: Use correct SCSI status during EXTENDED_COPY exceptionNicholas Bellinger
[ Upstream commit 0583c261e6325f392c1f7a1b9112e31298e1a4bd ] This patch adds the missing target_complete_cmd() SCSI status parameter change in target_xcopy_do_work(), that was originally missing in commit 926317de33. It correctly propigates up the correct SCSI status during EXTENDED_COPY exception cases, instead of always using the hardcoded SAM_STAT_CHECK_CONDITION from original code. This is required for ESX host environments that expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com> Cc: Nixon Vincent <nixon.vincent@calsoftinc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm/i915: fix use-after-free in page_flip_completed()Andrey Ryabinin
[ Upstream commit 5351fbb1bf1413f6024892093528280769ca852f ] page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90 Call Trace: __asan_report_load8_noabort+0x59/0x80 page_flip_completed+0x3ff/0x490 intel_finish_page_flip_mmio+0xe3/0x130 intel_pipe_handle_vblank+0x2d/0x40 gen8_irq_handler+0x4a7/0xed0 __handle_irq_event_percpu+0xf6/0x860 handle_irq_event_percpu+0x6b/0x160 handle_irq_event+0xc7/0x1b0 handle_edge_irq+0x1f4/0xa50 handle_irq+0x41/0x70 do_IRQ+0x9a/0x200 common_interrupt+0x89/0x89 Freed: kfree+0x113/0x4d0 intel_unpin_work_fn+0x29a/0x3b0 process_one_work+0x79e/0x1b70 worker_thread+0x611/0x1460 kthread+0x241/0x3a0 ret_from_fork+0x27/0x40 Move queue_work() after trace_i915_flip_complete() to fix this. Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions") Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> # v2.6.36+ Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com (cherry picked from commit 05c41f926fcc7ef838c80a6a99d84f67b4e0b824) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: pl2303: add ATEN device IDMarcel J.E. Mol
[ Upstream commit d07830db1bdb254e4b50d366010b219286b8c937 ] Seems that ATEN serial-to-usb devices using pl2303 exist with different device ids. This patch adds a missing device ID so it is recognised by the driver. Signed-off-by: Marcel J.E. Mol <marcel@mesa.nl> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06mmc: sdhci: Ignore unexpected CARD_INT interruptsGabriel Krisman Bertazi
[ Upstream commit 161e6d44a5e2d3f85365cb717d60e363171b39e6 ] One of our kernelCI boxes hanged at boot because a faulty eSDHC device was triggering spurious CARD_INT interrupts for SD cards, causing CMD52 reads, which are not allowed for SD devices. This adds a sanity check to the interruption path, preventing that illegal command from getting sent if the CARD_INT interruption should be disabled. This quirk allows that particular machine to resume boot despite the faulty hardware, instead of getting hung dealing with thousands of mishandled interrupts. Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrievalIlia Mirkin
[ Upstream commit 24bf7ae359b8cca165bb30742d2b1c03a1eb23af ] Based on the xf86-video-nv code, NFORCE (NV1A) and NFORCE2 (NV1F) have a different way of retrieving clocks. See the nv_hw.c:nForceUpdateArbitrationSettings function in the original code for how these clocks were accessed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54587 Cc: stable@vger.kernel.org Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06ISDN: eicon: silence misleading array-bounds warningArnd Bergmann
[ Upstream commit 950eabbd6ddedc1b08350b9169a6a51b130ebaaf ] With some gcc versions, we get a warning about the eicon driver, and that currently shows up as the only remaining warning in one of the build bots: In file included from ../drivers/isdn/hardware/eicon/message.c:30:0: eicon/message.c: In function 'mixer_notify_update': eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds] The code is easily changed to open-code the unusual PUT_WORD() line causing this to avoid the warning. Cc: stable@vger.kernel.org Link: http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.45/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06usb: gadget: f_fs: Assorted buffer overflow checks.Vincent Pelletier
[ Upstream commit 83e526f2a2fa4b2e82b6bd3ddbb26b70acfa8947 ] OS descriptor head, when flagged as provided, is accessed without checking if it fits in provided buffer. Verify length before access. Also, there are other places where buffer length it checked after accessing offsets which are potentially past the end. Check buffer length before as well to fail cleanly. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm/i915: Don't leak edid in intel_crt_detect_ddc()Ander Conselvan de Oliveira
[ Upstream commit c34f078675f505c4437919bb1897b1351f16a050 ] In the path where intel_crt_detect_ddc() detects a CRT, if would return true without freeing the edid. Fixes: a2bd1f541f19 ("drm/i915: check whether we actually received an edid in detect_ddc") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.6+ Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-1-git-send-email-ander.conselvan.de.oliveira@intel.com (cherry picked from commit c96b63a6a7ac4bd670ec2e663793a9a31418b790) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: Add quirk for WORLDE easykey.25 MIDI keyboardLukáš Lalinský
[ Upstream commit d9b2997e4a0a874e452df7cdd7de5a54502bd0aa ] Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218, idProduct=0401). The device reports that it has config string descriptor at index 3, but when the system selects the configuration and tries to get the description, it returns a -EPROTO error, the communication restarts and this keeps repeating over and over again. Not requesting the string descriptor makes the device work correctly. Relevant info from Wireshark: [...] CONFIGURATION DESCRIPTOR bLength: 9 bDescriptorType: 0x02 (CONFIGURATION) wTotalLength: 101 bNumInterfaces: 2 bConfigurationValue: 1 iConfiguration: 3 Configuration bmAttributes: 0xc0 SELF-POWERED NO REMOTE-WAKEUP 1... .... = Must be 1: Must be 1 for USB 1.1 and higher .1.. .... = Self-Powered: This device is SELF-POWERED ..0. .... = Remote Wakeup: This device does NOT support remote wakeup bMaxPower: 50 (100mA) [...] 45 0.369104 host 2.38.0 USB 64 GET DESCRIPTOR Request STRING [...] URB setup bmRequestType: 0x80 1... .... = Direction: Device-to-host .00. .... = Type: Standard (0x00) ...0 0000 = Recipient: Device (0x00) bRequest: GET DESCRIPTOR (6) Descriptor Index: 0x03 bDescriptorType: 0x03 Language Id: English (United States) (0x0409) wLength: 255 46 0.369255 2.38.0 host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet] [...] Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0 USB URB [Source: 2.38.0] [Destination: host] URB id: 0xffff88021f62d480 URB type: URB_COMPLETE ('C') URB transfer type: URB_CONTROL (0x02) Endpoint: 0x80, Direction: IN Device: 38 URB bus id: 2 Device setup request: not relevant ('-') Data: present (0) URB sec: 1484896277 URB usec: 455031 URB status: Protocol error (-EPROTO) (-71) URB length [bytes]: 0 Data length [bytes]: 0 [Request in: 45] [Time from request: 0.000151000 seconds] Unused Setup Header Interval: 0 Start frame: 0 Copy of Transfer Flags: 0x00000200 Number of ISO descriptors: 0 [Malformed Packet: USB] [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)] [Malformed Packet (Exception occurred)] [Severity level: Error] [Group: Malformed] Signed-off-by: Lukáš Lalinský <lukas@oxygene.sk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06fbdev: color map copying bounds checkingKees Cook
[ Upstream commit 2dc705a9930b4806250fbf5a76e55266e59389f2 ] Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps. CVE-2016-8405 Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Peter Pi (@heisecode) of Trend Micro Cc: Min Chong <mchong@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: option: add device ID for HP lt2523 (Novatel E371)Bjørn Mork
[ Upstream commit 5d03a2fd2292e71936c4235885c35ccc3c94695b ] Yet another laptop vendor rebranded Novatel E371. Cc: stable@vger.kernel.org Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: qcserial: add Dell DW5570 QDLAleksander Morgado
[ Upstream commit 24d615a694d649aa2e167c3f97f62bdad07e3f84 ] The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by default boot with vid 0x413c and pid 0x81a3. When triggered QDL download mode, the device switches to pid 0x81a6 and provides the standard TTY used for firmware upgrade. Cc: <stable@vger.kernel.org> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06can: ti_hecc: add missing prepare and unprepare of the clockYegor Yefremov
[ Upstream commit befa60113ce7ea270cb51eada28443ca2756f480 ] In order to make the driver work with the common clock framework, this patch converts the clk_enable()/clk_disable() to clk_prepare_enable()/clk_disable_unprepare(). Also add error checking for clk_prepare_enable(). Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointerEinar Jón
[ Upstream commit c97c52be78b8463ac5407f1cf1f22f8f6cf93a37 ] The priv->device pointer for c_can_pci is never set, but it is used without a NULL check in c_can_start(). Setting it in c_can_pci_probe() like c_can_plat_probe() prevents c_can_pci.ko from crashing, with and without CONFIG_PM. This might also cause the pm_runtime_*() functions in c_can.c to actually be executed for c_can_pci devices - they are the only other place where priv->device is used, but they all contain a null check. Signed-off-by: Einar Jón <tolvupostur@gmail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06qla2xxx: Fix crash due to null pointer accessQuinn Tran
[ Upstream commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 ] During code inspection, while investigating following stack trace seen on one of the test setup, we found out there was possibility of memory leak becuase driver was not unwinding the stack properly. This issue has not been reproduced in a test environment or on a customer setup. Here's stack trace that was seen. [1469877.797315] Call Trace: [1469877.799940] [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx] [1469877.806980] [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx] [1469877.814013] [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0 [1469877.820265] [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90 [1469877.826776] [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80 [1469877.833720] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.839885] [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80 [1469877.846830] [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0 [1469877.852562] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.858727] [<ffffffff81319c89>] pci_call_probe+0x89/0xb0 Cc: <stable@vger.kernel.org> Signed-off-by: Quinn Tran <quinn.tran@cavium.com> Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com> Reviewed-by: Christoph Hellwig <hch@lst.de> [ bvanassche: Fixed spelling in patch description ] Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06mmc: mxs-mmc: Fix additional cycles after transmission stopStefan Wahren
[ Upstream commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 ] According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06drm: Fix broken VT switch with video=1366x768 optionTakashi Iwai
[ Upstream commit fdf35a6b22247746a7053fc764d04218a9306f82 ] I noticed that the VT switch doesn't work any longer with a Dell laptop with 1366x768 eDP when the machine is connected with a DP monitor. It behaves as if VT were switched, but the graphics remain frozen. Actually the keyboard works, so I could switch back to VT7 again. I tried to track down the problem, and encountered a long story until we reach to this error: - The machine is booted with video=1366x768 option (the distro installer seems to add it as default). - Recently, drm_helper_probe_single_connector_modes() deals with cmdline modes, and it tries to create a new mode when no matching mode is found. - The drm_mode_create_from_cmdline_mode() creates a mode based on either CVT of GFT according to the given cmdline mode; in our case, it's 1366x768. - Since both CVT and GFT can't express the width 1366 due to alignment, the resultant mode becomes 1368x768, slightly larger than the given size. - Later on, the atomic commit is performed, and in drm_atomic_check_only(), the size of each plane is checked. - The size check of 1366x768 fails due to the above, and eventually the whole VT switch fails. Back in the history, we've had a manual fix-up of 1368x768 in various places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD panel"), but they have been all in drm_edid.c at probing the modes from EDID. For addressing the problem above, we need a similar hack to the mode newly created from cmdline, manually adjusting the width when the expected size is 1366 while we get 1368 instead. Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.de Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06xhci: fix deadlock at host remove by running watchdog correctlyMathias Nyman
[ Upstream commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 ] If a URB is killed while the host is removed we can end up in a situation where the hub thread takes the roothub device lock, and waits for the URB to be given back by xhci-hcd, blocking the host remove code. xhci-hcd tries to stop the endpoint and give back the urb, but can't as the host is removed from PCI bus at the same time, preventing the normal way of giving back urb. Instead we need to rely on the stop command timeout function to give back the urb. This xhci_stop_endpoint_command_watchdog() timeout function used a XHCI_STATE_DYING flag to indicate if the timeout function is already running, but later this flag has been taking into use in other places to mark that xhci is dying. Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still checking that reading from pci state does not return 0xffffffff or that host is not halted before trying to stop the endpoint. This whole area of stopping endpoints, giving back URBs, and the wathdog timeout need rework, this fix focuses on solving a specific deadlock issue that we can then send to stable before any major rework. Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06PCI: Enumerate switches below PCI-to-PCIe bridgesBjorn Helgaas
[ Upstream commit 51ebfc92b72b4f7dac1ab45683bf56741e454b8c ] A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary interface and a PCI Express secondary interface. The PCIe interface is a Downstream Port that originates a Link. See the "PCI Express to PCI/PCI-X Bridge Specification", rev 1.0, sections 1.2 and A.6. The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below the bridge: 00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a] 01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a] 02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a] 03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a] 01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by lspci). As we traverse a PCIe hierarchy, device connections alternate between PCIe Links and internal Switch logic. Previously we did not recognize that 01:00.0 had a secondary link, so we thought the 02:00.0 Upstream Port *did* have a secondary link. In fact, it's the other way around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic on its secondary side. When we thought 02:00.0 had a secondary link, the pci_scan_slot() -> only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0 was the only possible downstream device. But 03:00.0 doesn't exist, so we didn't look for any other devices on bus 03. Booting with "pci=pcie_scan_all" is a workaround, but we don't want users to have to do that. Recognize that PCI-to-PCIe bridges originate links on their secondary interfaces. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361 Fixes: d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links") Tested-by: Blake Moore <blake.moore@men.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.2+ Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: ch341: fix control-message error handlingJohan Hovold
[ Upstream commit 2d5a9c72d0c4ac73cf97f4b7814ed6c44b1e49ae ] A short control transfer would currently fail to be detected, something which could lead to stale buffer data being used as valid input. Check for short transfers, and make sure to log any transfer errors. Note that this also avoids leaking heap data to user space (TIOCMGET) and the remote device (break control). Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06vme: Fix wrong pointer utilization in ca91cx42_slave_getAugusto Mecking Caringi
[ Upstream commit c8a6a09c1c617402cc9254b2bc8da359a0347d75 ] In ca91cx42_slave_get function, the value pointed by vme_base pointer is set through: *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); So it must be dereferenced to be used in calculation of pci_base: *pci_base = (dma_addr_t)*vme_base + pci_offset; This bug was caught thanks to the following gcc warning: drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *pci_base = (dma_addr_t)vme_base + pci_offset; Signed-off-by: Augusto Mecking Caringi <augustocaringi@gmail.com> Acked-By: Martyn Welch <martyn@welchs.me.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06sysrq: attach sysrq handler correctly for 32-bit kernelAkinobu Mita
[ Upstream commit 802c03881f29844af0252b6e22be5d2f65f93fd0 ] The sysrq input handler should be attached to the input device which has a left alt key. On 32-bit kernels, some input devices which has a left alt key cannot attach sysrq handler. Because the keybit bitmap in struct input_device_id for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is greater than BITS_PER_LONG on 32-bit kernels. I found this problem when using a matrix keypad device which defines a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32). Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: kl5kusb105: fix line-state error handlingJohan Hovold
[ Upstream commit 146cc8a17a3b4996f6805ee5c080e7101277c410 ] The current implementation failed to detect short transfers when attempting to read the line state, and also, to make things worse, logged the content of the uninitialised heap transfer buffer. Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: ch341: fix open error handlingJohan Hovold
[ Upstream commit f2950b78547ffb8475297ada6b92bc2d774d5461 ] Make sure to stop the interrupt URB before returning on errors during open. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: ch341: fix modem-control and B0 handlingJohan Hovold
[ Upstream commit 030ee7ae52a46a2be52ccc8242c4a330aba8d38e ] The modem-control signals are managed by the tty-layer during open and should not be asserted prematurely when set_termios is called from driver open. Also make sure that the signals are asserted only when changing speed from B0. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
2017-03-06USB: serial: ch341: fix open and resume after B0Johan Hovold
[ Upstream commit a20047f36e2f6a1eea4f1fd261aaa55882369868 ] The private baud_rate variable is used to configure the port at open and reset-resume and must never be set to (and left at) zero or reset-resume and all further open attempts will fail. Fixes: aa91def41a7b ("USB: ch341: set tty baud speed according to tty struct") Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-06 02:54:49 +0000