From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v5 1/1] cpufreq: tegra: Re-model Tegra20 cpufreq driver Date: Fri, 20 Dec 2013 09:29:51 -0700 Message-ID: <52B4707F.4040303@wwwdotorg.org> References: <1387451926-21373-1-git-send-email-bilhuang@nvidia.com> <52B41B18.30302@nvidia.com> <52B41F1B.3030005@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52B41F1B.3030005@nvidia.com> Sender: linux-pm-owner@vger.kernel.org To: bilhuang , Viresh Kumar Cc: "Rafael J. Wysocki" , Thierry Reding , Linux Kernel Mailing List , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-tegra@vger.kernel.org" List-Id: linux-tegra@vger.kernel.org On 12/20/2013 03:42 AM, bilhuang wrote: > On 12/20/2013 06:33 PM, Viresh Kumar wrote: >> On 20 December 2013 15:55, bilhuang wrote: >>> Don't you think it worth creating a file here so this can be shared to >>> arm64? >> >> We will see how to handle virtual devices when we will start getting >> arm64 SoCs. Probably we might end up writing a single file in cpufreq, >> if required, that will create virtual devices for every arm64 platform.. >> >> So, some people might use it and others wouldn't.. But no platform >> specific files for such stuff. So, the best we can do for now is to move >> these to platform code as we are talking about arm32 SoC's for now >> which do have a mach-* directory.. >> > OK thanks, this is suggested by Stephen earlier, I'll let him comment in > case he might think otherwise. 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.