kernel/git/next/linux-next.git/drivers/media/common, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-14T15:08:32+00:00

# Conflicts: # net/ceph/osd_client.c

media: require two-byte Cypress type 04 records

2026-09-09T12:03:38+00:00

Both Cypress Intel HEX parsers read two address bytes from type 04 records. Generic record framing permits any record length, so a short record can make the parser consume the checksum or bytes beyond the firmware record. A longer record also violates the Intel HEX type 04 layout. Require the type 04 payload length to be exactly two bytes in both implementations. Fixes: 79a63c60a6a2 ("[media] media: move dvb-usb-v2/cypress_firmware.c to media/common") Fixes: 776338e121b9 ("[PATCH] dvb: Add generalized dvb-usb driver") Cc: stable@kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil

media: saa7146: Initialize interrupt lock before requesting IRQ

2026-09-08T13:10:04+00:00

The saa7146 interrupt handler can call SAA7146_IER_DISABLE(), which serializes register access with dev->int_slock. request_irq() allows the shared handler to run before saa7146_init_one() reaches the current lock initialization block. Initialize dev->int_slock before requesting the interrupt so every handler path sees an initialized lock. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Hans Verkuil

drivers/media: Remove pagemap.h includes

2026-08-25T19:12:26+00:00

None of these files actually needs pagemap.h. ivtv does need highmem.h which is brought in by pagemap.h, but that's easy to add. Signed-off-by: Matthew Wilcox (Oracle)

media: videobuf2: move vb2_querybuf() kernel-doc to header

2026-07-15T15:12:55+00:00

Move the function documentation for vb2_querybuf() from videobuf2-v4l2.c to videobuf2-v4l2.h to match other functions. Leaving the comment in the source file prevents the kernel-doc parser from extracting it - thus become missing from the generated HTML. Additionally, format the comment block to be the same style as other functions in the header. Signed-off-by: Tharit Tangkijwanichakul Signed-off-by: Hans Verkuil

media: v4l2-tpg: reduce stack usage for kasan builds

2026-07-10T08:32:27+00:00

tpg_fill_plane_buffer() is a rather complex function. While there is nothing wrong with it per se, I have run into corner cases with clang-22 on s390 using KASAN that makes it run out of registers and blow the stack warning limit from excessive spills: drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2629:6: error: stack frame size (1560) exceeds limit (1536) in 'tpg_fill_plane_buffer' [-Werror,-Wframe-larger-than] 2629 | void tpg_fill_plane_buffer(struct tpg_data *tpg, v4l2_std_id std, Forcing the two largest callees out of line completely avoids the problem and prevents all the register spills, with the stack usage for each function going down to a few bytes for the local variables. Arguably this is a problem caused by clang rather than the code, but a noinline_for_stack annotation is an easy workaround. Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil

media: vb2: use ssize_t for vb2_read/vb2_write

2026-05-06T07:05:56+00:00

vb2_read() and vb2_write() return size_t, but propagate negative errno values from __vb2_perform_fileio(). This relies on implicit signed/unsigned conversions in callers (e.g. vb2_fop_read()) to recover error codes: __vb2_perform_fileio() -> -EINVAL vb2_read() -> (size_t)-EINVAL vb2_fop_read() -> -EINVAL This relies on implicit conversions that are not obvious. These helpers are exported (EXPORT_SYMBOL_GPL) and part of the vb2 API, so changing their return type may affect existing users. However, they conceptually follow read/write semantics, where ssize_t is typically used to return either a byte count or a negative error code. Switch vb2_read() and vb2_write() to ssize_t, and update __vb2_perform_fileio() accordingly. Signed-off-by: Zile Xiong Acked-by: Marek Szyprowski Fixes: b25748fe6126 ("[media] v4l: videobuf2: add read() and write() emulator") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil

media: uvcvideo: Add support for P010 pixel format

2026-03-25T08:40:28+00:00

Add support for the P010 (10-bit Y/UV 4:2:0) pixel format to the uvcvideo driver. This format is exposed by USB capture devices such as the Magewell USB Capture HDMI 4K Pro when capturing HDR10 content. P010 stores 10-bit Y and interleaved UV samples in 16-bit little-endian words, with data in the upper 10 bits and zeros in the lower 6 bits. This requires 2 bytes per sample, so bytesperline is wWidth * 2. V4L2_PIX_FMT_P010 was added to the V4L2 core in commit 5374d8fb75f3 ("media: Add P010 video format"). Based on the community DKMS patch from awawa-dev/P010_for_V4L2. Link: https://github.com/awawa-dev/P010_for_V4L2 Signed-off-by: Oliver Collyer Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20251226065718.95504-1-ovcollyer@mac.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: rc: fix race between unregister and urb/irq callbacks

2026-03-17T13:43:56+00:00

Some rc device drivers have a race condition between rc_unregister_device() and irq or urb callbacks. This is because rc_unregister_device() does two things, it marks the device as unregistered so no new commands can be issued and then it calls rc_free_device(). This means the driver has no chance to cancel any pending urb callbacks or interrupts after the device has been marked as unregistered. Those callbacks may access struct rc_dev or its members (e.g. struct ir_raw_event_ctrl), which have been freed by rc_free_device(). This change removes the implicit call to rc_free_device() from rc_unregister_device(). This means that device drivers can call rc_unregister_device() in their remove or disconnect function, then cancel all the urbs and interrupts before explicitly calling rc_free_device(). Note this is an alternative fix for an issue found by Haotian Zhang, see the Closes: tags. Reported-by: Haotian Zhang Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/ Reviewed-by: Patrice Chotard Signed-off-by: Sean Young Signed-off-by: Hans Verkuil

media: videobuf2: Set vma_flags in vb2_dma_sg_mmap

2026-03-16T10:51:55+00:00

vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops. gst-launch-1.0 v4l2src ! gtk4paintablesink [ 38.201528] ------------[ cut here ]------------ [ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [ 38.219040] Tainted: [W]=WARN [ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp : ffffc0008dc678e0 [ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [ 38.231488] Call trace: [ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [ 38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813] __mmap_region+0x488/0x9a0 [ 38.233277] mmap_region+0xd0/0x148 [ 38.233703] do_mmap+0x350/0x5c0 [ 38.234148] vm_mmap_pgoff+0x14c/0x200 [ 38.234612] ksys_mmap_pgoff+0x150/0x208 [ 38.235107] __arm64_sys_mmap+0x34/0x50 [ 38.235611] invoke_syscall+0x50/0x120 [ 38.236075] el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680] do_el0_svc+0x24/0x38 [ 38.237113] el0_svc+0x38/0x168 [ 38.237507] el0t_64_sync_handler+0xa0/0xe8 [ 38.238034] el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end trace 0000000000000000 ]--- There were discussions in [1] at the end of 2023 that mmap() on imported dma-bufs should not be supported but as of v6.17 drm_gem_shmem_mmap() in drm_gem_shmem_helper.c still supports it. This might affect all gpu or accel drivers using drm_gem_shmem_mmap() or the wrapper drm_gem_shmem_object_mmap(). [1] https://lore.kernel.org/dri-devel/bc7f7844-0aa3-4802-b203-69d58e8be2fa@linux.intel.com/ Cc: stable@vger.kernel.org Fixes: 5ba3f757f059 ("[media] v4l: videobuf2: add DMA scatter/gather allocator") Signed-off-by: Janne Grunau Acked-by: Marek Szyprowski Signed-off-by: Hans Verkuil