aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/platform
AgeCommit message (Collapse)Author
2020-09-04media: cros-ec-cec: do not bail on device_init_wakeup failureDariusz Marcinkiewicz
commit 6f01dfb760c027d5dd6199d91ee9599f2676b5c6 upstream. Do not fail probing when device_init_wakeup fails. device_init_wakeup fails when the device is already enabled as wakeup device. Hence, the driver fails to probe the device if: - The device has already been enabled for wakeup (by e.g. sysfs) - The driver has been unloaded and is being loaded again. This goal of the patch is to fix the above cases. Overwhelming majority of the drivers do not check device_init_wakeup return code. Fixes: cd70de2d356ee ("media: platform: Add ChromeOS EC CEC driver") Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-09-04media: exynos4-is: Add missed check for pinctrl_lookup_state()Chuhong Yuan
commit 18ffec750578f7447c288647d7282c7d12b1d969 upstream. fimc_md_get_pinctrl() misses a check for pinctrl_lookup_state(). Add the missed check to fix it. Fixes: 4163851f7b99 ("[media] s5p-fimc: Use pinctrl API for camera ports configuration]") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-09-04media: omap3isp: Add missed v4l2_ctrl_handler_free() for preview_init_entities()Chuhong Yuan
commit dc7690a73017e1236202022e26a6aa133f239c8c upstream. preview_init_entities() does not call v4l2_ctrl_handler_free() when it fails. Add the missed function to fix it. Fixes: de1135d44f4f ("[media] omap3isp: CCDC, preview engine and resizer") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-07-11media: platform: fcp: Set appropriate DMA parametersKieran Bingham
commit dd844fb8e50b12e65bbdc5746c9876c6735500df upstream. Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will enable extra validation on DMA operations ensuring that the size restraints are met. When using the FCP in conjunction with the VSP1/DU, and display frames, the size of the DMA operations is larger than the default maximum segment size reported by the DMA core (64K). With the DMA debug enabled, this produces a warning such as the following: "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device claims to support [len=3145728] [max=65536]" We have no specific limitation on the segment size which isn't already handled by the VSP1/DU which actually handles the DMA allcoations and buffer management, so define a maximum segment size of up to 4GB (a 32 bit mask). Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver") Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-07-11media: vicodec: Fix error codes in probe functionDan Carpenter
commit f36592e7b343d853edf44d3545bb68961c0949a4 upstream. If these functions fail then we return success, but we should instead preserve negative error code and return that. Fixes: fde649b418d1 ("media: vicodec: Register another node for stateless decoder") Fixes: c022a4a95722 ("media: vicodec: add struct for encoder/decoder instance") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-06-24media: platform: ao-cec-g12a: remove spin_lock_irqsave() locking in ↵Neil Armstrong
meson_ao_cec_g12a_read/write commit 7aac98494d1d932cde053861ce0c12ca5ab3f762 upstream. Since locking is handled by regmap, the spin_lock_irqsave() in the meson_ao_cec_g12a_read/write() regmap callbacks is not needed. Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-06-01media: ti-vpe: cal: fix a kernel oops when unloading moduleBenoit Parrot
commit 80264809ea0a3fd2ee8251f31a9eb85d2c3fc77e upstream. After the switch to use v4l2_async_notifier_add_subdev() and v4l2_async_notifier_cleanup(), unloading the ti_cal module would cause a kernel oops. This was root cause to the fact that v4l2_async_notifier_cleanup() tries to kfree the asd pointer passed into v4l2_async_notifier_add_subdev(). In our case the asd reference was from a statically allocated struct. So in effect v4l2_async_notifier_cleanup() was trying to free a pointer that was not kalloc. So here we switch to using a kzalloc struct instead of a static one. To achieve this we re-order some of the calls to prevent asd allocation from leaking. Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Cc: stable@vger.kernel.org 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+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-06-01media: ti-vpe: cal: fix disable_irqs to only the intended targetBenoit Parrot
commit 1db56284b9da9056093681f28db48a09a243274b upstream. disable_irqs() was mistakenly disabling all interrupts when called. This cause all port stream to stop even if only stopping one of them. Cc: stable <stable@vger.kernel.org> Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-06-01media: venus: firmware: Ignore secure call error on first resumeStanimir Varbanov
commit 2632e7b618a7730969f9782593c29ca53553aa22 upstream. With the latest cleanup in qcom scm driver the secure monitor call for setting the remote processor state returns EINVAL when it is called for the first time and after another scm call auth_and_reset. The error returned from scm call could be ignored because the state transition is already done in auth_and_reset. Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-06-01media: venus: hfi_parser: Ignore HEVC encoding for V1Stephan Gerhold
commit c50cc6dc6c48300af63a6fbc71b647053c15fc80 upstream. Some older MSM8916 Venus firmware versions also seem to indicate support for encoding HEVC, even though they really can't. This will lead to errors later because hfi_session_init() fails in this case. HEVC is already ignored for "dec_codecs", so add the same for "enc_codecs" to make these old firmware versions work correctly. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-05-15media: sti: bdisp: fix a possible sleep-in-atomic-context bug in ↵Jia-Ju Bai
bdisp_device_run() commit bb6d42061a05d71dd73f620582d9e09c8fbf7f5b upstream. The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: drivers/media/platform/sti/bdisp/bdisp-hw.c, 385: msleep in bdisp_hw_reset drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 341: bdisp_hw_reset in bdisp_device_run drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 317: _raw_spin_lock_irqsave in bdisp_device_run To fix this bug, msleep() is replaced with udelay(). This bug is found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-04-12media: fdp1: Fix R-Car M3-N naming in debug messageGeert Uytterhoeven
commit c05b9d7b9f3ece2831e4e4829f10e904df296df8 upstream. The official name is "R-Car M3-N", not "R-Car M3N". Fixes: 4e8c120de9268fc2 ("media: fdp1: Support M3N and E3 platforms") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-03-30media: aspeed-video: Fix memory leaks in aspeed_video_probeNavid Emamdoost
commit c3df30a01da4955e04fa068c503cd784b31dad92 upstream. In the implementation of aspeed_video_probe() the allocated memory for video should be released if either devm_ioremap_resource() or aspeed_video_init() or aspeed_video_setup_video() fails. Replace kzalloc() with devm_kzalloc to avoid explicit release for video. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-03-30media: exynos4-is: Fix recursive locking in isp_video_release()Seung-Woo Kim
commit 704c6c80fb471d1bb0ef0d61a94617d1d55743cd upstream. >From isp_video_release(), &isp->video_lock is held and subsequent vb2_fop_release() tries to lock vdev->lock which is same with the previous one. Replace vb2_fop_release() with _vb2_fop_release() to fix the recursive locking. Fixes: 1380f5754cb0 ("[media] videobuf2: Add missing lock held on vb2_fop_release") Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-03-30media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'Christophe JAILLET
commit 2eca8e4c1df4864b937752c3aa2f7925114f4806 upstream. The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of bytes. So use 'csi2rx->max_lanes' instead of 'sizeof(lanes_used)'. Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-03-30media: rcar-vin: Fix incorrect return statement in rvin_try_format()Niklas Söderlund
commit a0862a40364e2f87109317e31c51c9d7bc89e33f upstream. While refactoring code the return statement became corrupted, fix it by returning the correct return code. Reported-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Fixes: 897e371389e77514 ("media: rcar-vin: simplify how formats are set and reset" Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: vim2m: media_device_cleanup was called too earlyHans Verkuil
commit 9f22e88a4bba270d3427684cee84dfbf67489e86 upstream. Running the contrib/test/test-media script in v4l-utils with the vim2m argument will cause this kernel warning: [ 554.430157] ------------[ cut here ]------------ [ 554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380 [ 554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid] [ 554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1 [ 554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380 [ 554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48 [ 554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282 [ 554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f [ 554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4 [ 554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681 [ 554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000 [ 554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8 [ 554.479622] FS: 00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000 [ 554.482673] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0 [ 554.487811] Call Trace: [ 554.488860] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.490818] ? do_exit+0x946/0x2980 [ 554.492269] ? mutex_lock_io_nested+0x1250/0x1250 [ 554.494128] ? __lock_acquire+0xe90/0x3c30 [ 554.495774] ? fsnotify_first_mark+0x120/0x120 [ 554.497487] ? vim2m_device_release+0x50/0x50 [vim2m] [ 554.499469] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.501493] v4l2_release+0x1b8/0x390 [videodev] [ 554.503430] __fput+0x256/0x790 [ 554.504711] task_work_run+0x109/0x190 [ 554.506145] do_exit+0x95e/0x2980 [ 554.507421] ? vfs_lock_file+0x21/0xf0 [ 554.509013] ? find_held_lock+0x33/0x1c0 [ 554.510382] ? __close_fd+0xee/0x190 [ 554.511862] ? release_task.part.21+0x1310/0x1310 [ 554.513701] ? lock_downgrade+0x6d0/0x6d0 [ 554.515299] do_group_exit+0xeb/0x2d0 [ 554.516862] __x64_sys_exit_group+0x35/0x40 [ 554.518610] do_syscall_64+0x90/0x450 [ 554.520142] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 554.522289] RIP: 0033:0x7fac6348ecf6 [ 554.523876] Code: Bad RIP value. [ 554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6 [ 554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760 [ 554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000 [ 554.540634] irq event stamp: 21731 [ 554.541618] hardirqs last enabled at (21731): [<ffffffffb75b3cd4>] _raw_spin_unlock_irq+0x24/0x30 [ 554.544145] hardirqs last disabled at (21730): [<ffffffffb75b3ada>] _raw_spin_lock_irq+0xa/0x40 [ 554.547027] softirqs last enabled at (20148): [<ffffffffb780064d>] __do_softirq+0x64d/0x906 [ 554.550385] softirqs last disabled at (19857): [<ffffffffb5926bd5>] irq_exit+0x175/0x1a0 [ 554.553668] ---[ end trace a389c80c2ca84244 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the video_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: exynos4-is: fix wrong mdev and v4l2 dev order in error pathSeung-Woo Kim
commit 4d741cbd58bf889c8a68cf6e592a7892b5c2802e upstream. When driver is built as module and probe during insmod is deferred because of sensor subdevs, there is NULL pointer deference because mdev is cleaned up and then access it from v4l2_device_unregister(). Fix the wrong mdev and v4l2 dev order in error path of probe. This fixes below null pointer deference: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ca026f68 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM [...] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at ida_free+0x7c/0x160 LR is at xas_start+0x44/0x204 [...] [<c0dafd60>] (ida_free) from [<c083c20c>] (__media_device_unregister_entity+0x18/0xc0) [<c083c20c>] (__media_device_unregister_entity) from [<c083c2e0>] (media_device_unregister_entity+0x2c/0x38) [<c083c2e0>] (media_device_unregister_entity) from [<c0843404>] (v4l2_device_release+0xd0/0x104) [<c0843404>] (v4l2_device_release) from [<c0632558>] (device_release+0x28/0x98) [<c0632558>] (device_release) from [<c0db1204>] (kobject_put+0xa4/0x208) [<c0db1204>] (kct_put) from [<bf00bac4>] (fimc_capture_subdev_unregistered+0x58/0x6c [s5p_fimc]) [<bf00bac4>] (fimc_capture_subdev_unregistered [s5p_fimc]) from [<c084a1cc>] (v4l2_device_unregister_subdev+0x6c/0xa8) [<c084a1cc>] (v4l2_device_unregister_subdev) from [<c084a350>] (v4l2_device_unregister+0x64/0x94) [<c084a350>] (v4l2_device_unregister) from [<bf0101ac>] (fimc_md_probe+0x4ec/0xaf8 [s5p_fimc]) [...] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Fixes: 9832e155f1ed ("[media] media-device: split media initialization and registration") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: vivid: media_device_cleanup was called too earlyHans Verkuil
commit 8ffd573c25e5fac1daeeffc592e2ed6bc6a3d947 upstream. Running the contrib/test/test-media script in v4l-utils with the vivid argument will cause this kernel warning: [ 104.748720] videodev: v4l2_release [ 104.748731] ------------[ cut here ]------------ [ 104.748750] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 104.748790] WARNING: CPU: 6 PID: 1823 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 104.748800] Modules linked in: rc_cec vivid v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [ 104.748845] CPU: 6 PID: 1823 Comm: sleep Not tainted 5.4.0-rc1-test-no #150 [ 104.748853] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 104.748867] RIP: 0010:__mutex_lock+0x919/0xc10 [ 104.748878] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 104.748886] RSP: 0018:ffff88811a357b80 EFLAGS: 00010286 [ 104.748895] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 104.748902] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed102346af62 [ 104.748910] RBP: ffff88811a357cf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 104.748917] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff8881a46103c0 [ 104.748924] R13: 0000000000000000 R14: ffff8881a4614f90 R15: ffff8881a46153d0 [ 104.748933] FS: 0000000000000000(0000) GS:ffff8881b6780000(0000) knlGS:0000000000000000 [ 104.748940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 104.748949] CR2: 00007f163fc9ca20 CR3: 0000000003013004 CR4: 00000000001606e0 [ 104.749036] Call Trace: [ 104.749051] ? _raw_spin_unlock+0x1f/0x30 [ 104.749067] ? llist_add_batch+0x33/0x50 [ 104.749081] ? tick_nohz_tick_stopped+0x19/0x30 [ 104.749130] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749143] ? mutex_lock_io_nested+0xb80/0xb80 [ 104.749153] ? vprintk_emit+0xf2/0x220 [ 104.749191] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749201] ? printk+0xad/0xde [ 104.749211] ? kmsg_dump_rewind_nolock+0x54/0x54 [ 104.749226] ? locks_remove_file+0x78/0x2b0 [ 104.749248] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 104.749281] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749321] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749361] v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749378] __fput+0x15a/0x390 [ 104.749393] task_work_run+0xb2/0xe0 [ 104.749407] do_exit+0x4d0/0x1200 [ 104.749422] ? do_user_addr_fault+0x367/0x610 [ 104.749431] ? release_task+0x990/0x990 [ 104.749449] ? rwsem_spin_on_owner+0x170/0x170 [ 104.749463] ? vmacache_find+0xb2/0x100 [ 104.749476] do_group_exit+0x85/0x130 [ 104.749487] __x64_sys_exit_group+0x23/0x30 [ 104.749500] do_syscall_64+0x5e/0x1c0 [ 104.749511] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 104.749520] RIP: 0033:0x7f163fc5c9d6 [ 104.749536] Code: Bad RIP value. [ 104.749543] RSP: 002b:00007ffe6f3bec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 104.749553] RAX: ffffffffffffffda RBX: 00007f163fd4d760 RCX: 00007f163fc5c9d6 [ 104.749560] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 104.749567] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 104.749574] R10: 00007ffe6f3beb24 R11: 0000000000000246 R12: 00007f163fd4d760 [ 104.749581] R13: 0000000000000002 R14: 00007f163fd56428 R15: 0000000000000000 [ 104.749597] ---[ end trace 66f20f73fc0daf79 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: aspeed: set hsync and vsync polarities to normal before starting mode ↵Jae Hyun Yoo
detection commit 5b3f3c41c5c791c1c22cd91655e7ef4b2a1dff7c upstream. Sometimes it detects a weird resolution such as 1024x287 when the actual resolution is 1024x768. To resolve such an issue, this commit adds clearing for hsync and vsync polarity register bits at the beginning of the first mode detection. This is recommended in the datasheet. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: fix a v4l2-compliance failure about invalid sizeimageBenoit Parrot
commit 0bac73adea4df8d34048b38f6ff24dc3e73e90b6 upstream. 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: ensure buffers are cleaned up properly in abort casesBenoit Parrot
commit cf6acb73b050e98b5cc435fae0e8ae0157520410 upstream. 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 <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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: fix a v4l2-compliance failure causing a kernel panicBenoit Parrot
commit a37980ac5be29b83da67bf7d571c6bd9f90f8e45 upstream. 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 <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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: Make sure YUYV is set as default formatBenoit Parrot
commit e20b248051ca0f90d84b4d9378e4780bc31f16c6 upstream. 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 <bparrot@ti.com> Fixes: 40cc823f7005 ("media: ti-vpe: Add support for NV21 format") 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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: fix a v4l2-compliance failure about frame sequence numberBenoit Parrot
commit 2444846c0dbfa4ead21b621e4300ec32c90fbf38 upstream. 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 <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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: fix a v4l2-compliance warning about invalid pixel formatBenoit Parrot
commit 06bec72b250b2cb3ba96fa45c2b8e0fb83745517 upstream. 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 <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: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: ti-vpe: vpe: Fix Motion Vector vpdma strideBenoit Parrot
commit 102af9b9922f658f705a4b0deaccabac409131bf upstream. commit 3dc2046ca78b ("[media] media: ti-vpe: vpe: allow use of user specified stride") and commit da4414eaed15 ("[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 00db969964c8 ("[media] media: ti-vpe: vpe: Fix line stride for output motion vector"). Fixes: 3dc2046ca78b ("[media] media: ti-vpe: vpe: allow use of user specified stride") Fixes: da4414eaed15 ("[media] media: ti-vpe: vpdma: add support for user specified stride") Signed-off-by: Benoit Parrot <bparrot@ti.com> Acked-by: Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: venus: Fix occasionally failures to suspendStanimir Varbanov
commit 8dbebb2bd01e6f36e9a215dcde99ace70408f2c8 upstream. 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: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: vimc: Fix gpf in rmmod path when stream is activeShuah Khan
commit d7fb5c361c2a2666d20e044206e1756bc8e87df2 upstream. If vimc module is removed while streaming is in progress, sensor subdev unregister runs into general protection fault when it tries to unregister media entities. This is a common subdev problem related to releasing pads from v4l2_device_unregister_subdev() before calling unregister. Unregister references pads during unregistering subdev. The sd release handler is the right place for releasing all sd resources including pads. The release handlers currently release all resources except the pads. Fix v4l2_device_unregister_subdev() not release pads and release pads from the sd_int_op release handlers. kernel: [ 4136.715839] general protection fault: 0000 [#1] SMP PTI kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4 kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013 kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60 kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03 <48> 83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89 kernel: [ 4136.715866] RSP: 0018:ffff9b2248fe3cb0 EFLAGS: 00010246 kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: ffff88c3eb37e9c0 RCX: 00000000802a0018 kernel: [ 4136.715873] RDX: ffff88c3e4f6a078 RSI: ffff88c3eb37e9c0 RDI: ffffffffb0cf7f00 kernel: [ 4136.715876] RBP: ffff9b2248fe3cb8 R08: 0000000001000002 R09: ffffffffb0492b00 kernel: [ 4136.715879] R10: ffff9b2248fe3c28 R11: 0000000000000001 R12: 0000000000000038 kernel: [ 4136.715881] R13: ffffffffc09a1628 R14: ffff88c3e4f6a028 R15: fffffffffffffff2 kernel: [ 4136.715885] FS: 00007f8389647740(0000) GS:ffff88c465500000(0000) knlGS:0000000000000000 kernel: [ 4136.715888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: [ 4136.715891] CR2: 000055d008f80fd8 CR3: 00000001996ec005 CR4: 00000000000606e0 kernel: [ 4136.715894] Call Trace: kernel: [ 4136.715903] media_gobj_destroy+0x14/0x20 kernel: [ 4136.715908] __media_device_unregister_entity+0xb3/0xe0 kernel: [ 4136.715915] media_device_unregister_entity+0x30/0x40 kernel: [ 4136.715920] v4l2_device_unregister_subdev+0xa8/0xe0 kernel: [ 4136.715928] vimc_ent_sd_unregister+0x1e/0x30 [vimc] kernel: [ 4136.715933] vimc_sen_rm+0x16/0x20 [vimc] kernel: [ 4136.715938] vimc_remove+0x3e/0xa0 [vimc] kernel: [ 4136.715945] platform_drv_remove+0x25/0x50 kernel: [ 4136.715951] device_release_driver_internal+0xe0/0x1b0 kernel: [ 4136.715956] device_driver_detach+0x14/0x20 kernel: [ 4136.715960] unbind_store+0xd1/0x130 kernel: [ 4136.715965] drv_attr_store+0x27/0x40 kernel: [ 4136.715971] sysfs_kf_write+0x48/0x60 kernel: [ 4136.715976] kernfs_fop_write+0x128/0x1b0 kernel: [ 4136.715982] __vfs_write+0x1b/0x40 kernel: [ 4136.715987] vfs_write+0xc3/0x1d0 kernel: [ 4136.715993] ksys_write+0xaa/0xe0 kernel: [ 4136.715999] __x64_sys_write+0x1a/0x20 kernel: [ 4136.716005] do_syscall_64+0x5a/0x130 kernel: [ 4136.716010] entry_SYSCALL_64_after_hwframe+0x4 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: venus: core: Fix msm8996 frequency tableLoic Poulain
commit c690435ed07901737e5c007a65ec59f53b33eb71 upstream. 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: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: vim2m: Fix BUG_ON in vim2m_device_release()Kefeng Wang
commit 2455d417c03aa0cbafed04c46cbb354643238318 upstream. If v4l2_m2m_init() fails, m2m_dev pointer will be set ERR_PTR(-ENOMEM), then kfree m2m_dev will trigger BUG_ON, see below, fix it by setting m2m_dev to NULL. vim2m vim2m.0: Failed to init mem2mem device ------------[ cut here ]------------ kernel BUG at mm/slub.c:3944! invalid opcode: 0000 [#1] SMP PTI CPU: 11 PID: 9061 Comm: insmod Tainted: G E 5.2.0-rc2 #81 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:kfree+0x11a/0x160 Call Trace: vim2m_device_release+0x3f/0x50 [vim2m] device_release+0x27/0x80 kobject_release+0x68/0x190 vim2m_probe+0x20f/0x280 [vim2m] platform_drv_probe+0x37/0x90 really_probe+0xef/0x3d0 driver_probe_device+0x110/0x120 device_driver_attach+0x4f/0x60 __driver_attach+0x9a/0x140 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x76/0xc0 ? klist_add_tail+0x57/0x70 bus_add_driver+0x141/0x210 driver_register+0x5b/0xe0 vim2m_init+0x29/0x1000 [vim2m] do_one_initcall+0x46/0x1f4 ? __slab_alloc+0x1c/0x30 ? kmem_cache_alloc_trace+0x167/0x1b0 do_init_module+0x5b/0x21f load_module+0x1add/0x1fb0 ? __do_sys_finit_module+0xe9/0x110 __do_sys_finit_module+0xe9/0x110 do_syscall_64+0x5b/0x1c0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: ea6c7e34f3b2 ("media: vim2m: replace devm_kzalloc by kzalloc") Reported-by: Hulk Robot <hulkci@huawei.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: vim2m: Fix abort issueJernej Skrabec
commit c362f77a243bfd1daec21b6c36491c061ee2f31b upstream. Currently, if start streaming -> stop streaming -> start streaming sequence is executed, driver will end job prematurely, if ctx->translen is higher than 1, because "aborting" flag is still set from previous stop streaming command. Fix that by clearing "aborting" flag in start streaming handler. Fixes: 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf framework test device") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: seco-cec: Add a missing 'release_region()' in an error handling pathChristophe JAILLET
commit a9cc4cbcdfd378b65fd4e398800cfa14e3855042 upstream. At the beginning of the probe function, we have a call to 'request_muxed_region(BRA_SMB_BASE_ADDR, 7, "CEC00001")()' A corresponding 'release_region()' is performed in the remove function but is lacking in the error handling path. Add it. Fixes: b03c2fb97adc ("media: add SECO cec driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-02-24media: am437x-vpfe: Setting STD to current value is not an errorBenoit Parrot
commit 13aa21cfe92ce9ebb51824029d89f19c33f81419 upstream. VIDIOC_S_STD should not return an error if the value is identical to the current one. This error was highlighted by the v4l2-compliance test. Signed-off-by: Benoit Parrot <bparrot@ti.com> Acked-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-01-31media: bdisp: fix memleak on releaseJohan Hovold
commit 11609a7e21f8cea42630350aa57662928fa4dc63 upstream. If a process is interrupted while accessing the video device and the device lock is contended, release() could return early and fail to free related resources. Note that the return value of the v4l2 release file operation is ignored. Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Cc: stable <stable@vger.kernel.org> # 4.2 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-01-31media: venus: remove invalid compat_ioctl32 handlerArnd Bergmann
commit 4adc0423de92cf850d1ef5c0e7cb28fd7a38219e upstream. v4l2_compat_ioctl32() is the function that calls into v4l2_file_operations->compat_ioctl32(), so setting that back to the same function leads to a trivial endless loop, followed by a kernel stack overrun. Remove the incorrect assignment. Cc: stable@vger.kernel.org Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files") Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2020-01-09media: vivid: Set vid_cap_streaming and vid_out_streaming to trueVandana BN
commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream. When vbi stream is started, followed by video streaming, the vid_cap_streaming and vid_out_streaming were not being set to true, which would cause the video stream to stop when vbi stream is stopped. This patch allows to set vid_cap_streaming and vid_out_streaming to true. According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)' checks are a left-over from the original vivid development and should never have been there. Signed-off-by: Vandana BN <bnvandana@gmail.com> Cc: <stable@vger.kernel.org> # for v3.18 and up Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-02media: vivid: Fix wrong locking that causes race conditions on streaming stopAlexander Popov
commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream. There is the same incorrect approach to locking implemented in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(). These functions are called during streaming stopping with vivid_dev.mutex locked. And they all do the same mistake while stopping their kthreads, which need to lock this mutex as well. See the example from vivid_stop_generating_vid_cap(): /* shutdown control thread */ vivid_grab_controls(dev, false); mutex_unlock(&dev->mutex); kthread_stop(dev->kthread_vid_cap); dev->kthread_vid_cap = NULL; mutex_lock(&dev->mutex); But when this mutex is unlocked, another vb2_fop_read() can lock it instead of vivid_thread_vid_cap() and manipulate the buffer queue. That causes a use-after-free access later. To fix those issues let's: 1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(); 2. use mutex_trylock() with schedule_timeout_uninterruptible() in the loops of the vivid kthread handlers. Signed-off-by: Alexander Popov <alex.popov@linux.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v3.18 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-12-02media: rcar_drif: fix a memory disclosureKangjie Lu
commit d39083234c60519724c6ed59509a2129fd2aed41 upstream. "f->fmt.sdr.reserved" is uninitialized. As other peer drivers like msi2500 and airspy do, the fix initializes it to avoid memory disclosures. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-10-05media: omap3isp: Set device on omap3isp subdevsSakari Ailus
[ Upstream commit e9eb103f027725053a4b02f93d7f2858b56747ce ] The omap3isp driver registered subdevs without the dev field being set. Do that now. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: aspeed-video: address a protential usage of an unitialized varMauro Carvalho Chehab
[ Upstream commit 31b8b0bd6e55c3ea5a08bb8141fa5d3c90600e3b ] While this might not occur in practice, if the device is doing the right thing, it would be teoretically be possible to have both hsync_counter and vsync_counter negatives. If this ever happen, ctrl will be undefined, but the driver will still call: aspeed_video_update(video, VE_CTRL, 0, ctrl); Change the code to prevent this to happen. This was warned by cppcheck: [drivers/media/platform/aspeed-video.c:653]: (error) Uninitialized variable: ctrl Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: omap3isp: Don't set streaming state on random subdevsSakari Ailus
[ Upstream commit 7ef57be07ac146e70535747797ef4aee0f06e9f9 ] The streaming state should be set to the first upstream sub-device only, not everywhere, for a sub-device driver itself knows how to best control the streaming state of its own upstream sub-devices. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: vsp1: fix memory leak of dl on error return pathColin Ian King
[ Upstream commit 70c55c1ad1a76e804ee5330e134674f5d2741cb7 ] Currently when the call vsp1_dl_body_get fails and returns null the error return path leaks the allocation of dl. Fix this by kfree'ing dl before returning. Addresses-Coverity: ("Resource leak") Fixes: 5d7936b8e27d ("media: vsp1: Convert display lists to use new body pool") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: fdp1: Reduce FCP not found message level to debugGeert Uytterhoeven
[ Upstream commit 4fd22938569c14f6092c05880ca387409d78355f ] When support for the IPMMU is not enabled, the FDP driver may be probe-deferred multiple times, causing several messages to be printed like: rcar_fdp1 fe940000.fdp1: FCP not found (-517) rcar_fdp1 fe944000.fdp1: FCP not found (-517) Fix this by reducing the message level to debug level, as is done in the VSP1 driver. Fixes: 4710b752e029f3f8 ("[media] v4l: Add Renesas R-Car FDP1 Driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: mtk-mdp: fix reference count on old device treeMatthias Brugger
[ Upstream commit 864919ea0380e62adb2503b89825fe358acb8216 ] of_get_next_child() increments the reference count of the returning device_node. Decrement it in the check if we are using the old or the new DTB. Fixes: ba1f1f70c2c0 ("[media] media: mtk-mdp: Fix mdp device tree") Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Houlong Wei <houlong.wei@mediatek.com> [hverkuil-cisco@xs4all.nl: use node instead of parent as temp variable] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: media/platform: fsl-viu.c: fix build for MICROBLAZERandy Dunlap
[ Upstream commit 6898dd580a045341f844862ceb775144156ec1af ] arch/microblaze/ defines out_be32() and in_be32(), so don't do that again in the driver source. Fixes these build warnings: ../drivers/media/platform/fsl-viu.c:36: warning: "out_be32" redefined ../arch/microblaze/include/asm/io.h:50: note: this is the location of the previous definition ../drivers/media/platform/fsl-viu.c:37: warning: "in_be32" redefined ../arch/microblaze/include/asm/io.h:53: note: this is the location of the previous definition Fixes: 29d750686331 ("media: fsl-viu: allow building it with COMPILE_TEST") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: vivid: work around high stack usage with clangArnd Bergmann
[ Upstream commit 1a03f91c2c2419c3709c4554952c66695575e91c ] Building a KASAN-enabled kernel with clang ends up in a case where too much is inlined into vivid_thread_vid_cap() and the stack usage grows a lot, possibly when the register allocation fails to produce efficient code and spills a lot of temporaries to the stack. This uses more than twice the amount of stack than the sum of the individual functions when they are not inlined: drivers/media/platform/vivid/vivid-kthread-cap.c:766:12: error: stack frame size of 2208 bytes in function 'vivid_thread_vid_cap' [-Werror,-Wframe-larger-than=] Marking two of the key functions in here as 'noinline_for_stack' avoids the pathological case in clang without any apparent downside for gcc. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: vivid:add sanity check to avoid divide error and set value to 1 if 0.Vandana BN
[ Upstream commit aa9c2182c45421d54ed27c2a1765f7adedce291b ] Syzbot reported divide error in vivid_thread_vid_cap, which has been seen only once and does not have a reproducer. This patch adds sanity checks for the denominator value with WARN_ON if it is 0 and replaces it with 1. divide error: 0000 [#1] PREEMPT SMP KASAN kobject: 'tx-0' (0000000017161f7f): kobject_uevent_env CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x284 drivers/media/platform/vivid/vivid-kthread-cap.c:789 Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 RSP: 0018:ffff88808b4afd68 EFLAGS: 00010246 kobject: 'tx-0' (0000000017161f7f): fill_kobj_path: path = '/devices/virtual/net/gre0/queues/tx-0' RAX: 000000de5a6f8e00 RBX: 0000000100047b22 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000004 RBP: ffff88808b4aff00 R08: ffff88804862e1c0 R09: ffffffff89997008 R10: ffffffff89997010 R11: 0000000000000001 R12: 00000000fffffffc R13: ffff8880a17e0500 R14: ffff88803e40f760 R15: ffff8882182b0140 FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004cdc90 CR3: 000000005d827000 CR4: 00000000001426f0 Call Trace: kobject: 'gretap0' (00000000d7549098): kobject_add_internal: parent: 'net', set: 'devices' kobject: 'loop2' (0000000094ed4ee4): kobject_uevent_env kobject: 'loop2' (0000000094ed4ee4): fill_kobj_path: path = '/devices/virtual/block/loop2' kthread+0x357/0x430 kernel/kthread.c:246 kobject: 'gretap0' (00000000d7549098): kobject_uevent_env ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: kobject: 'gretap0' (00000000d7549098): fill_kobj_path: path = '/devices/virtual/net/gretap0' ---[ end trace bc5c8b25b64d768f ]--- kobject: 'loop1' (0000000032036b86): kobject_uevent_env RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x2840 drivers/media/platform/vivid/vivid-kthread-cap.c:789 kobject: 'loop1' (0000000032036b86): fill_kobj_path: path = '/devices/virtual/block/loop1' Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 kobject: 'loop0' (00000000dd9927c3): kobject_uevent_env RSP: 0018:ffff88808b4afd68 EFLAGS: 00010246 RAX: 000000de5a6f8e00 RBX: 0000000100047b22 RCX: 0000000000000000 kobject: 'queues' (000000007ed20666): kobject_add_internal: parent: 'gretap0', set: '<NULL>' RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000004 RBP: ffff88808b4aff00 R08: ffff88804862e1c0 R09: ffffffff89997008 kobject: 'loop0' (00000000dd9927c3): fill_kobj_path: path = '/devices/virtual/block/loop0' R10: ffffffff89997010 R11: 0000000000000001 R12: 00000000fffffffc kobject: 'queues' (000000007ed20666): kobject_uevent_env R13: ffff8880a17e0500 R14: ffff88803e40f760 R15: ffff8882182b0140 FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 kobject: 'loop5' (00000000a41f9e79): kobject_uevent_env CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kobject: 'queues' (000000007ed20666): kobject_uevent_env: filter function caused the event to drop! CR2: 00000000004cdc90 CR3: 000000005d827000 CR4: 00000000001426f0 kobject: 'loop5' (00000000a41f9e79): fill_kobj_path: path = '/devices/virtual/block/loop5' Reported-by: syz...@syzkaller.appspotmail.com Signed-off-by: Vandana BN <bnvandana@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05media: exynos4-is: fix leaked of_node referencesWen Yang
[ Upstream commit da79bf41a4d170ca93cc8f3881a70d734a071c37 ] The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/media/platform/exynos4-is/fimc-is.c:813:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 807, but without a corresponding object release within this function. drivers/media/platform/exynos4-is/fimc-is.c:870:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 807, but without a corresponding object release within this function. drivers/media/platform/exynos4-is/fimc-is.c:885:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 807, but without a corresponding object release within this function. drivers/media/platform/exynos4-is/media-dev.c:545:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 541, but without a corresponding object release within this function. drivers/media/platform/exynos4-is/media-dev.c:528:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 499, but without a corresponding object release within this function. drivers/media/platform/exynos4-is/media-dev.c:534:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 499, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-21media: stm32-dcmi: fix irq = 0 caseFabien Dessenne
commit dbb9fcc8c2d8d4ea1104f51d4947a8a8199a2cb5 upstream. Manage the irq = 0 case, where we shall return an error. Fixes: b5b5a27bee58 ("media: stm32-dcmi: return appropriate error codes during probe") Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reported-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-06-17 06:41:01 +0000