kernel/linux.git/drivers/media/usb/uvc, branch linux-7.0.y

media: uvcvideo: Enable VB2_DMABUF for metadata stream

2026-05-17T15:16:22+00:00

commit fbac03467e53d8d72e5099c03df26d9adae11416 upstream. The UVC driver has two video streams, one for the frames and another one for the metadata. Both streams share most of the codebase, but only the data stream declares support for DMABUF transfer mode. I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM and the frames looked correct. This patch announces the support for DMABUF for the metadata stream. This is useful for apps/HALs that only want to support DMABUF. Cc: stable@vger.kernel.org Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix bug in error path of uvc_alloc_urb_buffers

2026-03-26T12:14:07+00:00

Recent cleanup introduced a bug in the error path of uvc_alloc_urb_buffers(). If there is not enough memory for the allocation the following error will be triggered: [ 739.196672] UBSAN: shift-out-of-bounds in mm/page_alloc.c:1403:22 [ 739.196710] shift exponent 52 is too large for 32-bit type 'int' Resulting in: [ 740.464422] BUG: unable to handle page fault for address: fffffac1c0800000 The reason for the bug is that usb_free_noncoherent is called with an invalid size (0) instead of the actual size of the urb. This patch takes care of that. Reported-by: Marek Marczykowski-Górecki Closes: https://lore.kernel.org/linux-media/abycbXzYupZpGkvR@hyeyoo/T/#t Tested-by: Marek Marczykowski-Górecki Fixes: c824345288d1 ("media: uvcvideo: Pass allocation size directly to uvc_alloc_urb_buffer") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260320-uvc-urb-free-error-v1-1-b12cc3762a19@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

media: uvcvideo: Pass allocation size directly to uvc_alloc_urb_buffer

2026-01-22T07:18:51+00:00

The uvc_alloc_urb_buffer() function implicitly depended on the stream->urb_size field, which was set by its caller, uvc_alloc_urb_buffers(). This implicit data flow makes the code harder to follow. More importantly, stream->urb_size was updated within the allocation loop before the allocation was confirmed to be successful. If the allocation failed, the stream object would be left with a urb_size that doesn't correspond to valid, allocated URB buffers. Refactor uvc_alloc_urb_buffer() to accept the buffer size as an explicit argument. This makes the function's dependencies clear and improves the robustness of the error handling path. The stream->urb_size is now set only after a complete and successful allocation. This is a pure refactoring and introduces no functional changes. Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Itay Chamiel Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-2-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: uvcvideo: Fix allocation for small frame sizes

2026-01-22T07:18:51+00:00

If a frame has size of less or equal than one packet size uvc_alloc_urb_buffers() is unable to allocate memory for it due to a off-by-one error. Fix the off-by-one-error and now that we are at it, make sure that stream->urb_size has always a valid value when we return from the function, even when an error happens. Fixes: efdc8a9585ce ("V4L/DVB (10295): uvcvideo: Retry URB buffers allocation when the system is low on memory.") Reported-by: Itay Chamiel Closes: https://lore.kernel.org/linux-media/CANiDSCsSoZf2LsCCoWAUbCg6tJT-ypXR1B85aa6rAdMVYr2iBQ@mail.gmail.com/T/#t Co-developed-by: Itay Chamiel Signed-off-by: Itay Chamiel Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Itay Chamiel Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-1-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: uvcvideo: Return queued buffers on start_streaming() failure

2026-01-22T07:18:50+00:00

Return buffers if streaming fails to start due to uvc_pm_get() error. This bug may be responsible for a warning I got running while :; do yavta -c3 /dev/video0; done on an xHCI controller which failed under this workload. I had no luck reproducing this warning again to confirm. xhci_hcd 0000:09:00.0: HC died; cleaning up usb 13-2: USB disconnect, device number 2 WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120 Fixes: 7dd56c47784a ("media: uvcvideo: Remove stream->is_streaming field") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20251015133642.3dede646.michal.pecio@gmail.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: uvcvideo: Create an ID namespace for streaming output terminals

2026-01-22T07:18:50+00:00

Some devices, such as the Grandstream GUV3100 and the LSK Meeting Eye for Business & Home, exhibit entity ID collisions between units and streaming output terminals. The UVC specification requires unit and terminal IDs to be unique, and uses the ID to reference entities: - In control requests, to identify the target entity - In the UVC units and terminals descriptors' bSourceID field, to identify source entities - In the UVC input header descriptor's bTerminalLink, to identify the terminal associated with a streaming interface Entity ID collisions break accessing controls and make the graph description in the UVC descriptors ambiguous. However, collisions where one of the entities is a streaming output terminal and the other entity is not a streaming terminal are less severe. Streaming output terminals have no controls, and, as they are the final entity in pipelines, they are never referenced in descriptors as source entities. They are referenced by ID only from innput header descriptors, which by definition only reference streaming terminals. For these reasons, we can work around the collision by giving streaming output terminals their own ID namespace. Do so by setting bit UVC_TERM_OUTPUT (15) in the uvc_entity.id field, which is normally never set as the ID is a 8-bit value. This ID change doesn't affect the entity name in the media controller graph as the name isn't constructed from the ID, so there should not be any impact on the uAPI. Although this change handles some ID collisions automagically, keep printing an error in uvc_alloc_new_entity() when a camera has invalid descriptors. Hopefully this message will help vendors fix their invalid descriptors. This new method of handling ID collisions includes a revert of commit 758dbc756aad ("media: uvcvideo: Use heuristic to find stream entity") that attempted to fix the problem urgently due to regression reports. Suggested-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Lili Orosz Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Link: https://patch.msgid.link/20251113210400.28618-1-laurent.pinchart@ideasonboard.com Signed-off-by: Hans Verkuil

Revert "media: uvcvideo: Remove nodrop parameter"

2026-01-13T13:59:59+00:00

This reverts commit 27ccc44a511b0cd76dc607e2a4893b876192ee1b. A user has reported that the Zoom Video Conferencing tool is not capable of handling invalid frames. Due to this, he has to continue using this parameter. We will keep working with Zoom so they can handle invalid frames correctly, but for this cycle the safest option is to revert this parameter drop. Fixes: 27ccc44a511b ("media: uvcvideo: Remove nodrop parameter") Reported-by: Ralf Jung Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121718 Closes: https://lore.kernel.org/linux-media/uboug5ectzm4s32yfgopjbcxq2uhsoc4kluaby7a4b7nzfjave@boco7oocnftr/ Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: uvcvideo: Remove nodrop parameter

2026-01-05T11:21:21+00:00

We announced the deprecation intentions one year ago in the commit commit 40ed9e9b2808 ("media: uvcvideo: Announce the user our deprecation intentions"). We have not hear any complains, lets remove the nodrop parameter. Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil