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]

Message-ID: <054bc4c050f1b16988de057f812232b0feb707cb.camel@fi.rohmeurope.com>
Date:   Fri, 4 Oct 2019 12:03:12 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "dianders@...omium.org" <dianders@...omium.org>,
        "m.felsch@...gutronix.de" <m.felsch@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "zhang.chunyan@...aro.org" <zhang.chunyan@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ckeepax@...nsource.cirrus.com" <ckeepax@...nsource.cirrus.com>
Subject: Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count
 usage


On Fri, 2019-10-04 at 12:32 +0100, Mark Brown wrote:
> 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.

I thought the regulator-boot-on could have been used for that. But as I
said - I don't really know all this so well =) And no, I am not opposed
to offloading this from kernel to boot, I was just trying to learn what
is the correct thing to do (tm). Thanks for educating me on this :) I
will suggest adding the enabling to boot code if (when) I get questions
concerning this. (always-on won't do for regulators which need to be
controlled for power saving or heating issues).

Br,
	Matti Vaittinen