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:   Mon, 23 Sep 2019 11:36:11 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Marco Felsch <m.felsch@...gutronix.de>, 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

Hi,

On Mon, Sep 23, 2019 at 11:14 AM Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Sep 23, 2019 at 11:02:26AM -0700, Doug Anderson wrote:
>
> > I will freely admit my ignorance here, but I've always been slightly
> > confused by the "always-on" vs. "boot-on" distinction...
>
> > The bindings say:
>
> >   regulator-always-on:
> >     description: boolean, regulator should never be disabled
>
> >   regulator-boot-on:
> >     description: bootloader/firmware enabled regulator
>
> > For 'boot-on' that's a bit ambiguous about what it means.  The
> > constraints have a bit more details:
>
> Boot on means that it's powered on when the kernel starts, it's
> for regulators that we can't read back the status of.

1. Would it be valid to say that it's always incorrect to set this
property if there is a way to read the status back from the regulator?

2. Would this be a valid description of how the property is expected to behave
a) At early boot this regulator will be turned on if it wasn't already on.
b) If no clients are found for this regulator after everything has
loaded, this regulator will be automatically disabled.

If so then I don't _think_ #2b is happening, but I haven't confirmed.

> > ...but then that begs the question of why we have two attributes?
> > Maybe this has already been discussed before and someone can point me
> > to a previous discussion?  We should probably make it more clear in
> > the bindings and/or the constraints.
>
> boot-on just refers to the status at boot, we can still turn
> those regulators off later on if we want to.

How, exactly?  As of my commit 5451781dadf8 ("regulator: core: Only
count load for enabled consumers") if you do:

  r = regulator_get(...)
  regulator_disable(r)

...then you'll get "Underflow of regulator enable count".  In other
words, if a given regulator client disables more times than it enables
then you will get an error.  Since there is no client that did the
initial "boot" enable then there's no way to do the disable unless it
happens automatically (as per 2b above).

...or do you mean that people could call regulator_force_disable()?
Couldn't they also do that with an always-on regulator?

-Doug