kernel/linux.git/drivers/media, branch v6.1.186

media: imx219: Fix maximum frame length in lines

2026-08-23T12:18:30+00:00

[ Upstream commit 2c4f1ba7354312ad2d6e34e70a518a51a9344715 ] The driver used the maximum frame length in lines value of 0xffff, but the maximum appears to be 0xfffe instead. Fix it. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: i2c: imx219: Rename VTS to FRM_LENGTH

2026-08-23T12:18:30+00:00

[ Upstream commit 04f78503f99ae7e9887c7fe5e4bc54a7cfb10fe0 ] The IMX219 datasheet refers to the vertical length + blanking as FRM_LENGTH instead of VTS. Reviewed-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: i2c: imx219: Correct the minimum vblanking value

2026-08-23T12:18:30+00:00

[ Upstream commit e3b82d49bf676f3c873e642038765eac32ab6d39 ] The datasheet for this sensor documents the minimum vblanking as being 32 lines. It does fix some problems with occasional black lines at the bottom of images (tested on Raspberry Pi). Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Reviewed-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: i2c: imx219: Drop IMX219_VTS_* macros

2026-08-23T12:18:29+00:00

[ Upstream commit 5ebbdd7aab3321e60a8be23aac1fee4f16644021 ] The IMX219_VTS_* macros define default VTS values for the modes supported by the driver. They are used in a single place, and hinder readability compared to using the value directly as a decimal number. Drop them. Signed-off-by: Laurent Pinchart Reviewed-by: Dave Stevenson Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix sequence number when no EOF

2026-08-19T15:16:11+00:00

commit f078966ca1fb1b3865d8e6bbe2705cfd277fc637 upstream. If the driver could not detect the EOF, the sequence number is increased twice: 1) When we enter uvc_video_decode_start() with the old buffer and FID has flipped => We return -EAGAIN and last_fid is not flipped 2) When we enter uvc_video_decode_start() with the new buffer. Fix this issue by moving the new frame detection logic earlier in uvc_video_decode_start(). This also has some nice side affects: - The error status from the new packet will no longer get propagated to the previous frame-buffer. - uvc_video_clock_decode() will no longer update the previous frame buf->stf with info from the new packet. - uvc_video_clock_decode() and uvc_video_stats_decode() will no longer get called twice for the same packet. Cc: stable@kernel.org Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost") Reported-by: Hans de Goede Closes: https://lore.kernel.org/linux-media/CANiDSCuj4cPuB5_v2xyvAagA5FjoN8V5scXiFFOeD3aKDMqkCg@mail.gmail.com/T/#me39fb134e8c2c085567a31548c3403eb639625e4 Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Sasha Levin

media: uvcvideo: Implement dual stream quirk to fix loss of usb packets

2026-08-19T15:16:10+00:00

commit c2eda35e675b6ea4a0a21a4b1167b121571a9036 upstream. Some cameras, such as the Sonix Technology Co. 292A, exhibit issues when running two parallel streams, causing USB packets to be dropped when an H.264 stream posts a keyframe while an MJPEG stream is running simultaneously. This occasionally causes the driver to erroneously output two consecutive JPEG images as a single frame. To fix this, we inspect the buffer, and trigger a new frame when we find an SOI. Signed-off-by: Isaac Scott Reviewed-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20241128145144.61475-2-isaac.scott@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab [Added JPEG_MARKER_SOI definition, jpeg header does not exist yet] Signed-off-by: Ricardo Ribalda Signed-off-by: Sasha Levin

media: vpif_capture: fix OF node reference imbalance

2026-08-19T15:16:05+00:00

commit 2282f979560af6bbc8ee2c1ee8663197312cee5b upstream. The driver reuses the OF node of the parent device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the parent and releasing the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when available") Cc: stable@vger.kernel.org # 4.13 Cc: Kevin Hilman Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: vivid: check for vb2_is_busy() when toggling caps

2026-08-19T15:16:05+00:00

commit c2d1a2130c93f6d758af58590b86b2254c7a1dec upstream. The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless. Reviewed-by: Nicolas Dufresne Fixes: 73c3f48230cd ("[media] vivid: add the control handling code") Cc: stable@vger.kernel.org Reported-by: syzbot+dac8f5eaa46837e97b89@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: vivid: add vivid_update_reduced_fps()

2026-08-19T15:16:05+00:00

commit 1d793a29efb4260f90913f5287939bf95573b073 upstream. Don't call vivid_update_format_cap() when switching to/from reduced fps for HDMI inputs: that will also reset the format, which is overkill for this. Make a new vivid_update_reduced_fps() function that just updates the dev->timeperframe_vid_cap. Reviewed-by: Nicolas Dufresne Fixes: c79aa6aeadb0 ("[media] vivid-capture: add control for reduced frame rate") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: vimc: fix reference leak on failed device registration

2026-08-19T15:16:05+00:00

commit 33e2b833c66b890a0d71c4fa82d4c97143f7f75f upstream. When platform_device_register() fails in vimc_init(), the embedded struct device in vimc_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: vimc_init() -> platform_device_register(&vimc_pdev) -> device_initialize(&vimc_pdev.dev) -> setup_pdev_dma_masks(&vimc_pdev) -> platform_device_add(&vimc_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman