From: Mark Brown <broonie@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
Jonathan Cameron <jic23@kernel.org>,
Alexandru Ardelean <alexandru.ardelean@analog.com>,
linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
Date: Fri, 8 May 2020 13:57:46 +0100 [thread overview]
Message-ID: <20200508125746.GH4820@sirena.org.uk> (raw)
In-Reply-To: <20200508134307.0000233a@Huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Fri, May 08, 2020 at 01:43:07PM +0100, Jonathan Cameron wrote:
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > It feels like we should just make a devm_ version of regulator_enable().
> > Or potentially this is more complicated than it seems, but in that case
> > probably adding devm_add_action_or_reset() is more complicated than it
> > seems as well.
> It has been a while since that was last proposed. At the time the
> counter argument was that you should almost always be doing some form
> of PM and hence the regulator shouldn't have the same lifetime as the
> driver. Reality is that a lot of simple drivers either don't do
> PM or have elected to not turn the regulator off so as to retain state
> etc.
Same issue as before - I fear it's far too error prone in conjunction
with runtime PM, and if the driver really is just doing an enable and
disable at probe and remove then that seems fairly trivial anyway. I
am constantly finding abuses of things like regulator_get_optional()
(which we do actually need) in drivers and it's not like I can review
all the users, I don't have much confidence in this stuff especially
when practically speaking few regulators ever change state at runtime so
issues don't manifest so often.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-05-08 12:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 9:31 [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants Alexandru Ardelean
2020-05-02 18:25 ` Jonathan Cameron
2020-05-04 5:52 ` Ardelean, Alexandru
2020-05-07 9:50 ` Dan Carpenter
2020-05-08 12:43 ` Jonathan Cameron
2020-05-08 12:57 ` Mark Brown [this message]
2020-05-08 15:30 ` 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=20200508125746.GH4820@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=alexandru.ardelean@analog.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.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).