linux-kernel - Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

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: <CAPDyKFryn5=GMs+hiRcxGOC1U=-LL9RQdnY3cWniyE+4pwQDog@mail.gmail.com>
Date:   Tue, 28 Nov 2017 17:38:52 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Stephen Boyd <sboyd@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Rafael Wysocki <rjw@...ysocki.net>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain
 magic values

On 2 November 2017 at 10:00, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 02-11-17, 00:15, Stephen Boyd wrote:
>> Sorry I'm not following. We're going to need to have platform
>> specific code that understands platform specific bindings that
>> aren't shoved into the generic OPP bindings.
>
> At least I am not targeting any platform specific binding right now.
> The way I see this to work is:
>
> - We will reuse earlier bindings and allow opp-hz and opp-microvolt to
>   contain special values (this patch).
> - Platform specific DT entries will put corner numbers in opp-hz (or
>   opp-microvolt) fields.
> - Some platform specific driver (in OPP or genpd) will be used to
>   convert OPP into a performance state (corner) value. Now that can
>   simply read opp-hz (or opp-microvolt) and return its value.

Since the "operating-points-v2" phandle(s) belongs in the power-domain
controller device node, which anyway is being parsed by the genpd SoC
specific driver, I assume it makes sense to start the initialization
from there. Unless there is something that prevents that, of course.

Then whatever library/helper functions we need for parse and create
the OPP tables, can be provided to the OPP framework and the OPP OF
library.

> - OPP core will request for a performance state (code is already
>   merged for that).
>
> And so there is no platform specific binding here. Do you want to do
> this differently ?

This makes sense to me!

Also, the SoC (QCOM) specific genpd driver is free to use the
terminology "corner values", when it translates opp-hz|microvolt into
such values.

Kind regards
Uffe