aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-20media: saa7146: drop overlay supportHans Verkuil5-679/+7
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: common: btcx-risc.h: drop obsolete headerHans Verkuil1-29/+0
This header is no longer used, drop it. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: zoran: drop two obsolete prototypes from zoran_device.hHans Verkuil1-2/+0
These overlay-related functions no longer exist, so drop them from the header. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: stm32: dma2d: remove unused fb_bufHans Verkuil1-2/+0
Drop the unused struct v4l2_framebuffer fb_buf in struct dma2d_ctx. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> CC: Hugues Fruchet <hugues.fruchet@foss.st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: admin-guide/media/cec.rst: update CEC debugging docHans Verkuil1-34/+36
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: docs: vidioc-g-ext-ctrls.rst: Document p_s32 and p_s64 fieldsDaniel Lundberg Pedersen1-0/+10
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: pvrusb2: VIDEO_PVRUSB2 depends on DVB_CORE to use dvb_* symbolsTom Rix1-1/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: cros-ec: Add Gladios/Lisbon to the match tableKevin Chiu1-0/+4
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: av7110: prevent underflow in write_ts_to_decoder()Dan Carpenter1-2/+2
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: fd46d16d602a ("V4L/DVB (11759): dvb-ttpci: Add TS replay capability") Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: mtk-jpegenc: Fix a compilation issueoushixiong1-1/+1
‘mtk8195_jpegenc_drvdata’ defined but not used [-Werror=unused-variable] Signed-off-by: oushixiong <oushixiong@kylinos.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: stm32-dcmi: Enable incoherent buffer allocationMarek Vasut1-0/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finishharperchen1-7/+9
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: via: Handle error for dma_set_maskharperchen1-1/+3
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: harperchen <harperchen1110@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: MAINTAINERS: Add myself as CAMSS maintainerBryan O'Donoghue1-0/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish()harperchen2-7/+10
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: harperchen <harperchen1110@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: amphion: decoder implement display delay enableMing Qian3-2/+37
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: 6de8d628df6e ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: cros-ec: Add aurash to the match tableZoey Wu1-0/+2
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: mtk-mdp3: Add missing check and free for ida_allocJiasheng Jiang1-1/+7
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: 61890ccaefaf ("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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: stm32: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-4/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: renesas: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-4/+1
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> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: dw100: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-3/+1
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> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: bdisp: Add missing check for create_workqueueJiasheng Jiang1-0/+2
Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference. Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: imx-jpeg: Bounds check sizeimage accessKees Cook1-0/+5
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: mxl5005s: Bounds check size used for max array indexKees Cook1-4/+8
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: Kees Cook <keescook@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: drop unnecessary networking includesJakub Kicinski4-5/+6
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: dvb-frontends: Fix a typo ("Unknow sleep mode")Jonathan Neuschäfer2-2/+2
Spell "unknown" correctly. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: dt-bindings: silabs,si470x: Convert to DT schemaKrzysztof Kozlowski3-26/+49
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: platform: exynos4-is: Fix spelling mistake "palne" -> "plane"Colin Ian King2-2/+2
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: tc358746: Remove unneeded semicolonYang Li1-2/+2
./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=2832 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: rc: add Beelink Mini MXIII keymapChristian Hewitt3-0/+59
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: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: dt-bindings: rc: add rc-beelink-mxiiiChristian Hewitt1-0/+1
Add a binding for the rc-beelink-mxiii remote keymap Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: rc: add common keymap for Dreambox RC10/RC0 and RC20/RC-BT remotesEmanuel Strobel3-0/+153
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: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: dt-bindings: rc: add rc-dreamboxChristian Hewitt1-0/+1
Add a binding for the rc-dreambox remote keymap Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: fix format compliance issuesHans Verkuil1-27/+44
This properly fills in all the format fields and calculates the width and height correctly. Esp. the minimum width and height was wrong. When changing the standard the width and height also have to be reset to the corresponding default width/height for the chosen standard. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: reorder fmt_vid_cap functions in cx18-ioctl.cHans Verkuil1-97/+100
No actual code changed, this just reorders functions so that the g/try/s_fmt_vid_cap functions are all together rather than mixed in with the vbi format functions. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: missing CAP_AUDIO for vbi streamHans Verkuil1-1/+1
The v4l2-compliance test complained about this. You can change the input connector for the vbi stream, but that means that you can have to be able to do the same for the audio input. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: properly report pixelformatsHans Verkuil1-23/+38
The MPEG device reported non-MPEG pixelformats, and the YUV device reported the MPEG pixelformat as well. Separate the two: either report MPEG or HM12/UYUV, not all three. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: fix incorrect input countingHans Verkuil1-2/+2
Counting the number of video and audio inputs was wrong if the number of inputs equalled CX18_CARD_MAX_VIDEO_INPUTS or CX18_CARD_MAX_AUDIO_INPUTS. This was a copy-and-paste from the ivtv driver. That driver has been fixed quite a long time ago, but we missed that this driver had the same bug. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: cx18: convert to vb2Hans Verkuil7-346/+199
This patch converts cx18 from the old deprecated videobuf framework to the 'new' vb2 framework. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: v4l2-dev.c: check for V4L2_CAP_STREAMING to enable streaming ioctlsHans Verkuil1-2/+3
Rather than checking which device type it is, just check the STREAMING cap since that indicates support for streaming ioctls. Some drivers only support READWRITE (typically MPEG encoders). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-19media: vb2: set owner before calling vb2_readHans Verkuil1-2/+3
Before vb2_read is called, the owner must be set since vb2_read will actually start streaming. If vb2_read returns an error and q->fileio is NULL, then it failed to start streaming and the owner is set back to NULL. When the vb2 start_streaming callback is called, it expects the owner pointer to be set, and that wasn't the case in this particular situation. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-18media: v4l: subdev: Make link validation saferSakari Ailus1-0/+10
Link validation currently accesses invalid pointers if the link passed to it is not between two sub-devices. This is of course a driver bug. Ignore the error but print a warning message, as this is how it used to work previously. Fixes: a6b995ed03ff ("media: subdev: use streams in v4l2_subdev_link_validate()") Reported-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-18media: subdev: Fix validation state lockdep issueTomi Valkeinen1-30/+52
The new subdev state code has a possible deadlock scenario during link validation when the pipeline contains subdevs that support state and that do not support state. The current code locks the states of the subdevs on both ends of the link when starting the link validation, locking the sink side first, then the source. If either (or both) of the subdevs does not support state, nothing is done for that subdev at this point, and instead the locking is handled the old way, i.e. the subdev's ops do the locking internally. The issue arises when the sink doesn't support state, but source does, so the validation code locks the source for the duration of the validation, and then the sink is locked only when the get_fmt op is called. So lockdep sees the source locked first, then the sink. Later, when the streaming is started, the sink's s_stream op is called, which probably takes the subdev's lock. The op then calls the source's s_stream, which takes the source's lock. So, the sink is locked first, then the source. Note that link validation and stream starting is not done at the same time, so an actual deadlock should never happen. However, it's still a clear bug. Fix this by locking the subdev states only if both subdevs support state. In other words, we have two scenarios: 1. Both subdevs support state. Lock sink first, then source, and keep the locks while validating the link. 2. At least one of the subdevs do not support state. Take the lock only for the duration of the operation (get_fmt or looking at the routing), and release after the op is done. Obviously 1. is better, as we have a more consistent view of the states of the subdevs during validation. 2. is how it has been so far, so it's no worse than this used to be. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-18media: i2c: imx290: fix conditional function definitionsArnd Bergmann1-3/+3
The runtime suspend/resume functions are only referenced from the dev_pm_ops, but they use the old SET_RUNTIME_PM_OPS() helper that requires a __maybe_unused annotation to avoid a warning: drivers/media/i2c/imx290.c:1082:12: error: unused function 'imx290_runtime_resume' [-Werror,-Wunused-function] static int imx290_runtime_resume(struct device *dev) ^ drivers/media/i2c/imx290.c:1090:12: error: unused function 'imx290_runtime_suspend' [-Werror,-Wunused-function] static int imx290_runtime_suspend(struct device *dev) ^ Convert this to the new RUNTIME_PM_OPS() helper that so this is not required. To improve this further, also use the pm_ptr() helper that lets the dev_pm_ops get dropped entirely when CONFIG_PM is disabled. A related mistake happened in the of_match_ptr() macro here, which like SET_RUNTIME_PM_OPS() requires the match table to be marked as __maybe_unused, though I could not reproduce building this without CONFIG_OF. Remove the of_match_ptr() here as there is no point in dropping the match table in configurations without CONFIG_OF. Fixes: 02852c01f654 ("media: i2c: imx290: Initialize runtime PM before subdev") Signed-off-by: Arnd Bergmann <arnd@arndb.de> 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@kernel.org>
2023-03-18media: Revert "venus: firmware: Correct non-pix start and end addresses"Javier Martinez Canillas1-2/+2
This reverts commit a837e5161cfffbb3242cc0eb574f8bf65fd32640, which broke probing of the venus driver, at least on the SC7180 SoC HP X2 Chromebook: [ 11.455782] qcom-venus aa00000.video-codec: Adding to iommu group 11 [ 11.506980] qcom-venus aa00000.video-codec: non legacy binding [ 12.143432] qcom-venus aa00000.video-codec: failed to reset venus core [ 12.156440] qcom-venus: probe of aa00000.video-codec failed with error -110 Matthias Kaehlcke also reported that the same change caused a regression in SC7180 and sc7280, that prevents AOSS from entering sleep mode during system suspend. So let's revert this commit for now to fix both issues. Fixes: a837e5161cff ("venus: firmware: Correct non-pix start and end addresses") Reported-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-12Linux 6.3-rc2Linus Torvalds1-1/+1
2023-03-12wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after free for wext"Hector Martin1-2/+0
This reverts part of commit 015b8cc5e7c4 ("wifi: cfg80211: Fix use after free for wext") This commit broke WPA offload by unconditionally clearing the crypto modes for non-WEP connections. Drop that part of the patch. Signed-off-by: Hector Martin <marcan@marcan.st> Reported-by: Ilya <me@0upti.me> Reported-and-tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Fixes: 015b8cc5e7c4 ("wifi: cfg80211: Fix use after free for wext") Cc: stable@kernel.org Link: https://lore.kernel.org/linux-wireless/ZAx0TWRBlGfv7pNl@kroah.com/T/#m11e6e0915ab8fa19ce8bc9695ab288c0fe018edf Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-12Merge tag 'tpm-v6.3-rc3' of ↵Linus Torvalds3-2/+137
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm fixes from Jarkko Sakkinen: "Two additional bug fixes for v6.3" * tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: disable hwrng for fTPM on some AMD designs tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address
2023-03-12tpm: disable hwrng for fTPM on some AMD designsMario Limonciello2-1/+132
AMD has issued an advisory indicating that having fTPM enabled in BIOS can cause "stuttering" in the OS. This issue has been fixed in newer versions of the fTPM firmware, but it's up to system designers to decide whether to distribute it. This issue has existed for a while, but is more prevalent starting with kernel 6.1 because commit b006c439d58db ("hwrng: core - start hwrng kthread also for untrusted sources") started to use the fTPM for hwrng by default. However, all uses of /dev/hwrng result in unacceptable stuttering. So, simply disable registration of the defective hwrng when detecting these faulty fTPM versions. As this is caused by faulty firmware, it is plausible that such a problem could also be reproduced by other TPM interactions, but this hasn't been shown by any user's testing or reports. It is hypothesized to be triggered more frequently by the use of the RNG because userspace software will fetch random numbers regularly. Intentionally continue to register other TPM functionality so that users that rely upon PCR measurements or any storage of data will still have access to it. If it's found later that another TPM functionality is exacerbating this problem a module parameter it can be turned off entirely and a module parameter can be introduced to allow users who rely upon fTPM functionality to turn it on even though this problem is present. Link: https://www.amd.com/en/support/kb/faq/pa-410 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989 Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/ Fixes: b006c439d58d ("hwrng: core - start hwrng kthread also for untrusted sources") Cc: stable@vger.kernel.org Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Tested-by: reach622@mailcuk.com Tested-by: Bell <1138267643@qq.com> Co-developed-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-03-12tpm/eventlog: Don't abort tpm_read_log on faulty ACPI addressMorten Linderud1-1/+5
tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI table is found. If the firmware vendor includes an invalid log address we are unable to map from the ACPI memory and tpm_read_log() returns -EIO which would abort discovery of the eventlog. Change the return value from -EIO to -ENODEV when acpi_os_map_iomem() fails to map the event log. The following hardware was used to test this issue: Framework Laptop (Pre-production) BIOS: INSYDE Corp, Revision: 3.2 TPM Device: NTC, Firmware Revision: 7.2 Dump of the faulty ACPI TPM2 table: [000h 0000 4] Signature : "TPM2" [Trusted Platform Module hardware interface Table] [004h 0004 4] Table Length : 0000004C [008h 0008 1] Revision : 04 [009h 0009 1] Checksum : 2B [00Ah 0010 6] Oem ID : "INSYDE" [010h 0016 8] Oem Table ID : "TGL-ULT" [018h 0024 4] Oem Revision : 00000002 [01Ch 0028 4] Asl Compiler ID : "ACPI" [020h 0032 4] Asl Compiler Revision : 00040000 [024h 0036 2] Platform Class : 0000 [026h 0038 2] Reserved : 0000 [028h 0040 8] Control Address : 0000000000000000 [030h 0048 4] Start Method : 06 [Memory Mapped I/O] [034h 0052 12] Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00 [040h 0064 4] Minimum Log Length : 00010000 [044h 0068 8] Log Address : 000000004053D000 Fixes: 0cf577a03f21 ("tpm: Fix handling of missing event log") Tested-by: Erkki Eilonen <erkki@bearmetal.eu> Signed-off-by: Morten Linderud <morten@linderud.pw> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Powered by cgit, Gruvboxed by Blaster4385.