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

Date:	Fri, 1 Apr 2016 18:22:14 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Mason <slash.tmp@...e.fr>
Cc:	Arnd Bergmann <arnd@...db.de>, linaro-kernel@...ts.linaro.org,
	k.kozlowski@...sung.com, kgene.kim@...sung.com, heiko@...ech.de,
	linux-pm@...r.kernel.org, mmcclint@...eaurora.org,
	xf@...k-chips.com, Rafael Wysocki <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org, rob.herring@...aro.org,
	Sebastian Frias <sebastian_frias@...madesigns.com>
Subject: Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device
 creation support

On 01-04-16, 14:30, Mason wrote:
> Hmmm... I'm using the older operating-points prop in my platform's DT.
> Why can't we define a new property (e.g. "enable-generic-cpufreq")
> which registers the "cpufreq-dt" pseudo-device?

DT is all about expressing hardware in a file. The same bindings
should be usable across any operating system, not just Linux. And so
we shouldn't have any OS or software-implementation specific
properties here.

> And platforms that manually register "cpufreq-dt" would be
> automatically white-listed, even if they don't have the new
> property, to maintain backward-compat?

Its not about just making it work, otherwise we would have done it
long time back by creating a DT node for cpufreq-dt driver.

> > @Rob: Will that be acceptable to you? We are discussing (again) about how to
> > probe cpufreq-dt driver automatically for platforms :)
> > 
> > The cpus node doesn't have any 'compatible' property today, and I will be
> > required to add that in this case.
> 
> Why does it need a compatible prop?

That compatible property will describe how to parse/describe
operating-points for a CPU. Any driver, which has the ability to parse
those bindings can do things base on such a compatibility string.

I hope you got the idea.

-- 
viresh