linux-kernel - Re: [PATCH 1/3] regulator: core: fix boot-on regulators use

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, 4 Oct 2019 12:32:34 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc:     Doug Anderson <dianders@...omium.org>,
        Marco Felsch <m.felsch@...gutronix.de>,
        Chunyan Zhang <zhang.chunyan@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        ckeepax@...nsource.cirrus.com, LKML <linux-kernel@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>
Subject: Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count
 usage

On Fri, Oct 04, 2019 at 09:34:43AM +0300, Matti Vaittinen wrote:
> On Tue, Oct 01, 2019 at 12:57:31PM -0700, Doug Anderson wrote:

> > I don't think your fix is correct.  It sounds as if the intention of
> > "regulator-boot-on" is to have the OS turn the regulator on at bootup
> > and it keep an implicit reference until someone explicitly tells the
> > OS to drop the reference.

> Hmm.. What is the intended way to explicitly tell the OS to drop the
> reference? I would assume we should still use same logic as with other
> regulators - if last user calls regulator_disable() we should disable
> the regulator? (I may not understand all this well enough though)

Yes.

> > It's a fixed regulator controlled by a GPIO?  Presumably the GPIO can
> > be read.  That would mean it ideally shouldn't be using
> > "regulator-boot-on" since this is _not_ a regulator whose software
> > state can't be read.  Just remove the property.

> How should we handle cases where we want OS to enable regulator at
> boot-up - possibly before consumer drivers can be load?

If you want the regulator to be on without any driver present then mark
it always-on.  If you want the regulator to be enabled prior to the
driver being loaded then the expectation is that the bootloader will do
that, it's difficult to see what the benefit there is from having the
kernel enable things when it starts prior to having a driver unless the
intent is to keep the regulator always on.

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