linux-kernel - Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings

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: <20191202131140.GD1998@sirena.org.uk>
Date:   Mon, 2 Dec 2019 13:11:40 +0000
From:   Mark Brown <broonie@...nel.org>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     "corbet@....net" <corbet@....net>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings

On Mon, Dec 02, 2019 at 07:57:13AM +0000, Vaittinen, Matti wrote:
> On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote:

> > The regulator driver has a bunch fo set_suspend_ operations.

> Hmm. I saw these. But unless I am mistaken linux only knows one
> 'suspend' state whereas the PMIC has a few separate states I can see as
> 'suspend' states. As far as I understood the set_suspend_voltage does
> not allow setting separate suspend voltages depending on the "type of
> suspend" (as there is only one 'suspend' state).

No, look at the bindings - we support a bunch of different
suspend states matching the different suspend states that the
kernel as a whole supports.  We don't assume that the device will
know this but you can always use the current suspend we're going
for to decide where to update.

> > > (RUN0, ... RUN3) could be mapped to regulator modes
> > > REGULATOR_MODE_FAST, REGULATOR_MODE_NORMAL, REGULATOR_MODE_IDLE
> > > and 
> > > REGULATOR_MODE_STANDBY. But regulators which are controlled by
> > > these

> > That doesn't make sense at all, the modes affect the quality of
> > regulation not the voltage that is set.

> Thanks. I misunderstood this. I thought these states could be used for
> some adaptive voltages. My understanding is that the RUN0,...RUN3 are
> designed for that - but I didn't know if regulator framework is
> designed for this.

The framework doesn't care how a device is controlled, that's up
to the device.  Like I said I recommend figuring out what
voltages are useful to have quick access to at runtime, for
example it's likely that it's good to have quick access to the
highest voltage that's been set (and/or the top of the
constraints).

> > The cpufreq code is all there in kernel - drivers/cpufreq.  I can't
> > remember if Android still has a custom governor in their trees but it
> > doesn't really make much difference in terms of how it interacts with
> > the regulator drivers.

> Right. I guess your answers mean that there is no "regulator group
> control" for "adaptive voltage changes" supported by regulator

I can't parse the above, sorry.  What is "regulator group
control"?

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