Re: What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

[Laurent Pinchart]

On Sun, Nov 08, 2026 at 06:05:34PM +0200, Tomi Valkeinen wrote:
> On 08/11/2026 12:25, Laurent Pinchart wrote:
> > On Sat, Nov 07, 2026 at 05:31:06PM -0800, DelaySystem wrote:
> >>
> >> Hello,
> >>
> >> While working on drivers/staging/media/tegra-video I ran into the FIXME
> >> above __tegra_channel_try_format() in vi.c (added by commit 40aaab9d773b
> >> in 2022):
> >>
> >> 	/* FIXME: Drop this call, drivers are not supposed to use
> >> 	 * __v4l2_subdev_state_alloc(). */
> >>
> >> The driver needs a scratch TRY state to negotiate formats with the remote
> >> sensor subdev from video-node ioctl context, where no subdev file handle
> >> exists. I looked for the intended replacement, but:
> >>
> >> - there is no non-dunder allocator in drivers/media or include/media;
> >> - v4l2_subdev_call_state_try() is documented for legacy non-MC drivers
> >>    only, has no in-tree users, and allocates one state per call, while the
> >>    driver needs one state across enum_frame_size + set_fmt + get_crop;
> >> - the active-state APIs have the wrong semantics here, since try_fmt must
> >>    not disturb ACTIVE state;
> >> - the same FIXME is still present in mainline vsp1 and staging atomisp,
> >>    and mainline stm32-dcmi still calls the dunder directly, with (as far
> >>    as I can tell) zero conversions since the 2022 rename.
> >>
> >> So my question: is a new core helper the intended direction for the
> >> bridge-driver scratch-TRY-state case, and if so, is there any guidance
> >> on the shape it should take? Or is there an existing pattern I missed?
> >>
> >> If a new helper is the answer, I am happy to implement it and convert
> >> the in-tree users.
> > 
> > No, that's not the answer.
> 
> I think converting to MC is the answer. At least for a staging driver.

Note that usage of LLMs is not allowed in drivers/staging/

-- 
Regards,

Laurent Pinchart