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:	Thu, 2 Jan 2014 19:08:38 +0800
From:	bilhuang <bilhuang@...dia.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Rob Herring <robherring2@...il.com>,
	Grant Likely <grant.likely@...aro.org>
CC:	"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

On 12/23/2013 01:06 PM, Viresh Kumar wrote:
> 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.
Actually, I don't have plan or resource on doing this, would it be 
better that you help to do that instead? Thanks.
>
> I am not sure about the location of such file. Should this be placed in DT
> code somewhere or kept in cpufreq? Rob/Grant ??
>
Do we have consensus on where to create such file?
> --
> 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/