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  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:	Fri, 25 Jul 2014 09:29:09 -0500
From:	Rob Herring <>
To:	Viresh Kumar <>
Cc:	"Rafael J. Wysocki" <>,
	Stephen Boyd <>,
	Rob Herring <>,
	Mike Turquette <>,
	Thomas Petazzoni <>,
	Nishanth Menon <>,
	Lists linaro-kernel <>,
	"" <>,
	"" <>,
	Tomasz Figa <>,
	Linux Kernel Mailing List <>,
	Michal Simek <>,
	"" <>,
	Simon Horman <>,
	Thomas P Abraham <>,
	Kukjin Kim <>,
	Arvind Chauhan <>,
	Sachin Kamat <>
Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2

On Thu, Jul 24, 2014 at 5:48 AM, Viresh Kumar <> wrote:
> On 18 July 2014 09:47, Viresh Kumar <> wrote:
>>> Before I apply anything in this area, I need a clear statement from the ARM
>>> people as a group on what the approach is going to be.
> @Rafael: The only patch which has blocked this set is:
> cpufreq: cpu0: Extend support beyond CPU0
> This is about finding which CPUs share clock line..
> Other patches are sort of independent of this one and cpufreq-cpu0 would
> continue to work for existing platforms if we apply these patches.
> I was wondering if you would like to apply other patches leaving this one?
> I will then rebase stuff again and send non-controversial patches for 3.17.
> So, that we get something in 3.17 and the last change can be merged during
> rc's as well once we finalize on bindings..
>> Mike/Rob/Stephen: I believe Atleast three of you should express your views
>> now :)
> Any idea on how can we get some temporary solution for 3.17 as we didn't
> conclude anything yet on bindings ?

A temporary solution would have to be NOT in DT because once you add
something into DT you are stuck with it for some time. You could
simply support independent clocks by looking at the platform type, but
that is still risky since you may want to define the OPP in DT
differently for the 2 cases.

The other problem with temporary solutions is once they are accepted,
people loose motivation to create the permanent solution. "Can you
take this now and I'll fix the issues later" is a red flag to

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists