From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
Dinghao Liu <dinghao.liu@zju.edu.cn>, Kangjie Lu <kjlu@umn.edu>,
Lars-Peter Clausen <lars@metafoo.de>,
"Peter Meerwald-Stadler" <pmeerw@pmeerw.net>,
linux-iio <linux-iio@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error
Date: Mon, 12 Apr 2021 11:15:06 +0100 [thread overview]
Message-ID: <20210412111506.0000653c@Huawei.com> (raw)
In-Reply-To: <CACRpkdYrRi3pa6Gw4_Q+P=WYbv-a27FHmOupKVv5s=yU53RFWA@mail.gmail.com>
On Mon, 12 Apr 2021 00:38:41 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, Apr 11, 2021 at 5:07 PM Jonathan Cameron <jic23@kernel.org> wrote:
> > On Wed, 7 Apr 2021 11:49:27 +0800
> > Dinghao Liu <dinghao.liu@zju.edu.cn> wrote:
> >
> > > When devm_request_threaded_irq() fails, we should decrease the
> > > runtime PM counter to keep the counter balanced. But when
> > > iio_device_register() fails, we need not to decrease it because
> > > we have already decreased it before.
> >
> > Whilst agree with your assessment that the code is wrong, I'm not
> > totally sure why we need to do the pm_runtime_get_noresume() in
> > the first place. Why do we need to hold the reference for
> > the operations going on here? What can race against this that
> > might care about that reference count?
>
> pm_runtime_get_noresume() is increasing the runtime PM
> reference without calling the pm_runtime_resume() callback.
>
> It is often called in sequence like this:
>
> pm_runtime_get_noresume(dev);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
>
> This increases the reference, sets the device as active
> and enables runtime PM.
>
> The reason that probe() has activated resources such as
> enabling two regulators, and want to leave them on so that
> later on pm_runtime_suspend() will disable them, i.e.
> handover to runtime PM with the device in resumed state.
>
> I hope this is answering the question, not sure.
There are drivers that look the same except they aren't
holding the reference. Are those immediately disabling the power?
I can't see the path by which that happens, but perhaps I'm just
missing something? Maybe this is just paranoid locking in
a probe path (before we are in a position where races can occur)?
An example would be the bmc150_magn driver which does exactly the
same call sequence as this one, but without the reference count increment
and decrement. Basically I want to know if there is a problem in
those other drivers that is being protected against here!
>
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2021-04-12 10:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 3:49 [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error Dinghao Liu
2021-04-07 7:16 ` Linus Walleij
2021-04-11 15:07 ` Jonathan Cameron
2021-04-11 22:38 ` Linus Walleij
2021-04-12 10:15 ` Jonathan Cameron [this message]
2021-04-12 11:47 ` Linus Walleij
2021-04-18 9:43 ` Jonathan Cameron
2021-04-19 10:28 ` Linus Walleij
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=20210412111506.0000653c@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=dinghao.liu@zju.edu.cn \
--cc=jic23@kernel.org \
--cc=kjlu@umn.edu \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.