linux-kernel - Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

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: <20161123034657.GB22335@vireshk-i7>
Date:   Wed, 23 Nov 2016 09:16:57 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>, nm@...com,
        sboyd@...eaurora.org, linaro-kernel@...ts.linaro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>, robh@...nel.org,
        d-gerlach@...com
Subject: Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

On 22-11-16, 18:41, Mark Brown wrote:
> On Tue, Nov 22, 2016 at 09:19:22AM +0530, Viresh Kumar wrote:
> > "How do we know (from the DT) the order in which entries for multiple regulators
> > are present in the OPP table?"
> > 
> > And I am not sure if we can do that without having a property like:
> > 
> > +               supply-names = "vcc0", "vcc1", "vcc2";
> > 
> > in the OPP table or the consumer device. And surely it isn't a clean enough
> > solution and that's why this series relied on the code to get such details.
> > 
> > Does someone have an alternative? If NO, can we go ahead with this series as is?
> 
> I'm really not at all clear why this has to be in DT.  My understanding
> was that this is basically a helper library for more specific bindings
> which already have to hard code things like sequencing so surely they'd
> be specifying the ordering to be used when supplying data?

I am a bit confused and perhaps I am misreading your feedback.

Are you saying that:

"we don't need to identify which microVolts value in the OPP table corresponds
to which supply from the DT itself and we can do that with some hard coded
stuff" ?

If yes, then below is from an earlier email from you, which I feel is opposite
of what you are suggesting now.

On 09-11-16, 14:58, Mark Brown wrote:
> On Wed, Oct 26, 2016 at 12:02:56PM +0530, Viresh Kumar wrote:

> > The platform driver is responsible to identify the order and pass it on to the
> > OPP core. And the platform driver needs to have that hard coded.
>
> That *really* should be in the binding.  Honestly if the binding is this
> vague I'm not even clear that it's worth documenting these properties at
> this level, might be better to just put the documentation in the
> platform driver bindings.

-- 
viresh