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: <ccc533df4e00bdcbe18ea45a0e0679161ff41354.camel@fi.rohmeurope.com>
Date:   Tue, 10 Dec 2019 11:14:48 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
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

Hello Mark,

On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote:
> On Fri, Nov 29, 2019 at 07:48:13AM +0000, Vaittinen, Matti wrote:
> > On Tue, 2019-11-19 at 19:36 +0000, Mark Brown wrote:
> 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.
> 
> > Anyways, my idea was to set the inital voltage values for these
> > states
> > via DT - but allow the voltages to be changed at run-time too (I
> > guess
> > this idea is visible in the patch 12).
> 
> It'd be much better if you could avoid putting the voltages in the
> binding if they're not strictly required.

You suggested in the other mail that it might be worth making a run-
level 'group' consisting only one buck for fast voltage changes via
GPIOs. So I am back to adding the run-level support to the BD71828
driver. Which lead me back to this.

The PMIC supports wide range of voltages for these DVS bucks - but only
4 of these voltages can be selected to be switched fast via GPIO line
states. Eg, in HW level we can set RUN0 voltage (selected when both
GPIO lines are LOW) to one register. RUN1 voltage (selected when one
GPIO is high, other low) to second register. Same for RUN2 and RUN3
voltages.

I could make this so that initially there is the HW default voltages
are read up by driver and cached to be used for each level. When new
voltage is requested by the consumer, correct RUN level is selected or
if matching voltage is not set to any RUN level, then it is written to
one of the run level registers (and cache).

Problem is that if no default voltages are given from DT, the the first
voltage changes are likely to be slow (require register access - I
guess the HW defaults are not working for many use-cases) - which may
be undesirable.

So I still think the DT bindings for setting these initial values might
be the most convenient way if we are not adding custom API for this.
Hence I plan to keep this binding. Please let me know if you have
better ideas or if this is absolutely a no go.

Br,
	Matti Vaittinen