Re: [PATCH v7 4/4] iio: light: veml6031x00: add support for events and trigger
"Javier Carrasco" <[email protected]>
| Newsgroups | org.kernel.vger.linux-iio,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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