- 19 Dec, 2017 2 commits
-
-
Mauro Carvalho Chehab authored
This debug option is there for a long time, but it is only enabled by editing the source code. Due to that, a breakage inside its code was only noticed years after a change at the ULE handling logic. Make it a Kconfig parameter, as it makes easier for advanced users to enable, and allow test if the compilation won't be broken in the future. Signed-off-by:Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
commit efb9ab67 ("[media] dvb_net: prepare to split a very complex function") changed the ULE handling logic, simplifying it. However, it forgot to keep the initialization for .priv and to zero .ule_hist fields. The lack of .priv cause crashes if dvb_net_ule() is called, as the function assuems that .priv field to be initialized. With regards to .ule_hist, the current logic is broken and don't even compile if ULE_DEBUG. Fix it by making the debug vars static again, and be sure to pass iov parameter to dvb_net_ule_check_crc(). Fixes: efb9ab67 ("[media] dvb_net: prepare to split a very complex function") Suggested-by:
Ron Economos <w6rz@comcast.net> Signed-off-by:
-
- 18 Dec, 2017 38 commits
-
-
Andi Shyti authored
Replace the original license statement with the SPDX identifier. Update also the copyright owner adding myself as co-owner of the copyright. Signed-off-by:
Andi Shyti <andi.shyti@samsung.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
There is no reason to hold the lock while we wait for the IR to transmit. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Sean Young authored
This is code existed for when drivers would send less than the whole buffer; no driver does this any more, so this is redundant. Drivers should return -EINVAL if they cannot send the entire buffer. Signed-off-by:
-
Sean Young authored
If memdup_user() fails, txbuf will be an error pointer and passed to kfree. Reported-by:
-
Sean Young authored
The TX loop is more complex than it should. Simplify it. Signed-off-by:
-
Sean Young authored
The semantics for lirc IR transmit with raw IR is that the write call should block until the IR is transmitted. Some drivers have no idea when this actually is (e.g. mceusb), so there is a wait. This is useful for userspace, as it might want to send a IR button press, a gap of a predefined number of milliseconds, and then send a repeat message. It turns out that for transmitting scancodes this feature is even more useful, as user space has no idea how long the IR is. So, maintain the existing semantics for IR scancode transmit. Signed-off-by:
-
Sean Young authored
rc_keydown() can be called from interrupt context, by e.g. an rc scancode driver. Since commit b2c96ba352b5 ("media: cec: move cec autorepeat handling to rc-core"), the del_timer_sync() call is not happy about being called in interrupt connect. del_timer() will suffice. WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1285 del_timer_sync+0x1d/0x40 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.15.0-rc1+ #1 Hardware name: /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011 task: ffffffffa3e10480 task.stack: ffffffffa3e00000 RIP: 0010:del_timer_sync+0x1d/0x40 RSP: 0018:ffff8b396bc03db0 EFLAGS: 00010046 RAX: 0000000080010000 RBX: ffff8b394d70e410 RCX: 0000000000000073 RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8b394d70e410 RBP: 0000000000000001 R08: ffffffffc0616000 R09: ffff8b396bfa3000 R10: 0000000000000000 R11: 0000000000000390 R12: ffff8b394f003800 R13: 0000000000000000 R14: ffff8b3771c19630 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b396bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1944469000 CR3: 00000001ebe09000 CR4: 00000000000006f0 Call Trace: <IRQ> ir_do_keyup.part.5+0x22/0x90 [rc_core] rc_keyup+0x37/0x50 [rc_core] usb_rx_callback_intf0+0x79/0x90 [imon] __usb_hcd_giveback_urb+0x90/0x130 uhci_giveback_urb+0xab/0x250 uhci_scan_schedule.part.34+0x806/0xb00 uhci_irq+0xab/0x150 usb_hcd_irq+0x22/0x30 __handle_irq_event_percpu+0x3a/0x180 handle_irq_event_percpu+0x30/0x70 handle_irq_event+0x27/0x50 handle_fasteoi_irq+0x6b/0x110 handle_irq+0xa5/0x100 do_IRQ+0x41/0xc0 common_interrupt+0x96/0x96 </IRQ> RIP: 0010:cpuidle_enter_state+0x9a/0x2d0 RSP: 0018:ffffffffa3e03e88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda RAX: ffff8b396bc1a000 RBX: 00000010da7bcd63 RCX: 00000010da7bccf6 RDX: 00000010da7bcd63 RSI: 00000010da7bcd63 RDI: 0000000000000000 RBP: ffff8b394f587400 R08: 0000000000000000 R09: 0000000000000002 R10: ffffffffa3e03e48 R11: 0000000000000390 R12: 0000000000000003 R13: ffffffffa3ebf018 R14: 0000000000000000 R15: 00000010da7ba772 ? cpuidle_enter_state+0x8d/0x2d0 do_idle+0x17b/0x1d0 cpu_startup_entry+0x6f/0x80 start_kernel+0x4a7/0x4c7 secondary_startup_64+0xa5/0xb0 Code: e7 5b 5d 41 5c e9 84 88 05 00 0f 1f 40 00 66 66 66 66 90 65 8b 05 e4 6f ef 5c a9 00 00 0f 00 53 48 89 fb 74 16 f6 47 22 20 75 10 <0f> ff 48 89 df e8 89 f1 ff ff 85 c0 79 0e f3 90 48 89 df e8 7b Fixes: b2c96ba352b5 ("media: cec: move cec autorepeat handling to rc-core") Signed-off-by: -
Sean Young authored
Since commit 9c7fd60e951d ("media: rc: Replace timeval with ktime_t in imon.c"), the function tv2int() is no longer used. Remove it. Signed-off-by: -
Sean Young authored
Another device with the 0xffdc device id, this one with 0x26 in the config byte. Its an iMON Inside + iMON IR. It does respond to rc-6, but seems to produce random garbage rather than a scancode. Signed-off-by:
-
Mauro Carvalho Chehab authored
The agreed format is to use /* */ comments inside header files. Unfortunately, I ended by using // on a few ones. Reported-by:
-
Flavio Ceolin authored
s5p_jpeg_runtime_resume() does not call clk_disable_unprepare() for jpeg->clocks[0] when one of the clk_prepare_enable() fails. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Flavio Ceolin <flavio.ceolin@intel.com> Acked-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Simon Shields authored
If the subdev is not yet present (probably because the subdev module has not yet been loaded), the pipe will be NULL. Make sure that this is not the case before attempting to call the op. Signed-off-by:
Simon Shields <simon@lineageos.org> Signed-off-by:
-
Marek Szyprowski authored
Support for Exynos4212 SoCs has been removed by commit bca9085e ("ARM: dts: exynos: remove Exynos4212 support (dead code)"), so there is no need to keep remaining dead code related to this SoC version. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Shuah Khan authored
Driver calls request_firmware() whenever the device is opened for the first time. As the device gets opened and closed, dev->num_inst == 1 is true several times. This is not necessary since the firmware is saved in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by the request_firmware() to dev->fw_buf. fw_buf sticks around until it gets released from s5p_mfc_remove(), hence there is no need to keep requesting firmware and copying it to fw_buf. This might have been overlooked when changes are made to free fw_buf from the device release interface s5p_mfc_release(). Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state. Change _probe() to load firmware once fw_buf has been allocated. s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init hardware which is the step where firmware is written to the device. This addresses the mfc_mutex contention due to repeated request_firmware() calls from open() in the following circular locking warning: [ 552.194115] qtdemux0:sink/2710 is trying to acquire lock: [ 552.199488] (&dev->mfc_mutex){+.+.}, at: [<bf145544>] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.207459] but task is already holding lock: [ 552.213264] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8 [ 552.220284] which lock already depends on the new lock. [ 552.228429] the existing dependency chain (in reverse order) is: [ 552.235881] -> #2 (&mm->mmap_sem){++++}: [ 552.241259] __might_fault+0x80/0xb0 [ 552.245331] filldir64+0xc0/0x2f8 [ 552.249144] call_filldir+0xb0/0x14c [ 552.253214] ext4_readdir+0x768/0x90c [ 552.257374] iterate_dir+0x74/0x168 [ 552.261360] SyS_getdents64+0x7c/0x1a0 [ 552.265608] ret_fast_syscall+0x0/0x28 [ 552.269850] -> #1 (&type->i_mutex_dir_key#2){++++}: [ 552.276180] down_read+0x48/0x90 [ 552.279904] lookup_slow+0x74/0x178 [ 552.283889] walk_component+0x1a4/0x2e4 [ 552.288222] link_path_walk+0x174/0x4a0 [ 552.292555] path_openat+0x68/0x944 [ 552.296541] do_filp_open+0x60/0xc4 [ 552.300528] file_open_name+0xe4/0x114 [ 552.304772] filp_open+0x28/0x48 [ 552.308499] kernel_read_file_from_path+0x30/0x78 [ 552.313700] _request_firmware+0x3ec/0x78c [ 552.318291] request_firmware+0x3c/0x54 [ 552.322642] s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc] [ 552.328358] s5p_mfc_open+0x4e4/0x550 [s5p_mfc] [ 552.333394] v4l2_open+0xa0/0x104 [videodev] [ 552.338137] chrdev_open+0xa4/0x18c [ 552.342121] do_dentry_open+0x208/0x310 [ 552.346454] path_openat+0x28c/0x944 [ 552.350526] do_filp_open+0x60/0xc4 [ 552.354512] do_sys_open+0x118/0x1c8 [ 552.358586] ret_fast_syscall+0x0/0x28 [ 552.362830] -> #0 (&dev->mfc_mutex){+.+.}: -> #0 (&dev->mfc_mutex){+.+.}: [ 552.368379] lock_acquire+0x6c/0x88 [ 552.372364] __mutex_lock+0x68/0xa34 [ 552.376437] mutex_lock_interruptible_nested+0x1c/0x24 [ 552.382086] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.386939] v4l2_mmap+0x54/0x88 [videodev] [ 552.391601] mmap_region+0x3a8/0x638 [ 552.395673] do_mmap+0x330/0x3a4 [ 552.399400] vm_mmap_pgoff+0x90/0xb8 [ 552.403472] SyS_mmap_pgoff+0x90/0xc0 [ 552.407632] ret_fast_syscall+0x0/0x28 [ 552.411876] other info that might help us debug this: [ 552.419848] Chain exists of: &dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem [ 552.431200] Possible unsafe locking scenario: [ 552.437092] CPU0 CPU1 [ 552.441598] ---- ---- [ 552.446104] lock(&mm->mmap_sem); [ 552.449484] lock(&type->i_mutex_dir_key#2); [ 552.456329] lock(&mm->mmap_sem); [ 552.462222] lock(&dev->mfc_mutex); [ 552.465775] *** DEADLOCK *** Signed-off-by:Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Shuah Khan authored
s5p_mfc_load_firmware() will not get called if fw_buf.virt allocation fails. The allocation happens very early on in the probe routine and probe fails if allocation fails. There is no need to check if it is null in s5p_mfc_load_firmware(). Remove the check. Signed-off-by:
-
Marek Szyprowski authored
Setting both V4L2_CAP_VIDEO_CAPTURE_MPLANE and V4L2_CAP_VIDEO_OUTPUT_MPLANE for mem2mem video nodes is obsolete since commit f0476a83 ("[media] V4L: Add capability flags for memory-to-memory devices"). It was enough time to adapt all users to the new flags, so drop the legacy caps for now to match other mem2mem drivers. Signed-off-by:
-
Marek Szyprowski authored
Setting both V4L2_CAP_VIDEO_CAPTURE_MPLANE and V4L2_CAP_VIDEO_OUTPUT_MPLANE for mem2mem video nodes is obsolete since commit f0476a83 ("[media] V4L: Add capability flags for memory-to-memory devices"). It was enough time to adapt all users to the new flags, so drop the legacy caps for now to match other mem2mem drivers. Signed-off-by:
-
Arnd Bergmann authored
We copy the subdev frame format from a partially initialized structure, which is not entirely well-defined. Older compilers like gcc-4.4 can copy uninitialized stack data here and warn about it: drivers/media/platform/exynos4-is/fimc-isp.c: In function 'fimc_isp_subdev_open': drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[10u]' may be used uninitialized in this function drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[9u]' may be used uninitialized in this function ... drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[0u]' may be used uninitialized in this function drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.xfer_func' may be used uninitialized in this function On newer compilers, only the initialized fields get copied, but we should not rely on that, so this changes the code to zero-out the remaining fields first. Fixes: 9a761e43 ("[media] exynos4-is: Add Exynos4x12 FIMC-IS driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Sylwester Nawrocki authored
This patch fixes the menu_skip_mask field initialization and addresses a following issue found by the SVACE static analysis: * NO_EFFECT.SELF: assignment to self in expression 'cfg.menu_skip_mask = cfg.menu_skip_mask' No effect at drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:2083 Signed-off-by:
-
Jia-Ju Bai authored
The driver may sleep under a spinlock. The function call path is: bdisp_device_run (acquire the spinlock) bdisp_hw_update bdisp_hw_save_request devm_kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by:Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Stanimir Varbanov authored
Currently videobuf2-dma-sg checks for dma direction for every single page and videobuf2-dc lacks any dma direction checks and calls set_page_dirty_lock unconditionally. Thus unify and align the invocations of set_page_dirty_lock for videobuf2-dc, videobuf2-sg memory allocators with videobuf2-vmalloc, i.e. the pattern used in vmalloc has been copied to dc and dma-sg. Suggested-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
The pvrusb2 code appears to have a some old workaround code for xawtv that causes a WARN() due to an unrecognized pixelformat 0 in v4l2_ioctl.c. Since all other MPEG drivers fill this in correctly, it is a safe assumption that this particular problem no longer exists. While I'm at it, clean up the code a bit. Signed-off-by:
-
Philipp Zabel authored
V4L2_BUF_FLAG_LAST is a signal from the driver to userspace for buffers on the capture queue. When userspace queues back a capture buffer with the flag set, we should clear it. Otherwise, if userspace restarts streaming after EOS, without reallocating the buffers, mem2mem devices will erroneously signal EOS prematurely, as soon as the already flagged buffer is dequeued. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
The mvcol buffer needs to be placed behind the chroma plane(s) when decoding MPEG-4, same as for the h.264 decoder. Use the real offset with the required rounding. Signed-off-by:
-
Philipp Zabel authored
The MPEG-4 decoder mvcol buffer was registered, but its size not added to a frame buffer allocation. This could cause the decoder to write past the end of the allocated buffer for large frame sizes. Signed-off-by:
-
Philipp Zabel authored
We need internal frames to be rounded up to full macroblocks for MPEG-4 decoding as well. Signed-off-by:
-
Philipp Zabel authored
Since bytesperline always fulfills VDOA width requirements, detile the whole buffer instead of limiting to visible width. This stops TRY_FMT from returning -EINVAL for YUYV capture buffers that are not a multiple of 16 wide. An alternative would be to always round up width to stride, as we report the valid image rectange via G_SELECTION (V4L2_SEL_TGT_COMPOSE_DEFAULT), but that would require all applications to handle the compose default rectangle properly. Signed-off-by:
-
Lucas Stach authored
The current driver implementation expects at least one buffer on all queues to start streaming. Properly signal this to the vb2 core, to avoid confusion when streamon is racing with qbuf. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Flavio Ceolin authored
pxa_camera_probe() was not calling pxa_camera_deactivate(), responsible to call clk_disable_unprepare(), on the failure path. This was leading to unbalancing source clock. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Jacopo Mondi authored
videobuf2 core reports an error when not all buffers have been returned to the framework: drivers/media/v4l2-core/videobuf2-core.c:1651 WARN_ON(atomic_read(&q->owned_by_drv_count)) Fix this returning all buffers currently in capture queue. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
When we split VB2 into an independent streaming module and a V4L2 one, some vb2-core functions started to have a wrong description: they're meant to be used only by the API-specific parts of VB2, like vb2-v4l2, as the functions that V4L2 drivers should use are all under videobuf2-v4l2.h. Correct their descriptions. Acked-by:
-
Mauro Carvalho Chehab authored
As kernel-doc doesn't support documenting #define values, and using enum makes easier to identify where the values are used, convert V4L2_MBUS_FRAME_DESC_FL_* to enum, and use BIT() macro. While here, fix the description at v4l2_mbus_frame_desc_entry, in order to match what's described for V4L2_MBUS_FRAME_DESC_FL_LEN_MAX. Signed-off-by: -
Mauro Carvalho Chehab authored
Convert V4L2_SUBDEV_IO_PIN_* to enums, use BIT() and document via kernel-doc. Signed-off-by: -
Mauro Carvalho Chehab authored
ownner -> owner Acked-by:
-
Mauro Carvalho Chehab authored
Despite the struct says "color16", it was actually using 32 bits for each color. Fix it. Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Acked-by:
-
Mauro Carvalho Chehab authored
The color structs right now are just "color" and "color16". That may lead into conflicts, and don't define precisely what they meant. As those are used by two drivers (vivid and vimc), this is even on a somewhat public header! So rename them to: color -> tpg_rbg_color8 color16 -> tpg_rbg_color16 Acked-by:
-
Mauro Carvalho Chehab authored
The v4l2-tpg*.h headers are meant to be used only internally by vivid and vimc. There's no sense keeping them together with the V4L2 kAPI headers. Also, one header includes the other as they're meant to be used together. So, merge them. Acked-by:
-
Mauro Carvalho Chehab authored
Add cross-references where needed and add periods at the end of each kernel-doc paragraph, in order to make it coherent with other VB2 descriptions. Acked-by:
-
