- 19 Mar, 2023 40 commits
-
-
Hans Verkuil authored
Support for clipping for overlays has been removed, update the documentation. Support for destructive overlay support has been removed as well, also update the documentation for this. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans Verkuil authored
Make sure this field is always 0 since destructive overlays are no longer supported. Signed-off-by:
-
Hans Verkuil authored
These two capabilities are no longer supported, so no longer define them when compiling the kernel. Signed-off-by:
-
Hans Verkuil authored
There are no longer any drivers that support clipping and bitmap support for the capture or output overlay interfaces, so drop this. Always set the bitmap, clips and clipcount fields to 0, and remove the compat32 support. Signed-off-by:
-
Hans Verkuil authored
This test driver is the only remaining driver still using the clipping and bitmap method. Drop support for this so we can remove this in the V4L2 API as well. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
This header is no longer used, drop it. Signed-off-by:
-
Hans Verkuil authored
These overlay-related functions no longer exist, so drop them from the header. Signed-off-by:
-
Hans Verkuil authored
Drop the unused struct v4l2_framebuffer fb_buf in struct dma2d_ctx. Signed-off-by:
-
Hans Verkuil authored
The documentation on how to create your own Raspberry Pi CEC debugger was a bit out of date. Update it to the Raspberry Pi 4B, drop the mention of the RTC and a link to a picture that no longer works. Also reorganize the text to make it easier to follow and change the pins to match the pins I use. Signed-off-by:
-
Daniel Lundberg Pedersen authored
p_s32 and p_s64 were added to the v4l2_ext_control struct, so these should have documentation as well. Signed-off-by:
Daniel Lundberg Pedersen <dlp@qtec.com> Signed-off-by:
-
Tom Rix authored
A rand config causes this link error vmlinux.o: In function `pvr2_dvb_create': (.text+0x8af1d2): undefined reference to `dvb_register_adapter' The rand config has CONFIG_VIDEO_PVRUSB2=y CONFIG_VIDEO_DEV=y CONFIG_DVB_CORE=m VIDEO_PVRUSB2 should also depend on DVB_CORE. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Kevin Chiu authored
The Google Gladios/Lisbon device uses the same approach as the Google Brask which enables the HDMI CEC via the cros-ec-cec driver. Signed-off-by:
Kevin Chiu <kevin.chiu.17802@gmail.com> Signed-off-by:
-
Dan Carpenter authored
The buf[4] value comes from the user via ts_play(). It is a value in the u8 range. The final length we pass to av7110_ipack_instant_repack() is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is not negative. It's not clear that passing a negative len value does anything bad necessarily, but it's not best practice. With the new bounds checking the "if (!len)" condition is no longer possible or required so remove that. Fixes: fd46d16d ("V4L/DVB (11759): dvb-ttpci: Add TS replay capability") Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
oushixiong authored
‘mtk8195_jpegenc_drvdata’ defined but not used [-Werror=unused-variable] Signed-off-by:
oushixiong <oushixiong@kylinos.cn> Signed-off-by:
-
Marek Vasut authored
Set allow_cache_hints to 1 for the vb2_queue capture queue in the STM32MP15xx DCMI V4L2 driver. This allows us to allocate buffers with the V4L2_MEMORY_FLAG_NON_COHERENT set. On STM32MP15xx SoCs, this enables caching for this memory, which improves performance when being read from CPU. This change should be safe from race conditions since videobuf2 already invalidates or flushes the appropriate cache lines in its prepare() and finish() methods. Tested on a STM32MP157F SoC. Resulted in 4x buffer access speedup. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
harperchen authored
When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of tw68_risc_buffer() and the value of buf->cpu before buffer free. Signed-off-by:
harperchen <harperchen1110@gmail.com> Signed-off-by:
-
harperchen authored
As the potential failure of the dma_set_mask(), we fix this bug by checking its return value and performing proper error handling. Signed-off-by:
-
Bryan O'Donoghue authored
I discussed with Robert a few ago lending a hand with CAMSS. Following up on that discussion, I'm happy to help. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
harperchen authored
When the driver calls cx23885_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer risc->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of cx23885_risc_buffer() and the value of risc->cpu before buffer free. Signed-off-by:
-
Ming Qian authored
amphion vpu support a low latency mode, when V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY_ENABLE is enabled, decoder can display frame immediately after it's decoded. Only h264 is support yet. Fixes: 6de8d628 ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
-
Zoey Wu authored
The Google aurash device uses the same approach as the Google Brask which enables the HDMI CEC via the cros-ec-cec driver. Signed-off-by:
Zoey Wu <zoey_wu@wistron.corp-partner.google.com> Signed-off-by:
-
Jiasheng Jiang authored
Add the check for the return value of the ida_alloc in order to avoid NULL pointer dereference. Moreover, free allocated "ctx->id" if mdp_m2m_open fails later in order to avoid memory leak. Fixes: 61890cca ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Ye Xingchen authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Ye Xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
Ye Xingchen authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Ye Xingchen authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Xavier Roumegue <xavier.roumegue@oss.nxp.com> Signed-off-by:
-
Jiasheng Jiang authored
Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference. Fixes: 28ffeebb ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Signed-off-by:
-
Kees Cook authored
The call of mxc_jpeg_get_plane_size() from mxc_jpeg_dec_irq() sets plane_no argument to 1. The compiler sees that it's possible to end up with an access beyond the bounds of sizeimage, if mem_planes was too large: if (plane_no >= fmt->mem_planes) // mem_planes = 2+ return 0; if (fmt->mem_planes == fmt->comp_planes) // comp_planes != mem_planes return q_data->sizeimage[plane_no]; if (plane_no < fmt->mem_planes - 1) // mem_planes = 2 return q_data->sizeimage[plane_no]; comp_planes == 0 or 1 is safe. comp_planes > 2 would be out of bounds. (This isn't currently possible given the contents of mxc_formats, though.) Silence the warning by bounds checking comp_planes for future robustness. Seen with GCC 13: In function 'mxc_jpeg_get_plane_size', inlined from 'mxc_jpeg_dec_irq' at ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:729:14: ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:641:42: warning: array subscript 2 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} [-Warray-bounds=] 641 | size += q_data->sizeimage[i]; | ~~~~~~~~~~~~~~~~~^~~ In file included from ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h:112, from ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:63: ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h: In function 'mxc_jpeg_dec_irq': ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h:84:41: note: while referencing 'sizeimage' 84 | u32 sizeimage[MXC_JPEG_MAX_PLANES]; | ^~~~~~~~~ Cc: Mirela Rabulea <mirela.rabulea@nxp.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
The use of state->CH_Ctrl[i].size in a shift operation implies that its value can be as much as 32, but the state->CH_Ctrl[i].val array is only 25 in size. Bounds check the size before shifting and looping. Fixes warnings seen with GCC 13: ../drivers/media/tuners/mxl5005s.c: In function 'MXL_ControlWrite_Group.isra': ../drivers/media/tuners/mxl5005s.c:3450:70: warning: array subscript 32 is above array bounds of 'u16[25]' {aka 'short unsigned int[25]'} [-Warray-bounds=] 3450 | state->CH_Ctrl[i].val[j] = (u8)((value >> j) & 0x01); | ~~~~~~~~~~~~~~~~~~~~~^~~ ../drivers/media/tuners/mxl5005s.c:238:13: note: while referencing 'val' 238 | u16 val[25]; /* Binary representation of Value */ | ^~~ Cc: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: -
Jakub Kicinski authored
dvb_net.h includes a bunch of core networking headers which increases the number of objects rebuilt when we touch them. They are unnecessary for the header itself and only one driver has an indirect dependency. tveeprom.h includes if_packet to gain access to ETH_ALEN. This is a bit of an overkill because if_packet.h pulls in skbuff.h. The definition of ETH_ALEN is in the uAPI header, which is very rarely touched, so switch to including that. This results in roughly 250 fewer objects built when skbuff.h is touched (6028 -> 5788). Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jonathan Neuschäfer authored
Spell "unknown" correctly. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Silicon Labs Si470x FM Radio Receiver bindings to DT schema. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Colin Ian King authored
There are spelling mistakes in a literal string and a comment. Fix them. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
-
Yang Li authored
./drivers/media/i2c/tc358746.c:857:3-4: Unneeded semicolon ./drivers/media/i2c/tc358746.c:861:2-3: Unneeded semicolon Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2832Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Christian Hewitt authored
Add a keymap for the simple IR (NEC) remote used with the Beelink Mini MXIII Android STB device. Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Christian Hewitt authored
Add a binding for the rc-beelink-mxiii remote keymap Signed-off-by:
-
Emanuel Strobel authored
Add a common keymap for the RC10/RC0 and RC20/RC-BT remotes used with the Dreambox One and Dreambox Two DVB-S/T boxes. The maps are combined since the IR codes do not conflict and both boxes have shipped with both remote designs over time. Both remote types can be programmed to control TVs, so include non-IR keys that are used to switch-to or toggle the remote mode: - DREAM in RC10/RC0 switches to (Dreambox) STB control mode - TV in RC10/RC0 switches to TV control mode - MODE in RC20/RC-BT toggles between STB/TV/BT control modes In the RC20 keymap the Android MIC (voice search) key maps to KEY_HELP and EXIT is mapped to KEY_ESC to replicate the go-backwards navigation behaviour in the Android vendor OS that ships on Dreambox devices. Signed-off-by:
Emanuel Strobel <emanuel.strobel@yahoo.com> Signed-off-by:
-
