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: <20191119193636.GH3634@sirena.org.uk>
Date:   Tue, 19 Nov 2019 19:36:36 +0000
From:   Mark Brown <broonie@...nel.org>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     "corbet@....net" <corbet@....net>, "pavel@....cz" <pavel@....cz>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "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>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "hofrat@...dl.org" <hofrat@...dl.org>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings

On Tue, Nov 19, 2019 at 06:51:37PM +0000, Vaittinen, Matti wrote:
> On Tue, 2019-11-19 at 18:13 +0000, Mark Brown wrote:

> > Ah, OK.  I didn't even notice that patch when I scanned the series.
> > I'll look out for this next time around but that sounds like it's
> > generally going in the right direction, especially if it's integrated
> > with the suspend mode regulator bindings that Chunyan did.

> Probably it is not as I am not familiar with Chunyan's work. I'll try
> looking what has been done on that front :) And I am pretty sure you
> might not be happy with that patch - but perhaps you can give me a
> nudge to better direction...

The driver interface was added in "regulator: add PM suspend and resume
hooks".

> > Yes, I think this needs clarification as I completely failed to pick
> > up
> > on this and did indeed read this as referring to the
> > modes.  "Voltages
> > that can be set in RUN mode" or something?  I take it these voltages
> > are
> > fixed and the OS can't change them?

> Unfortunately they are not. Voltages and enable/disable statuses for
> each run-level (and individually for each run-level capable buck) can
> be changed at runtime via I2C. And a customer requested me also to
> support this - hence the in-kernel API - but I am sure you have some
> nice words when you check the patch 12. :]

Ah, that's actually better.  It opens up possiblities for making use of
the feature without encoding voltages in DT.  For example, you can cache
the last however many voltages that were set and jump quickly to them or
do something like put the top of the constraints in to help with
governors like ondemand.  I'd recommend trying for something like that
rather than encoding in DT, it'll probably be more robust with things
like cpufreq changing.

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