linux-kernel - Re: [PATCH v5 1/1] cpufreq: tegra: Re-model Tegra20 cpufreq driver

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:	Mon, 23 Dec 2013 10:36:49 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>,
	Rob Herring <robherring2@...il.com>,
	Grant Likely <grant.likely@...aro.org>
Cc:	bilhuang <bilhuang@...dia.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thierry Reding <thierry.reding@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v5 1/1] cpufreq: tegra: Re-model Tegra20 cpufreq driver

Ccc'ing Grant and Rob as well.

On 20 December 2013 21:59, Stephen Warren <swarren@...dotorg.org> wrote:
> No, I definitely don't agree here. The rules for arch/arm64 are: no
> platform-specific code. We should immediately start planning for that.
> If this means renaming the file that creates the virtual device from
> tegra-cpufreq.c to something else, so be it, but we shouldn't go
> backwards and push stuff into the arch directories.

I don't mind doing this now as well if it is generic enough. I wasn't sure
if you guys wanted to take it on now..

@Bill: So, please create a separate commit for creating such file which
would create a virtual device for probing cpufreq drivers with name picked
from root-node. Compilation of such a file should be configurable but if
it is compiled, then it shouldn't cause any problems if that device isn't
used, for multiplatform kernels specially..

Probably then you can widen the scope of your patchset by modifying
some of the existing drivers which require a device to get cpufreq
driver probed. Currently they are all making such a device from
their arch/ stuff.

I am not sure about the location of such file. Should this be placed in DT
code somewhere or kept in cpufreq? Rob/Grant ??

--
viresh
--
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/