Re: [PATCH v3 2/2] iio: light: veml3328: add support for new device

[Joshua Crofts]

On Mon, 1 Jun 2026 at 16:43, Joshua Crofts <joshua.crofts1@xxxxxxxxx> wrote:
>
> On Mon, 1 Jun 2026 at 11:17, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> >
> > If you have time to figure out the path that causes that, it would be excellent
> > to have it recorded. I spent a few minutes the other day on this and couldn't
> > find it.  Maybe ask AI to figure it out :)

Briefly analyzing this with AI (Gemini 3.1 Pro, just like Sashiko). I
noticed that
in drivers/base/dd.c the specific driver probe function is called and then
pm_request_idle() is called after it in _driver_probe_device(), which
is probably
the reason the sensor is suspended after probe even though I didn't
explicitly call
pm_runtime_put_autosuspend() (odd that this behaviour in the actual
driver base).

To err on the side of caution, I'd add a pm_runtime_get_noresume() call before
setting up autosuspend and a
pm_runtime_mark_last_busy()/pm_runtime_get_autosupend()
combo before registering the device. Technically Sashiko is correct, this isn't
explicitly done in the driver, nevertheless the driver base actually
handles this
if pm_runtime is correctly set up and callbacks are defined.

Jonathan - up to you if you want to fix up the driver since it's
already committed
or if I should send a patch (I guess it isn't that critical, but it
keeps Sashiko quiet
in future patches).

-- 
Kind regards

CJD