What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

[DelaySystem]

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.

Thank you,
DelaySystem

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart