[PATCH 0/2] media: amd: isp4: two fixes found on the ROG Flow Z13

[Seifelden Abdelmonem]

These are two small fixes for the AMD ISP4 capture driver. I found
them while bringing up the OV13B10 rear camera of the ASUS ROG Flow Z13
(GZ302EA, ACPI ID OMNI13B1), which is discussed in [1]. Both fixes are
independent of that sensor and apply to the driver as merged.

Patch 1 holds buf_list_lock while start_streaming hands the queued
buffers to the firmware. The firmware response thread can remove
completed buffers from the same list during that walk; I hit the
resulting list corruption as an oops.

Patch 2 makes completed buffers report V4L2_FIELD_NONE instead of
V4L2_FIELD_ANY, which v4l2-compliance rejects.

The two patches are independent of each other and apply in any order.

Testing: the GZ302 camera is not supported upstream, so I applied the
patches to an out-of-tree build of this driver that streams on that
machine (NV12 1920x1080, about 30 fps). The stock linux-firmware image
does not start this sensor; on my machine the camera runs with ISP
firmware and sensor setup data from my own Windows driver
installation, read from the Windows partition of that machine. I do
not redistribute any of it.
- 6 stream starts with patch 1 alone and 6 with both patches (each
  time 5 captures of 90 frames plus the v4l2-compliance run); no oops,
  hung task or WARN.
- With both patches, s2idle suspend and hibernation with the camera
  idle: capture works before and after.
- v4l2-compliance -s: 52 of 58 without the patches, the same 52 with
  patch 1, 53 with both.
- W=1 build (clang) on media-committers next. Not run: lockdep,
  sparse, smatch.

Known issues, not addressed by this series:
- The remaining 5 v4l2-compliance failures all stop at
  v4l2-test-buffers.cpp:1651: CREATE_BUFS with half the sizeimage after
  REQBUFS is expected to fail with EINVAL and does not. A likely cause,
  not yet confirmed: isp4vid_qops_queue_setup() writes the requested
  size back into isp_vdev->format.sizeimage, so a larger CREATE_BUFS
  earlier in the test raises the size that later requests are checked
  against.
- A stream does not survive system sleep. Start a stream, then
  "rtcwake -m mem -s 20": after resume no further frame arrives, and
  stopping the stream logs "fail to disable stream" and "fail to stop
  stream". The same happens without these patches; the driver has no
  system-sleep callbacks. On the GZ302 the command timeouts return; the
  stop-path hang reported in [1] may be related. This should be
  reproducible on the HP ZBook Ultra G1a, and I can test a fix on the
  GZ302.
- Hibernating while a stream is running hung the GZ302 once, during
  hibernation, and needed a forced power-off. That run used both
  patches and I did not repeat it without them, so I cannot say yet
  whether it predates them; neither patch touches the sleep path.

AI use: Claude (Claude Code) helped me analyse the code, write the
changes and the changelogs, and run the checks. I reviewed the patches
and ran the hardware tests.

[1] https://lore.kernel.org/all/lWYl1YJwDSh-q2Ew2f8b0BweQ4V-SUnPMSMurU5gT1LkqVdrmWFunj0sSgjC7m66bORBAD_jRCFTt1_ZOkotOMukY46rI4ayYbIfPQq4E9U=@proton.me/

Seifelden Abdelmonem (2):
  media: amd: isp4: hold buf_list_lock while sending buffers at stream
    start
  media: amd: isp4: return capture buffers with V4L2_FIELD_NONE

 drivers/media/platform/amd/isp4/isp4_video.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)


base-commit: d7e7bca7169873b46e857c025c10f3336c1258d8
-- 
2.56.0