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
| ||
|
Message-ID: <CAL_JsqJzMfNhHK=6Wt4dzBRS9BVGMZ-f7uk3OnUupudTfwuyUA@mail.gmail.com> 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
Powered by blists - more mailing lists