- 31 Dec, 2019 40 commits
-
-
Miquel Raynal authored
[ Upstream commit db033831 ] All the registers are configured by the driver, let's reset the chip at probe time, avoiding any conflict with a possible earlier configuration. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ingo Rohloff authored
[ Upstream commit abb0b3d9 ] commit 1455cf8d ("driver core: emit uevents when device is bound to a driver") added bind and unbind uevents when a driver is bound or unbound to a physical device. For USB devices which are handled via the generic usbfs layer (via libusb for example), this is problematic: Each time a user space program calls ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr); and then later ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr); The kernel will now produce a bind or unbind event, which does not really contain any useful information. This allows a user space program to run a DoS attack against programs which listen to uevents (in particular systemd/eudev/upowerd): A malicious user space program just has to call in a tight loop ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr); ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr); With this loop the malicious user space program floods the kernel and all programs listening to uevents with tons of bind and unbind events. This patch suppresses uevents for ioctls USBDEVFS_CLAIMINTERFACE and USBDEVFS_RELEASEINTERFACE. Signed-off-by:
Ingo Rohloff <ingo.rohloff@lauterbach.com> Link: https://lore.kernel.org/r/20191011115518.2801-1-ingo.rohloff@lauterbach.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jin Yao authored
[ Upstream commit 800d3f56 ] We received a user report that call-graph DWARF mode was enabled in 'perf record' but 'perf report' didn't unwind the callstack correctly. The reason was, libunwind was not compiled in. We can use 'perf -vv' to check the compiled libraries but it would be valuable to report a warning to user directly (especially valuable for a perf newbie). The warning is: Warning: Please install libunwind development packages during the perf build. Both TUI and stdio are supported. Signed-off-by:
Jin Yao <yao.jin@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20191011022122.26369-1-yao.jin@linux.intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Leo Yan authored
[ Upstream commit 6add129c ] When fail to mmap events in task exit case, it misses to set 'err' to -1; thus the testing will not report failure for it. This patch sets 'err' to -1 when fails to mmap events, thus Perf tool can report correct result. Fixes: d723a550 ("perf test: Add test case for checking number of EXIT events") Signed-off-by:
Leo Yan <leo.yan@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lore.kernel.org/lkml/20191011091942.29841-1-leo.yan@linaro.orgSigned-off-by:
-
Daniel Kurtz authored
[ Upstream commit fadfee3f ] When setting a new display mode, dw_hdmi_setup() calls dw_hdmi_enable_video_path(), which disables all hdmi clocks, including the audio clock. We should only (re-)enable the audio clock if audio was already enabled when setting the new mode. Without this patch, on RK3288, there will be HDMI audio on some monitors if i2s was played to headphone when the monitor was plugged. ACER H277HU and ASUS PB278 are two of the monitors showing this issue. Signed-off-by:
Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Bjorn Andersson authored
[ Upstream commit d43810b2 ] The return value of dma_map_single() should be checked for errors using dma_mapping_error() and the skb has been dequeued so it needs to be freed. This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the missing dma_mapping_error() call. Fixes: 1807da49 ("ath10k: wmi: add management tx by reference support over wmi") Reported-by:
Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Sami Tolvanen authored
[ Upstream commit f53e2cd0 ] We call native_set_fixmap indirectly through the function pointer struct pv_mmu_ops::set_fixmap, which expects the first parameter to be 'unsigned' instead of 'enum fixed_addresses'. This patch changes the function type for native_set_fixmap to match the pointer, which fixes indirect call mismatches with Control-Flow Integrity (CFI) checking. Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H . Peter Anvin <hpa@zytor.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20190913211402.193018-1-samitolvanen@google.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephan Gerhold authored
[ Upstream commit 69426350 ] On some devices (e.g. Samsung Galaxy A5 (2015)), the bootloader seems to keep interrupts enabled for SM5502 when booting Linux. Changing the cable state (i.e. plugging in a cable) - until the driver is loaded - will therefore produce an interrupt that is never read. In this situation, the cable state will be stuck forever on the initial state because SM5502 stops sending interrupts. This can be avoided by clearing those pending interrupts after the driver has been loaded. One way to do this is to reset all registers to default state by writing to SM5502_REG_RESET. This ensures that we start from a clean state, with all interrupts disabled. Suggested-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
David Galiffi authored
[ Upstream commit dd998291 ] [WHY] During detection: function: get_active_converter_info populates link->dpcd_caps.dongle_caps only when dpcd_rev >= DPCD_REV_11 and DWN_STRM_PORTX_TYPE is DOWN_STREAM_DETAILED_HDMI or DOWN_STREAM_DETAILED_DP_PLUS_PLUS. Otherwise, it is not cleared, and stale information remains. During mode validation: function: dp_active_dongle_validate_timing reads link->dpcd_caps.dongle_caps->dongle_type to determine the maximum pixel clock to support. This information is now stale and no longer valid. [HOW] dp_active_dongle_validate_timing should be using link->dpcd_caps->dongle_type instead. Signed-off-by:
David Galiffi <david.galiffi@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sami Tolvanen authored
[ Upstream commit 8661d769 ] Although a syscall defined using SYSCALL_DEFINE0 doesn't accept parameters, use the correct function type to avoid type mismatches with Control-Flow Integrity (CFI) checking. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: H . Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20191008224049.115427-2-samitolvanen@google.comSigned-off-by:
-
Benoit Parrot authored
[ Upstream commit 0bac73ad ] v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(463): !pfmt.sizeimage fail: v4l2-test-formats.cpp(736): \ Video Capture Multiplanar is valid, \ but TRY_FMT failed to return a format test VIDIOC_TRY_FMT: FAIL This failure is causd by the driver failing to handle out range 'bytesperline' values from user space applications. VPDMA hardware is limited to 64k line stride (16 bytes aligned, so 65520 bytes). So make sure the provided or calculated 'bytesperline' is smaller than the maximum value. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit cf6acb73 ] v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(691): ret == 0 fail: v4l2-test-buffers.cpp(974): captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL This caused the following Kernel Warning: WARNING: CPU: 0 PID: 961 at drivers/media/v4l2-core/videobuf2-core.c:1658 __vb2_queue_cancel+0x174/0x1d8 ... CPU: 0 PID: 961 Comm: v4l2-compliance Not tainted 4.14.62-01720-g20ecd717e87a #6 Hardware name: Generic DRA72X (Flattened Device Tree) Backtrace: [<c020b5bc>] (dump_backtrace) from [<c020b8a0>] (show_stack+0x18/0x1c) r7:00000009 r6:60070013 r5:00000000 r4:c1053824 [<c020b888>] (show_stack) from [<c09232e8>] (dump_stack+0x90/0xa4) [<c0923258>] (dump_stack) from [<c022b740>] (__warn+0xec/0x104) r7:00000009 r6:c0c0ad50 r5:00000000 r4:00000000 [<c022b654>] (__warn) from [<c022b810>] (warn_slowpath_null+0x28/0x30) r9:00000008 r8:00000000 r7:eced4808 r6:edbc9bac r5:eced4844 r4:eced4808 [<c022b7e8>] (warn_slowpath_null) from [<c0726f48>] (__vb2_queue_cancel+0x174/0x1d8) [<c0726dd4>] (__vb2_queue_cancel) from [<c0727648>] (vb2_core_queue_release+0x20/0x40) r10:ecc7bd70 r9:00000008 r8:00000000 r7:edb73010 r6:edbc9bac r5:eced4844 r4:eced4808 r3:00000004 [<c0727628>] (vb2_core_queue_release) from [<c0729528>] (vb2_queue_release+0x10/0x14) r5:edbc9810 r4:eced4800 [<c0729518>] (vb2_queue_release) from [<c0724d08>] (v4l2_m2m_ctx_release+0x1c/0x30) [<c0724cec>] (v4l2_m2m_ctx_release) from [<bf0e8f28>] (vpe_release+0x74/0xb0 [ti_vpe]) r5:edbc9810 r4:ed67a400 [<bf0e8eb4>] (vpe_release [ti_vpe]) from [<c070fccc>] (v4l2_release+0x3c/0x80) r7:edb73010 r6:ed176aa0 r5:edbc9868 r4:ed5119c0 [<c070fc90>] (v4l2_release) from [<c033cf1c>] (__fput+0x8c/0x1dc) r5:ecc7bd70 r4:ed5119c0 [<c033ce90>] (__fput) from [<c033d0cc>] (____fput+0x10/0x14) r10:00000000 r9:ed5119c0 r8:ece392d0 r7:c1059544 r6:ece38d80 r5:ece392b4 r4:00000000 [<c033d0bc>] (____fput) from [<c0246e00>] (task_work_run+0x98/0xb8) [<c0246d68>] (task_work_run) from [<c022f1d8>] (do_exit+0x170/0xa80) r9:ece351fc r8:00000000 r7:ecde3f58 r6:ffffe000 r5:ece351c0 r4:ece38d80 [<c022f068>] (do_exit) from [<c022fb6c>] (do_group_exit+0x48/0xc4) r7:000000f8 [<c022fb24>] (do_group_exit) from [<c022fc00>] (__wake_up_parent+0x0/0x28) r7:000000f8 r6:b6c6a798 r5:00000001 r4:00000001 [<c022fbe8>] (SyS_exit_group) from [<c0207c80>] (ret_fast_syscall+0x0/0x4c) These warnings are caused by buffers which not properly cleaned up/release during an abort use case. In the abort cases the VPDMA desc buffers would still be mapped and the in-flight VB2 buffers would not be released properly causing a kernel warning from being generated by the videobuf2-core level. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit a37980ac ] v4l2-compliance fails with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. test VIDIOC_TRY_FMT: FAIL This causes the following kernel panic: Unable to handle kernel paging request at virtual address 56595561 pgd = ecd80e00 *pgd=00000000 Internal error: Oops: 205 [#1] PREEMPT SMP ARM ... CPU: 0 PID: 930 Comm: v4l2-compliance Not tainted \ 4.14.62-01715-gc8cd67f49a19 #1 Hardware name: Generic DRA72X (Flattened Device Tree) task: ece44d80 task.stack: ecc6e000 PC is at __vpe_try_fmt+0x18c/0x2a8 [ti_vpe] LR is at 0x8 Because the driver fails to properly check the 'num_planes' values for proper ranges it ends up accessing out of bound data causing the kernel panic. Since this driver only handle single or dual plane pixel format, make sure the provided value does not exceed 2 planes. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit e20b2480 ] v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(672): \ Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT fail: v4l2-test-formats.cpp(672): \ Video Output Multiplanar: TRY_FMT(G_FMT) != G_FMT ... test VIDIOC_TRY_FMT: FAIL The default pixel format was setup as pointing to a specific offset in the vpe_formats table assuming it was pointing to the V4L2_PIX_FMT_YUYV entry. This became false after the addition on the NV21 format (see above commid-id) So instead of hard-coding an offset which might change over time we need to use a lookup helper instead so we know the default will always be what we intended. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 2444846c ] v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(294): \ (int)g_sequence() < seq.last_seq + 1 fail: v4l2-test-buffers.cpp(740): \ buf.check(m2m_q, last_m2m_seq) fail: v4l2-test-buffers.cpp(974): \ captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL The driver is failing to update the source frame sequence number in the vb2 buffer object. Only the destination frame sequence was being updated. This is only a reporting issue if the user space app actually cares about the frame sequence number. But it is fixed nonetheless. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 06bec72b ] v4l2-compliance warns with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(718): \ This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(719): \ http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html ... test VIDIOC_TRY_FMT: FAIL We need to make sure that the returns a valid pixel format in all instance. Based on the v4l2 framework convention drivers must return a valid pixel format when the requested pixel format is either invalid or not supported. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 102af9b9 ] commit 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") and commit da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") resulted in the Motion Vector stride to be the same as the image stride. This caused memory corruption in the output image as mentioned in commit 00db9699 ("[media] media: ti-vpe: vpe: Fix line stride for output motion vector"). Fixes: 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") Fixes: da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") Signed-off-by:
Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit e1444e9b ] A call to 'pci_disable_device()' is missing in the error handling path. In some cases, a call to 'free_irq()' may also be missing. Reorder the error handling path, add some new labels and fix the 2 issues mentionned above. This way, the error handling path in more in line with 'cx8800_finidev()' (i.e. the remove function) Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Rodrigo Siqueira authored
[ Upstream commit aed6105b ] For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland * Weston * Mutter * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING". * Look in the git history of the project with the command git log -S<STRING> None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects. Change since V5 (Pekka Paalanen): - Check if the change also affects Mutter Change since V4 (Daniel): - Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Cc: Keith Packard <keithp@keithp.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002140516.adeyj3htylimmlmg@smtp.gmail.comSigned-off-by:
-
Navid Emamdoost authored
[ Upstream commit d10dcb61 ] In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release for skb and card->evtbd_ring_vbase is added. Fixes: 0732484b ("mwifiex: separate ring initialization and ring creation routines") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 1d200e9d ] Fix the following compiler warnings: In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:21, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from ./include/linux/bvec.h:13, from ./include/linux/blk_types.h:10, from block/blk-wbt.c:23: In function 'strncpy', inlined from 'perf_trace_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Fixes: e34cbd30 ("blk-wbt: add general throttling mechanism"; v4.10). Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Daniel T. Lee authored
[ Upstream commit 3cad8f91 ] Currently, proc_cmd is used to dispatch command to 'pg_ctrl', 'pg_thread', 'pg_set'. proc_cmd is designed to check command result with grep the "Result:", but this might fail since this string is only shown in 'pg_thread' and 'pg_set'. This commit fixes this logic by grep-ing the "Result:" string only when the command is not for 'pg_ctrl'. For clarity of an execution flow, 'errexit' flag has been set. To cleanup pktgen on exit, trap has been added for EXIT signal. Signed-off-by:
Daniel T. Lee <danieltimlee@gmail.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Matthias Kaehlcke authored
[ Upstream commit bee447e2 ] The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Sean Paul <sean@poorly.run> Acked-by:
-
Hans Verkuil authored
[ Upstream commit 9b211f9c ] The CEC_MSG_GIVE_DECK_STATUS and CEC_MSG_GIVE_TUNER_DEVICE_STATUS commands both have a status_req argument: ON, OFF, ONCE. If ON or ONCE, then the follower will reply with a STATUS message. Either once or whenever the status changes (status_req == ON). If status_req == OFF, then it will stop sending continuous status updates, but the follower will *not* send a STATUS message in that case. This means that if status_req == OFF, then msg->reply should be 0 as well since no reply is expected in that case. Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit 649cd16c ] If usb_set_interface() failed, iface->cur_altsetting will not be assigned and it will be used in flexcop_usb_transfer_init() It may lead a NULL pointer dereference. Check usb_set_interface() return value in flexcop_usb_init() and return failed to avoid using this NULL pointer. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Yizhuo authored
[ Upstream commit 472b39c3 ] Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by:
Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.eduSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit eaecce12 ] When unloading omap3-rom-rng, we'll get the following: WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable This is because the clock may be already disabled by omap3_rom_rng_idle(). Let's fix the issue by checking for rng_idle on exit. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 1c6b7c21 ("hwrng: OMAP3 ROM Random Number Generator support") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Veeraiyan Chidambaram authored
[ Upstream commit 39abcc84 ] When R-Car Gen3 USB 2.0 is in Gadget mode, if host is detached an interrupt will be generated and Suspended state bit is set in interrupt status register. Interrupt handler will call driver->suspend(composite_suspend) if suspended state bit is set. composite_suspend will call ffs_func_suspend which will post FUNCTIONFS_SUSPEND and will be consumed by user space application via /dev/ep0. To be able to detect host detach, extend the DVSQ_MASK to cover the Suspended bit of the DVSQ[2:0] bitfield from the Interrupt Status Register 0 (INTSTS0) register and perform appropriate action in the DVST interrupt handler (usbhsg_irq_dev_state). Without this commit, disconnection of the phone from R-Car-H3 ES2.0 Salvator-X CN9 port is not recognized and reverse role switch does not happen. If phone is connected again it does not enumerate. With this commit, disconnection will be recognized and reverse role switch will happen by a user space application. If phone is connected again it will enumerate properly and will become visible in the output of 'lsusb'. Signed-off-by:
Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
-
Stanimir Varbanov authored
[ Upstream commit 8dbebb2b ] Failure to suspend (venus_suspend_3xx) happens when the system is fresh booted and loading venus driver. This happens once and after reload the venus driver modules the problem disrepair. Fix the failure by skipping the check for WFI and IDLE bits if PC_READY is on in control status register. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Ivan Khoronzhuk authored
[ Upstream commit c5881463 ] The "path" buf is supposed to contain path + printf msg up to 24 bytes. It will be cut anyway, but compiler generates truncation warns like: " samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c: In function ‘setup_cgroup_environment’: samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:34: warning: ‘/cgroup.controllers’ directive output may be truncated writing 19 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:2: note: ‘snprintf’ output between 20 and 4116 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:34: warning: ‘/cgroup.subtree_control’ directive output may be truncated writing 23 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.subtree_control", ^~~~~~~~~~~~~~~~~~~~~~~ cgroup_path); samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:2: note: ‘snprintf’ output between 24 and 4120 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.subtree_control", cgroup_path); " In order to avoid warns, lets decrease buf size for cgroup workdir on 24 bytes with assumption to include also "/cgroup.subtree_control" to the address. The cut will never happen anyway. Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20191002120404.26962-3-ivan.khoronzhuk@linaro.orgSigned-off-by:
-
Allen Pais authored
[ Upstream commit 81de29d8 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. v2 (Felix Kuehling): * Fix compile error (kfifo_free instead of fifo_free) * Return proper error code Signed-off-by:
Allen Pais <allen.pais@oracle.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit be4c60b5 ] When populating the pinctrl mapping table entries for a device, the 'dev_name' field for each entry is initialised to point directly at the string returned by 'dev_name()' for the device and subsequently used by 'create_pinctrl()' when looking up the mappings for the device being probed. This is unreliable in the presence of calls to 'dev_set_name()', which may reallocate the device name string leaving the pinctrl mappings with a dangling reference. This then leads to a use-after-free every time the name is dereferenced by a device probe: | BUG: KASAN: invalid-access in strcmp+0x20/0x64 | Read of size 1 at addr 13ffffc153494b00 by task modprobe/590 | Pointer tag: [13], memory tag: [fe] | | Call trace: | __kasan_report+0x16c/0x1dc | kasan_report+0x10/0x18 | check_memory_region | __hwasan_load1_noabort+0x4c/0x54 | strcmp+0x20/0x64 | create_pinctrl+0x18c/0x7f4 | pinctrl_get+0x90/0x114 | devm_pinctrl_get+0x44/0x98 | pinctrl_bind_pins+0x5c/0x450 | really_probe+0x1c8/0x9a4 | driver_probe_device+0x120/0x1d8 Follow the example of sysfs, and duplicate the device name string before stashing it away in the pinctrl mapping entries. Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by:
Elena Petrova <lenaptr@google.com> Tested-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20191002124206.22928-1-will@kernel.orgSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ben Greear authored
[ Upstream commit cc6df017 ] Offchannel management frames were failing: [18099.253732] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18102.293686] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18105.333653] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18108.373712] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18111.413687] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18114.453726] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 [18117.493773] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18120.533631] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 This bug appears to have been added between 4.0 (which works for us), and 4.4, which does not work. I think this is because the tx-offchannel logic gets in a loop when ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually sent to the firmware for transmit. This patch fixes the problem on 4.9 for me, and now HS20 clients can work again with my firmware. Antonio: tested with 10.4-3.5.3-00057 on QCA4019 and QCA9888 Signed-off-by:
Ben Greear <greearb@candelatech.com> Tested-by:
Antonio Quartulli <antonio.quartulli@kaiwoo.ai> [kvalo@codeaurora.org: improve commit log, remove unneeded parenthesis] Signed-off-by:
-
Loic Poulain authored
[ Upstream commit c690435e ] In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in encoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 7e5705c6 ] When building cpupower with clang, the following warning appears: utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] .desc = N_("Processor Package C2"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization is here .desc = N_("Processor Package C9"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ 1 warning generated. This appears to be a copy and paste or merge mistake because the name and id fields both have PC9 in them, not PC2. Remove the second assignment to fix the warning. Fixes: 7ee767b6 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states") Link: https://github.com/ClangBuiltLinux/linux/issues/718Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 1463b371 ] The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 3143b459 ] The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 9d669fbf ] The initial registers sequence is only loaded at probe time. Afterward only the resolution and format specific register are modified. Care must be taken to make sure registers modified by one resolution setting are reverted back when another resolution is programmed. This was not done properly for the 720p case. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 7b188d6b ] Commit 4f996594 ("[media] v4l2: make vidioc_s_crop const") introduced a writable copy of constified user requested crop rectangle in order to be able to perform hardware alignments on it. Later on, commit 10d5509c ("[media] v4l2: remove g/s_crop from video ops") replaced s_crop() video operation using that const argument with set_selection() pad operation which had a corresponding argument not constified, however the original behavior of the driver was not restored. Since that time, any hardware alignment applied on a user requested crop rectangle is not passed back to the user calling .set_selection() as it should be. Fix the issue by dropping the copy and replacing all references to it with references to the crop rectangle embedded in the user argument. Fixes: 10d5509c ("[media] v4l2: remove g/s_crop from video ops") Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 85c4043f ] In ov2659_s_stream() return value for invoked function should be checked and propagated. Signed-off-by:
-
