Re: [RFC PATCH 2/5] media: iris: Update the CAPTURE stride and size on S_FMT(OUTPUT)

[Bryan O'Donoghue <bod@kernel.org>]

On 27/10/2026 03:19, Christian Cortner wrote:
> Setting the OUTPUT format also updates the width and height of the
> CAPTURE format, but bytesperline and sizeimage keep their old values,
> those of the 320x240 default on a new instance. For a 640x360 stream,
> VIDIOC_G_FMT(CAPTURE) then reports 640x384 NV12 with a sizeimage of
> 147456 bytes. VIDIOC_REQBUFS(CAPTURE) allocates buffers of that size,
> and iris_vb2_buf_prepare() rejects every one of them with -EINVAL,
> because it checks them against the size computed from the new width
> and height.

Again the commit log is a word salad. A much clearer problem statement 
should be possible.
"When updating the OUTPUT format we fail to update some variables which 
we should be updating i.e. bytesperline and sizeimage."

Simple and clear, like myself ;)

> Move the per-format rules S_FMT(CAPTURE) uses into a helper and call it
> for both queues, so that S_FMT(OUTPUT) leaves the CAPTURE format exactly
> as S_FMT(CAPTURE) would set it for the same size.
> 
> Fixes: 8aadfd445373 ("media: iris: Update CAPTURE format info based on OUTPUT format")
> Cc:stable@vger.kernel.org
> Assisted-by: LLM sparse smatch

On the substance here I like it.

- Functional decomposition
- Reuse

So... I'd be inclined to take this. It fixes a real bug.

---
bod