Re: [PATCH RFC 5/5] media: imx219: Add status polling using .detect()

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

Hi Sakari,

On Fri, Oct 02, 2026 at 10:21, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:

> Hi Dave, Mattij,
>
> On Thu, Oct 01, 2026 at 04:58:57PM +0100, Dave Stevenson wrote:
>> Hi Mattij
>> 
>> On Thu, 1 Oct 2026 at 13:55, Mattijs Korpershoek
>> <mkorpershoek@kernel.org> wrote:
>> >
>> > Userspace needs to be notified when a sensor connection status
>> > changes (e.g. disconnected at boot, then later reconnected) so it can
>> > react accordingly.
>> >
>> > Add periodic polling using a delayed work that calls .detect() every
>> > 2s and sends a KOBJ_CHANGE uevent with HOTPLUG=1 on status changes.
>> > This mirrors the approach used by DRM connectors in output_poll_execute().
>> 
>> AIUI DRM polls from within the framework (drm_probe_helper.c), not by
>> a workqueue in the individual drivers.
>> 
>> Admittedly V4L2 doesn't currently have a totally obvious place to
>> setup this, but it would be far less effort to have the polling
>> framework within the core code rather than driver.
>> Possibly initialised in __v4l2_async_register_subdev_sensor() based on
>> whether .detect is set, and cleaned up in
>> v4l2_async_unregister_subdev, with the workqueue calling .detect and
>> generating the udev event based on the return value? I think that's
>> feasible.
>
> Sounds good to me.
>
> I'd also put this behind a Kconfig option, the use case is rather special.

Ack

>
> Also there are different approaches to this: in some cases you may want to
> know the values written to the device's registers get updated so you write
> and read, then some devices might crash in a way they're not doing their
> real job while still allowing reading registers as usual. These are rare
> cases though.

As far as I understand, that's device specific so could be handled in
the device specific .detect() implementation?

>
> Should the interval be at least configurable? That indeed further suggests
> the use of controls for this.

I agree that the current polling interval is completely arbitrary and
not a proper value.
I'll move it 10s for v2 but will also look into making it configurable.

I'll also look into controls.

Thanks for the suggestions!

Mattijs

>
> -- 
> Regards,
>
> Sakari Ailus