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: <20161122184103.djm3jn67gshdtun4@sirena.org.uk>
Date:   Tue, 22 Nov 2016 18:41:03 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.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 Tue, Nov 22, 2016 at 09:19:22AM +0530, Viresh Kumar wrote:

> So the LAST remaining question is:

> "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?

Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)