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

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 2 Jun 2026 10:14:59 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> On Mon, 1 Jun 2026 at 16:43, Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> >
> > On Mon, 1 Jun 2026 at 11:17, Jonathan Cameron <jic23@kernel.org> 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).

It kind of makes sense as it's basically a now you are finished, should this
be going to sleep call.  I never thought of looking there.
I did some archaeology and via 3 refactors / bug fixes that call goes all the
way back to the introduction of runtime PM 17 years ago.


> 
> 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).
It is fine as it stands - lets just keep replying to tell sashiko it is wrong
until it learns :)

Arguably we should be ripping out some of the dance that is going on in current
drivers so as to remove unnecessary complexity.  I'm nervous to do that on anything
we can't test.

Thanks for looking into this!


Jonathan

>