linux-kernel - Re: [PATCH V8 3/3] 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]

Date:   Wed, 27 Dec 2017 15:54:37 -0600
From:   Rob Herring <robh@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Kevin Hilman <khilman@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Rafael Wysocki <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain
 magic values

On Wed, Dec 27, 2017 at 2:56 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 26-12-17, 14:29, Rob Herring wrote:
>> On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:
>
>> > +On some platforms the exact frequency or voltage may be hidden from the OS by
>> > +the firmware and the "opp-hz" or the "opp-microvolt" properties may contain
>> > +magic values that represent the frequency or voltage in a firmware dependent
>> > +way, for example an index of an array in the firmware.
>>
>> I'm still not convinced this is a good idea.
>
> You were kind-of a few days back :)
>
> lkml.kernel.org/r/CAL_JsqK-qtAaM_Ou5NtxcWR3F_q=8rMPJUm-VqGtKhbtWe5SAQ@...l.gmail.com

Yeah, well that was before Stephen said anything.

> So here is the deal:
>
> - I proposed "domain-performance-state" property for this stuff
>   initially.
> - But Kevin didn't like that and proposed reusing "opp-hz" and
>   "opp-microvolt", which we all agreed to multiple times..
> - And we are back to the same discussion now and its painful and time
>   killing for all of us.

There's bigger issues than where we put magic values as I raised in
the other patch.

> TBH, I don't have too strong preferences about any of the suggestions
> you guys have and I need you guys to tell me what binding changes to
> do here and I will do that.
>
>> If you have firmware
>> partially managing things, then I think we should have platform specific
>> bindings or drivers.
>
> What about the initial idea then, like "performance-state" for the
> power domains ? All platforms will anyway replicate that binding only.

I don't really know. I don't really care either. I'll probably go
along with what everyone agrees to, but the only one I see any
agreement from is Ulf. Also, it is pretty vague as to what platforms
will use this. You claimed you can support QCom scenarios, but there's
really no evidence that that is true. What I don't want to see is this
merged and then we need something more yet again in a few months for
another platform.

Rob