- 10 Nov, 2019 4 commits
-
-
Navid Emamdoost authored
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: d2b4387f ("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>
-
Pragnesh Patel authored
$id doesn't match the actual filename, so update the $id Signed-off-by:
Pragnesh Patel <pragnesh.patel@sifive.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
zhong jiang authored
It's more clear to use FIELD_SIZEOF instead of its implementation. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Simon Horman authored
Remove the SH Mobile CEU bindings documentation as the corresponding driver was removed v5.1 by the following commit: 43a445f1 ("media: sh_mobile_ceu_camera: remove obsolete soc_camera driver") Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 09 Nov, 2019 19 commits
-
-
Clément Péron authored
Beelink GS1 ships with a NEC remote control. Add the rc keymap to the device-tree. Signed-off-by:
Clément Péron <peron.clem@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Clément Péron authored
Beelink GS1 Andoid TV Box ships with a simple NEC remote. Signed-off-by:
-
Jan Pieter van Woerkom authored
remove unused code Signed-off-by:
Jan Pieter van Woerkom <jp@jpvw.nl> Signed-off-by:
-
Colin Ian King authored
An earlier commit hard coded a return 0 to function flexcop_usb_i2c_req even though the an -EIO was intended to be returned in the case where ret != buflen. Fix this by replacing the return 0 with the return of ret to return the error return code. Addresses-Coverity: ("Unused value") Fixes: b430eaba ("[media] flexcop-usb: don't use stack for DMA") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Oliver Neukum authored
The driver needs an isochronous endpoint to be present. It will oops in its absence. Add checking for it. Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Philipp Zabel authored
The irqlock spinlock has been unused from the start. Remove it. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Mike Isely authored
In some device configurations there's no radio or radio support in the driver. That's OK, as the driver sets itself up accordingly. However on tear-down in these caes it's still trying to tear down radio related context when there isn't anything there, leading to dereferences through a null pointer and chaos follows. How this bug survived unfixed for 11 years in the pvrusb2 driver is a mystery to me. [hverkuil: fix two checkpatch warnings] Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Neil Armstrong authored
Update the path to the ao-cec bindings after conversion to DT Schemas. Suggested-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Arnd Bergmann authored
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: 7472c1c6 ("[media] media: venus: vdec: add video decoder files") Fixes: aaaa93ed ("[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:
-
Jernej Skrabec authored
Hold buf flag is set on output queue, not capture. Fix that. Fixes: f07602ac ("media: v4l2-mem2mem: add new_frame detection") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Dafna Hirschfeld authored
The field kthread_sen in the vimc_sen_device is not set and used. So remove the field and the code that check if it is non NULL Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Cc: <stable@vger.kernel.org> # for v5.4 and up Signed-off-by:
-
Francois Buergisser authored
The picture order count table only makes sense for profiles higher than Baseline. This is confirmed by the H.264 specification (See 8.2.1 Decoding process for picture order count), which clarifies how POC are used for features not present in Baseline. """ Picture order counts are used to determine initial picture orderings for reference pictures in the decoding of B slices, to represent picture order differences between frames or fields for motion vector derivation in temporal direct mode, for implicit mode weighted prediction in B slices, and for decoder conformance checking. """ As a side note, this change matches various vendors downstream codebases, including ChromiumOS and IMX VPU libraries. Fixes: dea0a82f ("media: hantro: Add support for H264 decoding on G1") Signed-off-by:
Francois Buergisser <fbuergisser@chromium.org> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Tested-by:
-
Francois Buergisser authored
The setting of the motion vectors usage and the setting of motion vectors address are currently done under different conditions. When decoding pre-recorded videos, this results of leaving the motion vectors address unset, resulting in faulty memory accesses. Fix it by using the same condition everywhere, which matches the profiles that support motion vectors. Fixes: dea0a82f ("media: hantro: Add support for H264 decoding on G1") Signed-off-by:
-
Jonas Karlman authored
TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels, change frmsize max_width/max_height to match TRM at [1]. This patch makes it possible to decode the 4096x2304 sample at [2]. [1] http://www.t-firefly.com/download/firefly-rk3288/docs/TRM/rk3288-chapter-25-video-encoder-decoder-unit-(vcodec).pdf [2] https://4ksamples.com/puppies-bath-in-4k/ Fixes: 76032793 ("media: hantro: Enable H264 decoding on rk3288") Signed-off-by:
-
Jonas Karlman authored
Scaling list supplied from userspace should be in matrix order and can be used without applying the inverse scanning process. The HW also only support 8x8 scaling list for the Y component, indices 0 and 1 in the scaling list supplied from userspace. Remove reordering and write the scaling matrix in an order expected by the VPU, also only allocate memory for the two 8x8 lists supported. Fixes: a9471e25 ("media: hantro: Add core bits to support H264 decoding") Signed-off-by:
-
Jonas Karlman authored
Documentation now defines the expected order of scaling lists, change to use correct indices. Fixes: 6eb9b758 ("media: cedrus: Add H264 decoding support") Signed-off-by:
-
Jonas Karlman authored
Clarify that the expected order of scaling lists should follow the order they are listed in the H264 standard. The expected scaling list order, for 4x4: Intra Y, Intra Cb, Intra Cr, Inter Y, Inter Cb, Inter Cr, for 8x8: Intra Y, Inter Y, Intra Cb, Inter Cb, Intra Cr, Inter Cr. Also clarify that the values in a scaling list should be in matrix order, the same value order that vaapi, vdpau and nvdec use. Signed-off-by:
-
Jernej Skrabec authored
Accessing capture queue structue directly is not safe. Use helpers for that. Acked-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Jernej Skrabec authored
It seems that for some H264 videos at least one bitstream parsing trigger must be called in order to be decoded correctly. There is no explanation why this helps, but it was observed that two sample videos with this fix are now decoded correctly and there is no regression with others. Acked-by:
-
- 08 Nov, 2019 17 commits
-
-
Hans Verkuil authored
Fix typo: putss -> puts Signed-off-by:
-
Ricardo Ribalda Delgado authored
After adding a const pointer to ctrl_ptr, lets use it where it make sense. Suggested-by:
Ricardo Ribalda Delgado <ribalda@kernel.org> Signed-off-by:
-
Ricardo Ribalda Delgado authored
Describe p_area field from v4l2_ext_ctrl Signed-off-by:
-
Ricardo Ribalda Delgado authored
Allow accessing V4L2_CTRL_TYPE_AREA controls without any casting. Signed-off-by:
-
Ricardo Ribalda Delgado authored
This control represents a generic read/write area. Suggested-by:
-
Ricardo Ribalda Delgado authored
This pointer is used to point to data that is constant. Thanks to this we can avoid a lot of casting and we make more clear when the data is constant or variable. Suggested-by:
-
Ricardo Ribalda Delgado authored
This allows setting the default value on compound controls created via v4l2_ctrl_new_custom. Signed-off-by:
-
Seung-Woo Kim authored
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: 9832e155 ("[media] media-device: split media initialization and registration") Signed-off-by:
-
Alexander Popov authored
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 authored
Refactor some of the vivid_create_instance code by using a new vivid_create_queue() helper function. Also add some sanity checks for the node_types vs input/output_types module options. This patch resolves these two smatch parse errors: drivers/media/platform/vivid/vivid-core.c:1679 vivid_create_instance() parse error: OOM: 3002600Kb sm_state_count = 6160113 drivers/media/platform/vivid/vivid-core.c: drivers/media/platform/vivid/vivid-core.c:1679 vivid_create_instance() parse error: __split_smt: function too hairy. Giving up after 33 seconds Signed-off-by:
-
Colin Ian King authored
Macros MSG_SMS_ENBALE_TS_INTERFACE_REQ and MSG_SMS_ENBALE_TS_INTERFACE_RES contain a spelling mistake. Fix these by replacing ENBALE with ENABLE. Signed-off-by:
-
Hans Verkuil authored
Drop two dprintk's that relied on a non-NULL mantis pointer when it was in fact a NULL pointer. Fix those warnings: drivers/media/pci/mantis/mantis_cards.c:73 mantis_irq_handler() error: we previously assumed 'mantis' could be null (see line 72) drivers/media/pci/mantis/hopper_cards.c:64 hopper_irq_handler() error: we previously assumed 'mantis' could be null (see line 63) Signed-off-by:
-
Hans Verkuil authored
Initialize ret to 0 to fix this smatch error: drivers/media/i2c/ov6650.c:853 ov6650_video_probe() error: uninitialized symbol 'ret'. Signed-off-by:
-
Hans Verkuil authored
This patch fixes this error: drivers/media/platform/ti-vpe/vpdma.c:767 dump_dtd() error: '%pad' expects argument of type 'dma_addr_t*', argument 2 has type 'uint*' dtd->start_addr is a u32, so no need for %pad. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Hans Verkuil authored
Use sizeof instead of ARRAY_SIZE to fix this smatch warning: drivers/media/usb/em28xx/em28xx-i2c.c:952 em28xx_do_i2c_scan() warn: calling memset(x, y, ARRAY_SIZE()); Do the same for the em28xx_hash_mem() call in the same function. smatch didn't pick that up, but there too it should use sizeof instead of ARRAY_SIZE. Signed-off-by:
-
Hans Verkuil authored
Use sizeof instead of ARRAY_SIZE to fix this smatch warning: drivers/media/rc/ite-cir.c:385 ite_tx_ir() warn: calling memset(x, y, ARRAY_SIZE()); Signed-off-by:
-
Hans Verkuil authored
Drop the "id >= 0" test in two conditions to fix these warnings: drivers/media/platform/mtk-vpu/mtk_vpu.c:276 vpu_ipi_register() warn: always true condition '(id >= 0) => (0-u32max >= 0)' drivers/media/platform/mtk-vpu/mtk_vpu.c:401 vpu_wdt_reg_handler() warn: always true condition '(id >= 0) => (0-u32max >= 0)' Signed-off-by:
-
