linux-kernel - Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2

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: <CAKohpokZXUzXKRWBje7QF_jrvOd5dmfmWQ2Csf3xiMuvT_vPYA@mail.gmail.com>
Date:	Thu, 17 Jul 2014 13:11:45 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Nishanth Menon <nm@...com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Simon Horman <horms@...ge.net.au>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Tomasz Figa <t.figa@...sung.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas P Abraham <thomas.ab@...sung.com>,
	Rob Herring <rob.herring@...aro.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Arvind Chauhan <arvind.chauhan@....com>,
	Sachin Kamat <spk.linux@...il.com>,
	Michal Simek <michal.simek@...inx.com>
Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2

On 17 July 2014 13:05, Thomas Petazzoni
<thomas.petazzoni@...e-electrons.com> wrote:
> Could you summarize what is the issue with the binding?
>
> At least for the case where we have one clock per CPU, the DT binding
> is really dead simple: each CPU node can carry a "clocks" property, and
> a "clock-latency" property. I really don't see why a long discussion is
> needed to agree on such a binding.
>
> Now, if the DT binding problem is related to those cases where you have
> siblings, i.e one clock controlling *some* of the CPUs, but not all
> CPUs or just one CPU, then maybe we could leave this aside for now,

Yeah, we are stuck on that for now.

> only support the following cases:
>
>  * One clock for all CPUs
>  * One clock for each CPU

Yeah, so I also proposed this yesterday that we stick to only these
two implementations for now. And was looking at how would the
cpufreq-generic driver come to know about this.

So, one way out now is to see if "clocks" property is defined in
multiple cpu nodes, if yes don't compare them and consider separate
clocks for each cpu. We don't have to try matching that to any other
node, as that's a very bad idea. Mike was already very upset with that :)

@Stephen/Rafael: Does that sound any better? Ofcourse the final thing
is to get bindings to figure out relations between CPUs..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/