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]

Date:   Thu, 10 Nov 2016 09:41:50 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>, nm@...com,
        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, broonie@...nel.org
Subject: Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

On 09-11-16, 17:19, Stephen Boyd wrote:
> On 11/02, Viresh Kumar wrote:
> > On 26-10-16, 12:02, Viresh Kumar wrote:
> > > Hi,
> > > 
> > > Some platforms (like TI) have complex DVFS configuration for CPU
> > > devices, where multiple regulators are required to be configured to
> > > change DVFS state of the device. This was explained well by Nishanth
> > > earlier [1].
> > > 
> > > One of the major complaints around multiple regulators case was that the
> > > DT isn't responsible in any way to represent the ordering in which
> > > multiple supplies need to be programmed, before or after frequency
> > > change. It was considered in this patch and such information is left to
> > > the platform specific OPP driver now, which can register its own
> > > opp_set_rate() callback with the OPP core and the OPP core will then
> > > call it during DVFS.
> > > 
> > > The patches are tested on Exynos5250 (Dual A15). I have hacked around DT
> > > and code to pass values for multiple regulators and verified that they
> > > are all properly read by the kernel (using debugfs interface).
> > > 
> > > Dave Gerlach has already tested it on the real TI platforms and it works
> > > well for him.
> > > 
> > > This is rebased over: linux-next branch in the PM tree.
> > > 
> > > V2->V3:
> > > - The last patch is new
> > > - Removed a debug leftover pr_info() message
> > > - Renamed few names as s/set_rate/set_opp
> > > - Removed a TODO comment (as it is done now with this series)
> > > - created struct for min_uV and max_uV
> > > - kerneldoc comments for structures in pm_opp.h
> > > - s/const char */const char * const
> > > - use kasprintf()
> > > - Some more minor reformatting
> > > - More Ack/RBY tags added
> > 
> > @Stephen: Can you please provide further comments or Acks ?
> > 
> 
> Where did we end up on the topic of RCU usage in OPP? I'd rather
> we figure that out before investing more time in reviewing code
> that we may end up completely rewriting in the future.

We haven't decided anything on that yet and I don't think there is any reason to
block this series for that. There is lots of existing code that needs to be
updated if we decide to walk that path and I wouldn't mind a small addition to
that from this series.

Lots of effort Coding/testing/reviewing has already gone into this work and we
better get it merged now.

-- 
viresh