linux-kernel - Re: [PATCH v2] regulator: devres: introduce managed enable and disable operations

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]

Message-ID: <20170213185152.GC20057@dtor-ws>
Date:   Mon, 13 Feb 2017 10:51:52 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] regulator: devres: introduce managed enable and
 disable operations

On Mon, Feb 13, 2017 at 06:01:29PM +0000, Mark Brown wrote:
> On Sun, Feb 12, 2017 at 06:32:49PM -0800, Dmitry Torokhov wrote:
> 
> > v2: restored lost regulator_disable() stub
> 
> > Mark, note that there is also patch introducing devm_clk_prepare() and
> > devm_clk_prepare_enable() that Russell did not hate so I think it will
> > get applied eventually. I believe lack of CLK methods was cited as a
> > reason for not having managed enable for regulators.
> 
> No, that's never been an issue.  The concern is partly that nobody
> bothered writing the patch but also that it gets messy over suspend and
> resume since you end up with drivers either doing explicit releases of
> managed resources (which is not normally a good pattern) or mixing
> managed and unmanaged access to the same resource which is also fun.  

I see where you are coming from, but I think that it is lesser concern
than mixing managed and unmanaged resources in probe() and remove() and
making sure that release order is right when they are mixed like that.

I think it is helps if you think about devm_regulator_enable and regular
regulator_enable as managed and unmanaged *actions*, not resources. So
managed action of enabling regulator will be undone on remove() and you
have to manually undo unmanaged regulator_disable() on resume(). It is
not worse than having unbalanced regulator_enable/disable between
probe()/suspend()/resume()/remove().

Thanks.

-- 
Dmitry