linux-kernel - Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation 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]

Date:	Mon, 18 Apr 2016 23:00:46 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linaro-kernel@...ts.linaro.org
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Rob Herring <robherring2@...il.com>,
	Rob Herring <rob.herring@...aro.org>,
	Krzysztof Kozłowski <k.kozlowski@...sung.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Heiko Stübner <heiko@...ech.de>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Matthew McClintock <mmcclint@...eaurora.org>,
	xf@...k-chips.com, Rafael Wysocki <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mason <slash.tmp@...e.fr>
Subject: Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

On Thursday 07 April 2016 14:00:36 Viresh Kumar wrote:
> On 01-04-16, 09:15, Rob Herring wrote:
> > On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:

> > >
> > >
> > > And the cpufreq-dt driver can match /cpus node's compatible string against
> > > "operating-points-v2" and create a device at runtime ?
> > >
> > > @Rob: Will that be acceptable to you? We are discussing (again) about how to
> > > probe cpufreq-dt driver automatically for platforms 
> > 
> > No, I don't think that belongs in /cpus.
> > 
> > Part of the problem is this requires a DT change if you switch between
> > a platform-specific driver and generic driver.
> 
> Right.

How likely is that to happen for future platforms though?

I'd rather see a whitelist for the existing platforms (as started
by Viresh), because we don't know what other out-of-tree platforms 
use the "operating-points-v2" binding that are in fact not compatible
with today's driver.

If we add one way to identify machines that are known to follow
the binding to the degree necessary to make them work with the
Linux driver (whatever way that would be), then the only remaining
worry is about machines suddenly breaking because of a change in
the Linux driver, and we can work around that in the kernel if
necessary (or revert whatever broke the platform).

> > I don't understand the issue having a little bit of code to parse the
> > DT and create the device.
> 
> I am fine with that, we were just re-evaluating our options 
> 
> > If you are worried about having a long list
> > of platforms,
> 
> At least I am not.

The length of the list is not the issue here, it's the requirement
to edit the list for each new SoC that gets added. That causes conflicts
and constant churn.

> > you could instead check the tree for operating-points-v2
> > property in the cpu node and create the device unless the platform is
> > black-listed.
> 
> I don't really like the black-list idea much. It forces a Non
> cpufreq-dt platform to edit cpufreq-dt related file, just to make its
> own cpufreq driver work.
> 
> I find that ugly somehow 

Agreed.

Sorry for the late reply, I'm still catching up with email from two
weeks of travelling.

	Arnd