use vb2 queue lock for waits

[grawis]

Summary

Linux 7 removed wait_prepare and wait_finish from struct vb2_ops.

vcam already sets vb2_queue.lock to vcam_mutex, so this patch removes
the obsolete callbacks and relies on the existing queue lock mechanism.
This keeps the blocking buffer-wait behavior unchanged while allowing vcam
to build with Linux 7 headers.

Testing

• Built with Linux 6.17.0-23-generic headers.
• Built and loaded on Linux 7.0.0-28-generic.
• v4l2-compliance -d /dev/video0 -f:
  48 succeeded, 0 failed, 0 warnings.
• Ran 100-frame MMAP streaming with v4l2-ctl.
  All frames reported bytesused=921600; output size was
  92160000 bytes (640 * 480 * 3 * 100).

---

Summary by cubic

Switches vcam waits to the videobuf2 queue lock to restore build compatibility with Linux 7. Linux 7 removes wait_prepare/wait_finish, so we drop those callbacks and rely on vb2_queue.lock = vcam_mutex, preserving the previous blocking semantics.

• Removes only the obsolete lock/unlock helpers; no uAPI or userspace behavior changes.
• Compatible with Linux 6.x and 7.0 headers; tested with v4l2-compliance (all pass) and 100-frame MMAP streaming (consistent bytesused).

^{Written for commit 178abf2. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="videobuf.c">

<violation number="1" location="videobuf.c:141">
P2: On kernels before ~6.6/6.7 (which lack the vb2 behavior added in upstream commit 88785982 where NULL wait_prepare/wait_finish auto-unlock q->lock), deleting these callbacks makes the blocking DQBUF wait hold `vcam_mutex` for its whole duration. Since the same mutex is `vdev->lock`, a thread blocked in DQBUF keeps the device lock, stalling concurrent STREAMOFF/QBUF/REQBUFS from other fds. The driver still targets old kernels via its version guards (6.8 and 4.17), so guard the removal: keep the two helper functions and restore the assignments for pre-6.6/6.7 kernels.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: On kernels before ~6.6/6.7 (which lack the vb2 behavior added in upstream commit 88785982 where NULL wait_prepare/wait_finish auto-unlock q->lock), deleting these callbacks makes the blocking DQBUF wait hold vcam_mutex for its whole duration. Since the same mutex is vdev->lock, a thread blocked in DQBUF keeps the device lock, stalling concurrent STREAMOFF/QBUF/REQBUFS from other fds. The driver still targets old kernels via its version guards (6.8 and 4.17), so guard the removal: keep the two helper functions and restore the assignments for pre-6.6/6.7 kernels.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At videobuf.c, line 141:

<comment>On kernels before ~6.6/6.7 (which lack the vb2 behavior added in upstream commit 88785982 where NULL wait_prepare/wait_finish auto-unlock q->lock), deleting these callbacks makes the blocking DQBUF wait hold `vcam_mutex` for its whole duration. Since the same mutex is `vdev->lock`, a thread blocked in DQBUF keeps the device lock, stalling concurrent STREAMOFF/QBUF/REQBUFS from other fds. The driver still targets old kernels via its version guards (6.8 and 4.17), so guard the removal: keep the two helper functions and restore the assignments for pre-6.6/6.7 kernels.</comment>

<file context>
@@ -103,18 +103,6 @@ static void vcam_stop_streaming(struct vb2_queue *vb2_q)
     spin_unlock_irqrestore(&dev->out_q_slock, flags);
 }
 
-static void vcam_outbuf_lock(struct vb2_queue *vq)
-{
-    struct vcam_device *dev = vb2_get_drv_priv(vq);
-    mutex_lock(&dev->vcam_mutex);
-}
-
</file context>