Re: [PATCH v7 4/4] iio: light: veml6031x00: add support for events and trigger

On Wed Aug 19, 2026 at 8:54 PM CEST, Andy Shevchenko wrote:

On Wed, Aug 19, 2026 at 08:33:30PM +0200, Javier Carrasco wrote:

quoted

On Wed Aug 19, 2026 at 6:42 AM CEST, Andy Shevchenko wrote:

quoted

On Tue, Aug 18, 2026 at 06:10:51PM +0200, Javier Carrasco wrote:

quoted

On Tue Aug 18, 2026 at 4:01 PM CEST, Andy Shevchenko wrote:

...

quoted

quoted

quoted

quoted

quoted

+	ret = pm_runtime_get_if_active(dev);
+	if (ret <= 0)

< 0 seems too much to me. If there is disabled runtime PM (and supposedly
device is always on) this prevents from getting events.

I am not sure if I get this. A reference is unconditionally acquired
when events are enabled as well as in buffer_preenable, and also in the
probe before interrupts are enabled. Runtime PM should be active at this
point. If not, the interrupt should not come from the device, even if it
was on (e.g. before autosuspend kicks in). But maybe I am missing
 something?

The device maybe in these states here:
- powered off (by runtime PM) ret == 0
- powered on (by some previous activity) ret > 0
- always on (PM is disabled by user space, for example) ret < 0

Are you telling that the third case is impossible? (Note that autosuspend in
this case is irrelevant.)

I followed the execution paths and the third case seems to be impossible.

Thanks for checking this!

quoted

Setting power/control to "on" calls pm_runtime_forbid()[1], which sets
runtime_auto to false and increments the usage counter. Note that it does
not update disable_depth, which is the variable that pm_runtime_disable()
updates and what pm_runtime_get_if_active() checks to return -EINVAL if
runtime PM is disabled. Therefore, pm_runtime_get_if_active() should
return a positive value under this configuration.

Would it be possible to have negative value at all from
pm_runtime_get_if_active() here?

That is not possible with pm_runtime_get_if_active() in this case: it is
just a wrapper around pm_runtime_get_conditional() with ign_usage_count
set to true, and therefore, the only path that could return a value other
than -EINVAL, 0, or 1 through the return value of atomic_inc_not_zero()
cannot be reached.

Best regards,
Javier