<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/media/common, branch v6.6.142</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.142</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.142'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-17T15:13:44+00:00</updated>
<entry>
<title>media: videobuf2: Set vma_flags in vb2_dma_sg_mmap</title>
<updated>2026-05-17T15:13:44+00:00</updated>
<author>
<name>Janne Grunau</name>
<email>j@jannau.net</email>
</author>
<published>2026-02-15T17:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=feb17524aa4ec337749344be0db52b88663e25ab'/>
<id>urn:sha1:feb17524aa4ec337749344be0db52b88663e25ab</id>
<content type='text'>
commit 7254b31a13aaa0c2c0f9ffbc335b718656117ff4 upstream.

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-&gt;vm_flags &amp; 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 &lt;j@jannau.net&gt;
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil+cisco@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: videobuf2: Fix device reference leak in vb2_dc_alloc error path</title>
<updated>2026-01-11T14:22:15+00:00</updated>
<author>
<name>Haotian Zhang</name>
<email>vulab@iscas.ac.cn</email>
</author>
<published>2025-10-28T06:44:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ad7c817410965f6098f53ae543a26359d489ee5'/>
<id>urn:sha1:1ad7c817410965f6098f53ae543a26359d489ee5</id>
<content type='text'>
commit 94de23a9aa487d7c1372efb161721d7949a177ae upstream.

In vb2_dc_alloc(), get_device() is called to increment the device
reference count. However, if subsequent DMA allocation fails
(vb2_dc_alloc_coherent or vb2_dc_alloc_non_coherent returns error),
the function returns without calling put_device(), causing a device
reference leak.

Add put_device() call in the error path before kfree() to properly
release the device reference acquired earlier.

Fixes: de27891f675e ("media: videobuf2: handle non-contiguous DMA allocations")
Cc: stable@vger.kernel.org
Signed-off-by: Haotian Zhang &lt;vulab@iscas.ac.cn&gt;
Reviewed-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil+cisco@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: videobuf2: use sgtable-based scatterlist wrappers</title>
<updated>2025-06-27T10:08:46+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2025-05-07T16:09:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=17cb043ea1334ebe57377ab138e155beec870c97'/>
<id>urn:sha1:17cb043ea1334ebe57377ab138e155beec870c97</id>
<content type='text'>
commit a704a3c503ae1cfd9de8a2e2d16a0c9430e98162 upstream.

Use common wrappers operating directly on the struct sg_table objects to
fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*()
functions have to be called with the number of elements originally passed
to dma_map_sg_*() function, not the one returned in sgt-&gt;nents.

Fixes: d4db5eb57cab ("media: videobuf2: add begin/end cpu_access callbacks to dma-sg")
CC: stable@vger.kernel.org
Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Sergey Senozhatsky &lt;senozhatsky@chromium.org&gt;
Acked-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil@xs4all.nl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: siano: Fix error handling in smsdvb_module_init()</title>
<updated>2025-04-25T08:45:22+00:00</updated>
<author>
<name>Yuan Can</name>
<email>yuancan@huawei.com</email>
</author>
<published>2024-10-22T06:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=192b87608c2ccadf0c1fb239fa30334a374ff515'/>
<id>urn:sha1:192b87608c2ccadf0c1fb239fa30334a374ff515</id>
<content type='text'>
commit 734ac57e47b3bdd140a1119e2c4e8e6f8ef8b33d upstream.

The smsdvb_module_init() returns without checking the retval from
smscore_register_hotplug().
If the smscore_register_hotplug() failed, the module failed to install,
leaving the smsdvb_debugfs not unregistered.

Fixes: 3f6b87cff66b ("[media] siano: allow showing the complete statistics via debugfs")
Cc: stable@vger.kernel.org
Signed-off-by: Yuan Can &lt;yuancan@huawei.com&gt;
Acked-by: Ricardo Ribalda &lt;ribalda@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil@xs4all.nl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: v4l2-tpg: prevent the risk of a division by zero</title>
<updated>2024-11-14T12:19:34+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+huawei@kernel.org</email>
</author>
<published>2024-10-16T09:53:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d0f01aa602fd15a805771bdf3f4d9a9b4df7f47'/>
<id>urn:sha1:2d0f01aa602fd15a805771bdf3f4d9a9b4df7f47</id>
<content type='text'>
commit e6a3ea83fbe15d4818d01804e904cbb0e64e543b upstream.

As reported by Coverity, the logic at tpg_precalculate_line()
blindly rescales the buffer even when scaled_witdh is equal to
zero. If this ever happens, this will cause a division by zero.

Instead, add a WARN_ON_ONCE() to trigger such cases and return
without doing any precalculation.

Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator")
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: videobuf2-core: clear memory related fields in __vb2_plane_dmabuf_put()</title>
<updated>2024-10-17T13:24:19+00:00</updated>
<author>
<name>Yunke Cao</name>
<email>yunkec@chromium.org</email>
</author>
<published>2024-08-14T02:06:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7af8d697b70fda49d04ef3f8c5f77a9b652e0035'/>
<id>urn:sha1:7af8d697b70fda49d04ef3f8c5f77a9b652e0035</id>
<content type='text'>
[ Upstream commit 6a9c97ab6b7e85697e0b74e86062192a5ffffd99 ]

