From: Jonathan Cameron <jic23@kernel.org>
To: Akshay Jindal <akshayaj.lkd@gmail.com>
Cc: anshulusr@gmail.com, dlechner@baylibre.com, nuno.sa@analog.com,
andy@kernel.org, shuah@kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: light: ltr390: Add runtime PM support
Date: Sat, 30 Aug 2025 19:08:06 +0100 [thread overview]
Message-ID: <20250830190806.7dd92eb9@jic23-huawei> (raw)
In-Reply-To: <CAE3SzaR14zWWM_g-H4C76+6fBDotuAux7n2V1g94R2xLFQZOYQ@mail.gmail.com>
On Tue, 26 Aug 2025 02:29:12 +0530
Akshay Jindal <akshayaj.lkd@gmail.com> wrote:
> Hi Jonathan,
> Thanks for your review. Please see my followup inline.
>
> On Mon, Aug 25, 2025 at 7:56 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Fri, 22 Aug 2025 23:33:26 +0530
> > Akshay Jindal <akshayaj.lkd@gmail.com> wrote:
> > > +
> > > + if (!state) {
> > > + ret = regmap_clear_bits(data->regmap, LTR390_INT_CFG, LTR390_LS_INT_EN);
> > > + data->irq_enabled = false;
> >
> > Just take an extra reference to runtime pm on enable of event and put it disable.
> > Then no need for special handling with a local flag etc.
>
> Consider a scenario, where the user only disables the event instead of
> enabling it,
> (i.e. user wrote 0 on the sysfs attribute before it was 1). In this case,
> If enable means inc ref count and disable means dec ref count, then
> this would lead to refcount underflow and the suspend callback will
> not be called.
>
> To handle this case, we would need to check whether irq/event was
> enabled or not.
> For that either we can use the local flag as I did, or I would need to
> do a read and test
> for the interrupt bit being set. I feel using the local flag would be
> cleaner and would
> require less code.
> If you are fine with local flag usage, then shall I not stick to only
> local flag usage?
>
Normally we'd check the register to find out what whether the event
is enabled or not. If we are asking for the state it is already in
then just return having done nothing. If bus reads are an overhead
worth avoiding regcache will ensure we only do it once.
Then if we are doing something, do the runtime pm get / put as appropriate.
Jonathan
> Thanks,
> Akshay
next prev parent reply other threads:[~2025-08-30 18:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 18:03 [PATCH] iio: light: ltr390: Add runtime PM support Akshay Jindal
2025-08-22 20:11 ` Andy Shevchenko
[not found] ` <CAE3SzaSW7j0yNaD9yQzc5KcJ-LH00TGebLQYDkuqwjky3ZBohA@mail.gmail.com>
2025-08-24 19:18 ` Andy Shevchenko
2025-08-23 16:03 ` David Lechner
2025-08-25 14:26 ` Jonathan Cameron
2025-08-25 20:59 ` Akshay Jindal
2025-08-30 18:08 ` Jonathan Cameron [this message]
2025-08-30 19:49 ` Akshay Jindal
2025-08-31 15:08 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250830190806.7dd92eb9@jic23-huawei \
--to=jic23@kernel.org \
--cc=akshayaj.lkd@gmail.com \
--cc=andy@kernel.org \
--cc=anshulusr@gmail.com \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).