summaryrefslogtreecommitdiff
path: root/drivers/media
AgeCommit message (Collapse)AuthorFilesLines
2020-02-28media: sti: bdisp: fix a possible sleep-in-atomic-context bug in ↵Jia-Ju Bai1-3/+3
bdisp_device_run() [ Upstream commit bb6d42061a05d71dd73f620582d9e09c8fbf7f5b ] 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: Sasha Levin <sashal@kernel.org>
2020-02-28media: i2c: mt9v032: fix enum mbus codes and frame sizesEugen Hristev1-2/+8
[ Upstream commit 1451d5ae351d938a0ab1677498c893f17b9ee21d ] This driver supports both the mt9v032 (color) and the mt9v022 (mono) sensors. Depending on which sensor is used, the format from the sensor is different. The format.code inside the dev struct holds this information. The enum mbus and enum frame sizes need to take into account both type of sensors, not just the color one. To solve this, use the format.code in these functions instead of the hardcoded bayer color format (which is only used for mt9v032). [Sakari Ailus: rewrapped commit message] Suggested-by: Wenyou Yang <wenyou.yang@microchip.com> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.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: Sasha Levin <sashal@kernel.org>
2020-02-15media: i2c: adv748x: Fix unsafe macrosGustavo A. R. Silva1-4/+4
commit 0d962e061abcf1b9105f88fb850158b5887fbca3 upstream. Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver") Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.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+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15media/v4l2-core: set pages dirty upon releasing DMA buffersJohn Hubbard1-1/+4
commit 3c7470b6f68434acae459482ab920d1e3fabd1c7 upstream. After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling set_page_dirty_lock() if the CPU pages were potentially receiving data from the device. Link: http://lkml.kernel.org/r/20200107224558.2362728-11-jhubbard@nvidia.com Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: <stable@vger.kernel.org> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Björn Töpel <bjorn.topel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Leon Romanovsky <leonro@mellanox.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15media: uvcvideo: Avoid cyclic entity chains due to malformed USB descriptorsWill Deacon1-0/+12
commit 68035c80e129c4cfec659aac4180354530b26527 upstream. Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 #238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa-PjUta7EOb7A@mail.gmail.com/ Cc: <stable@vger.kernel.org> Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-15media: iguanair: fix endpoint sanity checkJohan Hovold1-1/+1
[ Upstream commit 1b257870a78b0a9ce98fdfb052c58542022ffb5b ] Make sure to use the current alternate setting, which need not be the first one by index, when verifying the endpoint descriptors and initialising the URBs. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 26ff63137c45 ("[media] Add support for the IguanaWorks USB IR Transceiver") Fixes: ab1cbdf159be ("media: iguanair: add sanity checks") Cc: stable <stable@vger.kernel.org> # 3.6 Cc: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-05media: si470x-i2c: Move free() past last use of 'radio'Lee Jones1-1/+1
A pointer to 'struct si470x_device' is currently used after free: drivers/media/radio/si470x/radio-si470x-i2c.c:462:25-30: ERROR: reference preceded by free on line 460 Shift the call to free() down past its final use. NB: Not sending to Mainline, since the problem does not exist there, it was caused by the backport of 2df200ab234a ("media: si470x-i2c: add missed operations in remove") to the stable trees. Cc: <stable@vger.kernel.org> # v3.18+ Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-05media: dvb-usb/dvb-usb-urb.c: initialize actlen to 0Hans Verkuil1-1/+1
commit 569bc8d6a6a50acb5fcf07fb10b8d2d461fdbf93 upstream. This fixes a syzbot failure since actlen could be uninitialized, but it was still used. Syzbot link: https://syzkaller.appspot.com/bug?extid=6bf9606ee955b646c0e1 Reported-and-tested-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-05media: gspca: zero usb_bufHans Verkuil1-1/+1
commit de89d0864f66c2a1b75becfdd6bf3793c07ce870 upstream. Allocate gspca_dev->usb_buf with kzalloc instead of kmalloc to ensure it is property zeroed. This fixes various syzbot errors about uninitialized data. Syzbot links: https://syzkaller.appspot.com/bug?extid=32310fc2aea76898d074 https://syzkaller.appspot.com/bug?extid=99706d6390be1ac542a2 https://syzkaller.appspot.com/bug?extid=64437af5c781a7f0e08e Reported-and-tested-by: syzbot+32310fc2aea76898d074@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+99706d6390be1ac542a2@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+64437af5c781a7f0e08e@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-05media: af9005: uninitialized variable printkedSean Young1-1/+1
commit 51d0c99b391f0cac61ad7b827c26f549ee55672c upstream. If usb_bulk_msg() fails, actual_length can be uninitialized. Reported-by: syzbot+9d42b7773d2fecd983ab@syzkaller.appspotmail.com Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-05media: digitv: don't continue if remote control state can't be readSean Young1-3/+7
commit eecc70d22ae51225de1ef629c1159f7116476b2e upstream. This results in an uninitialized variable read. Reported-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29media: v4l2-ioctl.c: zero reserved fields for S/TRY_FMTHans Verkuil1-12/+12
commit ee8951e56c0f960b9621636603a822811cef3158 upstream. v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format have a reserved array at the end that should be zeroed by drivers as per the V4L2 spec. Older drivers often do not do this, so just handle this in the core. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-27media: atmel: atmel-isi: fix timeout value for stop streamingAlexandre Kroupski1-1/+1
[ Upstream commit 623fd246bb40234fe68dd4e7c1f1f081f9c45a3d ] In case of sensor malfunction, stop streaming timeout takes much longer than expected. This is due to conversion of time to jiffies: milliseconds multiplied with HZ (ticks/second) gives out a value of jiffies with 10^3 greater. We need to also divide by 10^3 to obtain the right jiffies value. In other words FRAME_INTERVAL_MILLI_SEC must be in seconds in order to multiply by HZ and get the right jiffies value to add to the current jiffies for the timeout expire time. Fixes: 195ebc43bf76 ("[media] V4L: at91: add Atmel Image Sensor Interface (ISI) support") Signed-off-by: Alexandre Kroupski <alexandre.kroupski@ingenico.com> Reviewed-by: Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: vivid: fix incorrect assignment operation when setting video modeColin Ian King1-1/+1
[ Upstream commit d4ec9550e4b2d2e357a46fdc65d8ef3d4d15984c ] The assigment of FB_VMODE_NONINTERLACE to var->vmode should be a bit-wise or of FB_VMODE_NONINTERLACE instead of an assignment, otherwise the previous clearing of the FB_VMODE_MASK bits of var->vmode makes no sense and is redundant. Addresses-Coverity: ("Unused value") Fixes: ad4e02d5081d ("[media] vivid: add a simple framebuffer device for overlay testing") Signed-off-by: Colin Ian King <colin.king@canonical.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>
2020-01-27media: davinci/vpbe: array underflow in vpbe_enum_outputs()Dan Carpenter1-1/+1
[ Upstream commit b72845ee5577b227131b1fef23f9d9a296621d7b ] In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but the problem is that "temp_index" can be negative. This patch changes the types to unsigned to address this array underflow bug. Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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: Sasha Levin <sashal@kernel.org>
2020-01-27media: omap_vout: potential buffer overflow in vidioc_dqbuf()Dan Carpenter1-9/+6
[ Upstream commit dd6e2a981bfe83aa4a493143fd8cf1edcda6c091 ] The "b->index" is a u32 the comes from the user in the ioctl. It hasn't been checked. We aren't supposed to use it but we're instead supposed to use the value that gets written to it when we call videobuf_dqbuf(). The videobuf_dqbuf() first memsets it to zero and then re-initializes it inside the videobuf_status() function. It's this final value which we want. Hans Verkuil pointed out that we need to check the return from videobuf_dqbuf(). I ended up doing a little cleanup related to that as well. Fixes: 72915e851da9 ("[media] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf") 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+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: ov2659: fix unbalanced mutex_lock/unlockAkinobu Mita1-1/+1
[ Upstream commit 384538bda10913e5c94ec5b5d34bd3075931bcf4 ] Avoid returning with mutex locked. Fixes: fa8cb6444c32 ("[media] ov2659: Don't depend on subdev API") Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: tw5864: Fix possible NULL pointer dereference in tw5864_handle_frameYueHaibing1-2/+2
[ Upstream commit 2e7682ebfc750177a4944eeb56e97a3f05734528 ] 'vb' null check should be done before dereferencing it in tw5864_handle_frame, otherwise a NULL pointer dereference may occur. Fixes: 34d1324edd31 ("[media] pci: Add tw5864 driver") Signed-off-by: YueHaibing <yuehaibing@huawei.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>
2020-01-27media: davinci-isif: avoid uninitialized variable useArnd Bergmann1-9/+0
[ Upstream commit 0e633f97162c1c74c68e2eb20bbd9259dce87cd9 ] clang warns about a possible variable use that gcc never complained about: drivers/media/platform/davinci/isif.c:982:32: error: variable 'frame_size' is uninitialized when used here [-Werror,-Wuninitialized] dm365_vpss_set_pg_frame_size(frame_size); ^~~~~~~~~~ drivers/media/platform/davinci/isif.c:887:2: note: variable 'frame_size' is declared here struct vpss_pg_frame_size frame_size; ^ 1 error generated. There is no initialization for this variable at all, and there has never been one in the mainline kernel, so we really should not put that stack data into an mmio register. On the other hand, I suspect that gcc checks the condition more closely and notices that the global isif_cfg.bayer.config_params.test_pat_gen flag is initialized to zero and never written to from any code path, so anything depending on it can be eliminated. To shut up the clang warning, just remove the dead code manually, it has probably never been used because any attempt to do so would have resulted in undefined behavior. Fixes: 63e3ab142fa3 ("V4L/DVB: V4L - vpfe capture - source for ISIF driver on DM365") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.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: Sasha Levin <sashal@kernel.org>
2020-01-27media: cx23885: check allocation returnNicholas Mc Guire1-2/+3
[ Upstream commit a3d7f22ef34ec4206b50ee121384d5c8bebd5591 ] Checking of kmalloc() seems to have been committed - as cx23885_dvb_register() is checking for != 0 return, returning -ENOMEM should be fine here. While at it address the coccicheck suggestion to move to kmemdup rather than using kmalloc+memcpy. Fixes: 46b21bbaa8a8 ("[media] Add support for DViCO FusionHDTV DVB-T Dual Express2") Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: wl128x: Fix an error code in fm_download_firmware()Dan Carpenter1-2/+3
[ Upstream commit ef4bb63dc1f7213c08e13f6943c69cd27f69e4a3 ] We forgot to set "ret" on this error path. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") 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+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: cx18: update *pos correctly in cx18_read_pos()Dan Carpenter1-1/+1
[ Upstream commit 7afb0df554292dca7568446f619965fb8153085d ] We should be updating *pos. The current code is a no-op. Fixes: 1c1e45d17b66 ("V4L/DVB (7786): cx18: new driver for the Conexant CX23418 MPEG encoder chip") 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+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: ivtv: update *pos correctly in ivtv_read_pos()Dan Carpenter1-1/+1
[ Upstream commit f8e579f3ca0973daef263f513da5edff520a6c0d ] We had intended to update *pos, but the current code is a no-op. Fixes: 1a0adaf37c30 ("V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder") 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+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27media: s5p-jpeg: Correct step and max values for V4L2_CID_JPEG_RESTART_INTERVALPawe? Chmiel1-1/+1
[ Upstream commit 19c624c6b29e244c418f8b44a711cbf5e82e3cd4 ] This commit corrects max and step values for v4l2 control for V4L2_CID_JPEG_RESTART_INTERVAL. Max should be 0xffff and step should be 1. It was found by using v4l2-compliance tool and checking result of VIDIOC_QUERY_EXT_CTRL/QUERYMENU test. Previously it was complaining that step was bigger than difference between max and min. Fixes: 15f4bc3b1f42 ("[media] s5p-jpeg: Add JPEG controls support") Signed-off-by: Pawe? Chmiel <pawel.mikolaj.chmiel@gmail.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.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+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-17media: exynos4-is: Fix recursive locking in isp_video_release()Seung-Woo Kim1-1/+1
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17media: ov6650: Fix .get_fmt() V4L2_SUBDEV_FORMAT_TRY supportJanusz Krzysztofik1-3/+9
commit 39034bb0c26b76a2c3abc54aa28c185f18b40c2f upstream. Commit da298c6d98d5 ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") converted a former ov6650_g_fmt() video operation callback to an ov6650_get_fmt() pad operation callback. However, the converted function disregards a format->which flag that pad operations should obey and always returns active frame format settings. That can be fixed by always responding to V4L2_SUBDEV_FORMAT_TRY with -EINVAL, or providing the response from a pad config argument, likely updated by a former user call to V4L2_SUBDEV_FORMAT_TRY .set_fmt(). Since implementation of the latter is trivial, go for it. Fixes: da298c6d98d5 ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17media: ov6650: Fix some format attributes not under controlJanusz Krzysztofik1-12/+39
commit 1c6a2b63095154bbf9e8f38d79487a728331bf65 upstream. User arguments passed to .get/set_fmt() pad operation callbacks may contain unsupported values. The driver takes control over frame size and pixel code as well as colorspace and field attributes but has never cared for remainig format attributes, i.e., ycbcr_enc, quantization and xfer_func, introduced by commit 11ff030c7365 ("[media] v4l2-mediabus: improve colorspace support"). Fix it. Set up a static v4l2_mbus_framefmt structure with attributes initialized to reasonable defaults and use it for updating content of user provided arguments. In case of V4L2_SUBDEV_FORMAT_ACTIVE, postpone frame size update, now performed from inside ov6650_s_fmt() helper, util the user argument is first updated in ov6650_set_fmt() with default frame format content. For V4L2_SUBDEV_FORMAT_TRY, don't copy all attributes to pad config, only those handled by the driver, then fill the response with the default frame format updated with resulting pad config format code and frame size. Fixes: 11ff030c7365 ("[media] v4l2-mediabus: improve colorspace support") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17media: ov6650: Fix incorrect use of JPEG colorspaceJanusz Krzysztofik1-11/+2
commit 12500731895ef09afc5b66b86b76c0884fb9c7bf upstream. Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support JPEG format, fix it to always select V4L2_COLORSPACE_SRGB. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17media: usb:zr364xx:Fix KASAN:null-ptr-deref Read in zr364xx_vidioc_querycapVandana BN1-1/+2
commit 5d2e73a5f80a5b5aff3caf1ec6d39b5b3f54b26e upstream. SyzKaller hit the null pointer deref while reading from uninitialized udev->product in zr364xx_vidioc_querycap(). ================================================================== BUG: KASAN: null-ptr-deref in read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 Read of size 1 at addr 0000000000000000 by task v4l_id/5287 CPU: 1 PID: 5287 Comm: v4l_id Not tainted 5.1.0-rc3-319004-g43151d6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 kasan_report.cold+0x5/0x3c mm/kasan/report.c:321 read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 strscpy+0x8a/0x280 lib/string.c:207 zr364xx_vidioc_querycap+0xb5/0x210 drivers/media/usb/zr364xx/zr364xx.c:706 v4l_querycap+0x12b/0x340 drivers/media/v4l2-core/v4l2-ioctl.c:1062 __video_do_ioctl+0x5bb/0xb40 drivers/media/v4l2-core/v4l2-ioctl.c:2874 video_usercopy+0x44e/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3056 v4l2_ioctl+0x14e/0x1a0 drivers/media/v4l2-core/v4l2-dev.c:364 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xced/0x12f0 fs/ioctl.c:696 ksys_ioctl+0xa0/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:718 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f3b56d8b347 Code: 90 90 90 48 8b 05 f1 fa 2a 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 90 90 90 90 90 90 90 90 90 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 fa 2a 00 31 d2 48 29 c2 64 RSP: 002b:00007ffe005d5d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f3b56d8b347 RDX: 00007ffe005d5d70 RSI: 0000000080685600 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400884 R13: 00007ffe005d5ec0 R14: 0000000000000000 R15: 0000000000000000 ================================================================== For this device udev->product is not initialized and accessing it causes a NULL pointer deref. The fix is to check for NULL before strscpy() and copy empty string, if product is NULL Reported-by: syzbot+66010012fd4c531a1a96@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> [bwh: Backported to 4.14: This function uses strlcpy() instead of strscpy()] Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09media: usb: fix memory leak in af9005_identify_stateNavid Emamdoost1-2/+3
commit 2289adbfa559050d2a38bcd9caac1c18b800e928 upstream. In af9005_identify_state when returning -EIO the allocated buffer should be released. Replace the "return -EIO" with assignment into ret and move deb_info() under a check. Fixes: af4e067e1dcf ("V4L/DVB (5625): Add support for the AF9005 demodulator from Afatech") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> 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>
2020-01-09media: flexcop-usb: ensure -EIO is returned on error conditionColin Ian King1-1/+1
commit 74a96b51a36de4d86660fbc56b05d86668162d6b upstream. 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: b430eaba0be5 ("[media] flexcop-usb: don't use stack for DMA") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09media: cec: avoid decrementing transmit_queue_sz if it is 0Hans Verkuil1-2/+12
commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream. WARN if transmit_queue_sz is 0 but do not decrement it. The CEC adapter will become unresponsive if it goes below 0 since then it thinks there are 4 billion messages in the queue. Obviously this should not happen, but a driver bug could cause this. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.12 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09media: cec: CEC 2.0-only bcast messages were ignoredHans Verkuil1-3/+3
commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream. Some messages are allowed to be a broadcast message in CEC 2.0 only, and should be ignored by CEC 1.4 devices. Unfortunately, the check was wrong, causing such messages to be marked as invalid under CEC 2.0. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09media: pulse8-cec: fix lost cec_transmit_attempt_done() callHans Verkuil1-4/+13
commit e5a52a1d15c79bb48a430fb263852263ec1d3f11 upstream. The periodic PING command could interfere with the result of a CEC transmit, causing a lost cec_transmit_attempt_done() call. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-31media: si470x-i2c: add missed operations in removeChuhong Yuan1-0/+2
[ Upstream commit 2df200ab234a86836a8879a05a8007d6b884eb14 ] The driver misses calling v4l2_ctrl_handler_free and v4l2_device_unregister in remove like what is done in probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31media: pvrusb2: Fix oops on tear-down when radio support is not presentMike Isely1-2/+7
[ Upstream commit 7f404ae9cf2a285f73b3c18ab9303d54b7a3d8e1 ] 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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31media: v4l2-core: fix touch support in v4l_g_fmtVandana BN1-15/+18
[ Upstream commit 545b618cfb5cadacd00c25066b9a36540e5ca9e9 ] v4l_s_fmt, for VFL_TYPE_TOUCH, sets unneeded members of the v4l2_pix_format structure to default values.This was missing in v4l_g_fmt, which would lead to failures in v4l2-compliance tests. Signed-off-by: Vandana BN <bnvandana@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31media: rcar_drif: fix a memory disclosureKangjie Lu1-0/+1
[ Upstream commit d39083234c60519724c6ed59509a2129fd2aed41 ] "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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: fix a v4l2-compliance failure about invalid sizeimageBenoit Parrot2-0/+5
[ Upstream commit 0bac73adea4df8d34048b38f6ff24dc3e73e90b6 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: ensure buffers are cleaned up properly in abort casesBenoit Parrot1-3/+9
[ Upstream commit cf6acb73b050e98b5cc435fae0e8ae0157520410 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: fix a v4l2-compliance failure causing a kernel panicBenoit Parrot1-1/+1
[ Upstream commit a37980ac5be29b83da67bf7d571c6bd9f90f8e45 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: Make sure YUYV is set as default formatBenoit Parrot1-1/+1
[ Upstream commit e20b248051ca0f90d84b4d9378e4780bc31f16c6 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: fix a v4l2-compliance failure about frame sequence numberBenoit Parrot1-0/+1
[ Upstream commit 2444846c0dbfa4ead21b621e4300ec32c90fbf38 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: fix a v4l2-compliance warning about invalid pixel formatBenoit Parrot1-4/+9
[ Upstream commit 06bec72b250b2cb3ba96fa45c2b8e0fb83745517 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ti-vpe: vpe: Fix Motion Vector vpdma strideBenoit Parrot1-5/+13
[ Upstream commit 102af9b9922f658f705a4b0deaccabac409131bf ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: cx88: Fix some error handling path in 'cx8800_initdev()'Christophe JAILLET1-4/+7
[ Upstream commit e1444e9b0424c70def6352580762d660af50e03f ] A call to 'pci_disable_device()' is missing in the error handling path. In some cases, a call to 'free_irq()' may also be missing. Reorder the error handling path, add some new labels and fix the 2 issues mentionned above. This way, the error handling path in more in line with 'cx8800_finidev()' (i.e. the remove function) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: 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-12-31media: flexcop-usb: fix NULL-ptr deref in flexcop_usb_transfer_init()Yang Yingliang1-1/+7
[ Upstream commit 649cd16c438f51d4cd777e71ca1f47f6e0c5e65d ] If usb_set_interface() failed, iface->cur_altsetting will not be assigned and it will be used in flexcop_usb_transfer_init() It may lead a NULL pointer dereference. Check usb_set_interface() return value in flexcop_usb_init() and return failed to avoid using this NULL pointer. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31media: venus: core: Fix msm8996 frequency tableLoic Poulain1-4/+5
[ Upstream commit c690435ed07901737e5c007a65ec59f53b33eb71 ] 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: Sasha Levin <sashal@kernel.org>
2019-12-31media: ov6650: Fix stored crop rectangle not in sync with hardwareJanusz Krzysztofik1-0/+2
[ Upstream commit 1463b371aff0682c70141f7521db13cc4bbf3016 ] The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31media: ov6650: Fix stored frame format not in sync with hardwareJanusz Krzysztofik1-3/+6
[ Upstream commit 3143b459de4cdcce67b36827476c966e93c1cf01 ] The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-19 06:19:50 +0300