Clear vb2_plane's memory related fields in __vb2_plane_dmabuf_put(),
including bytesused, length, fd and data_offset.

Remove the duplicated code in __prepare_dmabuf().

Signed-off-by: Yunke Cao &lt;yunkec@chromium.org&gt;
Acked-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: videobuf2: request more buffers for vb2_read</title>
<updated>2024-04-27T15:11:30+00:00</updated>
<author>
<name>Hans Verkuil</name>
<email>hverkuil-cisco@xs4all.nl</email>
</author>
<published>2023-11-30T12:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=390a71e361f466770999264e2ca57f294438272a'/>
<id>urn:sha1:390a71e361f466770999264e2ca57f294438272a</id>
<content type='text'>
[ Upstream commit 350ab13e1382f2afcc2285041a1e75b80d771c2c ]

The vb2 read support requests 1 buffer, leaving it to the driver
to increase this number to something that works.

Unfortunately, drivers do not deal with this reliably, and in fact
this caused problems for the bttv driver and reading from /dev/vbiX,
causing every other VBI frame to be all 0.

Instead, request as the number of buffers whatever is the maximum of
2 and q-&gt;min_buffers_needed+1.

In order to start streaming you need at least q-&gt;min_buffers_needed
queued buffers, so add 1 buffer for processing. And if that field
is 0, then choose 2 (again, one buffer is being filled while the
other one is being processed).

This certainly makes more sense than requesting just 1 buffer, and
the VBI bttv support is now working again.

It turns out that the old videobuf1 behavior of bttv was to allocate
8 (video) and 4 (vbi) buffers when used with read(). After the vb2
conversion that changed to 2 for both. With this patch it is 3, which
is really all you need.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Fixes: b7ec3212a73a ("media: bttv: convert to vb2")
Tested-by: Dr. David Alan Gilbert &lt;dave@treblig.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: v4l2-tpg: fix some memleaks in tpg_alloc</title>
<updated>2024-03-26T22:19:45+00:00</updated>
<author>
<name>Zhipeng Lu</name>
<email>alexious@zju.edu.cn</email>
</author>
<published>2024-02-01T12:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c86c772fef06f5d7a66151bac42366825db0941'/>
<id>urn:sha1:4c86c772fef06f5d7a66151bac42366825db0941</id>
<content type='text'>
[ Upstream commit 8cf9c5051076e0eb958f4361d50d8b0c3ee6691c ]

In tpg_alloc, resources should be deallocated in each and every
error-handling paths, since they are allocated in for statements.
Otherwise there would be memleaks because tpg_free is called only when
tpg_alloc return 0.

Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator")
Signed-off-by: Zhipeng Lu &lt;alexious@zju.edu.cn&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: videobuf2-dma-sg: fix vmap callback</title>
<updated>2024-02-01T00:18:55+00:00</updated>
<author>
<name>Michael Grzeschik</name>
<email>m.grzeschik@pengutronix.de</email>
</author>
<published>2023-11-23T22:32:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72a28c92839c68c367b21af25fa04f68f51346ad'/>
<id>urn:sha1:72a28c92839c68c367b21af25fa04f68f51346ad</id>
<content type='text'>
commit 608ca5a60ee47b48fec210aeb7a795a64eb5dcee upstream.

For dmabuf import users to be able to use the vaddr from another
videobuf2-dma-sg source, the exporter needs to set a proper vaddr on
vb2_dma_sg_dmabuf_ops_vmap callback. This patch adds vmap on map if
buf-&gt;vaddr was not set.

Cc: stable@kernel.org
Fixes: 7938f4218168 ("dma-buf-map: Rename to iosys-map")
Signed-off-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Acked-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: vb2: frame_vector.c: replace WARN_ONCE with a comment</title>
<updated>2023-09-14T21:31:55+00:00</updated>
<author>
<name>Hans Verkuil</name>
<email>hverkuil-cisco@xs4all.nl</email>
</author>
<published>2023-08-17T10:41:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=735de5caf79e06cc9fb96b1b4f4974674ae3e917'/>
<id>urn:sha1:735de5caf79e06cc9fb96b1b4f4974674ae3e917</id>
<content type='text'>
The WARN_ONCE was issued also in cases that had nothing to do with VM_IO
(e.g. if the start address was just a random value and uaccess fails with
-EFAULT).

There are no reports of WARN_ONCE being issued for actual VM_IO cases, so
just drop it and instead add a note to the comment before the function.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Reviewed-by: David Hildenbrand &lt;david@redhat.com&gt;
Reported-by: Yikebaer Aizezi &lt;yikebaer61@gmail.com&gt;
</content>
</entry>
</feed>
