linux-kernel - Re: [RFC 0/5] drivers: Add boot constraints core

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: <CAGb2v67hxVciKFLD=8pgfm+UJ1i2Zb0aByTEa556O5uGcX7Oug@mail.gmail.com>
Date:   Fri, 30 Jun 2017 12:05:21 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        "Enrico Weigelt, metux IT consult" <enrico.weigelt@...3.net>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>, rnayak@...eaurora.org,
        Shiraz Hashim <shashim@...eaurora.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 30-06-17, 11:33, Chen-Yu Tsai wrote:
>> AFAIK regulator constraints are supposed to satisfy all users of it.
>
> Right.
>
>> >> >Let me try with an example. A regulator is shared between LCD and DMA
>> >> >controller.
>> >> >
>> >> >Operable ranges of the regulator: 1.8 - 3.0 V
>> >> >Range required by LCD: 2.0 - 3.0 V
>> >> >Range required by DMA: 1.8 - 2.5 V
>>
>> So for the example here, the regulator constraint should be 2.5 - 3.0 V,
>> or the intersection of all voltage requirements.
>
> Had a look at regulator_check_consumers() and the range selected by it
> is the *highest* min_uV and *lowest* max_uV, to find that intersection
> point.
>
> For LCD: min_uV = 2.0 V, max_uV = 3.0 V
> For DMA: min_uV = 1.8 V, max_uV = 2.5 V
>
> Highest min_uV = 2.0 V
> Lowest max_uV = 2.5 V
>
> And so I mentioned the regulator's final range (that satisfies all
> consumers) is 2 - 2.5 V.
>
> Why do you say it should be 2.5 - 3.0 V ?

You are right. It should be 2.0 - 2.5 V. Haven't had my coffee this
morning. :(

I also want to mention that for DT based platforms, this constraint
should already be set in the device tree for the regulator, so the
scenario where DMA comes up and sets a voltage level that LCD cannot
use should not even be possible.

ChenYu