linux-kernel - Re: [PATCH] staging: iio: ad5933: rework probe to use devm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 May 2020 13:57:46 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        linux-iio@...r.kernel.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function
 variants

On Fri, May 08, 2020 at 01:43:07PM +0100, Jonathan Cameron wrote:
> Dan Carpenter <dan.carpenter@...cle.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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)