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

[Javier Carrasco]

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:
>> On Wed Aug 19, 2026 at 6:42 AM CEST, Andy Shevchenko wrote:
>> > On Tue, Aug 18, 2026 at 06:10:51PM +0200, Javier Carrasco wrote:
>> >> On Tue Aug 18, 2026 at 4:01 PM CEST, Andy Shevchenko wrote:
>
> ...
>
>> >> >> +	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!
>
>> 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