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] [day] [month] [year] [list]

Message-ID: <20161124101936.do2zccr23ldgjvpz@sirena.org.uk>
Date:   Thu, 24 Nov 2016 10:19:36 +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 Thu, Nov 24, 2016 at 10:37:24AM +0530, Viresh Kumar wrote:
> On 23-11-16, 12:29, Mark Brown wrote:

> > No, of course not.  That would be completely incoherent, there would be
> > no way for anything to use the data if the values can just be in any
> > random order.

> With the current implementation in this patchset, the order in which entries are
> present in the OPP node is _assumed_ to be known to the platform specific code,
> which will pass it on to the OPP core with some callbacks. So the order will not
> be completely random.

What we're reviewing here is the DT binding and the DT binding
explicitly said the order doesn't matter.  The DT binding is OS neutral
so it needs to make sense without the code.

> > The "platform driver bindings" bit of this is very important here.  This
> > is a generic binding that is going to be used by platform specific
> > drivers (as I understand it).

> There is no platform specific binding here.

It seems like we're going to need one for this to be a comprehensible
binding.

> We can either get this information from DT (somehow) or hardcode it in platform
> specific code. This patch provided infrastructure for the later one.

> If we indeed want to get this information from the DT then there are two
> options:

Why would we want to get it from DT when we can't get half the other
information we need to make the data useful from DT?

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