linux-kernel - Re: [PATCH v4 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]

Message-ID: <52AF3126.6090000@wwwdotorg.org>
Date:	Mon, 16 Dec 2013 09:58:14 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	bilhuang <bilhuang@...dia.com>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
	"thierry.reding@...il.com" <thierry.reding@...il.com>
CC:	"linux-kernel@...r.kernel.org" <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 v4 1/1] cpufreq: tegra: Re-model Tegra20 cpufreq driver

On 12/16/2013 03:52 AM, bilhuang wrote:
> On 12/14/2013 07:21 AM, Stephen Warren wrote:
>> On 12/12/2013 02:33 AM, Bill Huang wrote:
>>> Re-model Tegra20 cpufreq driver as below.
>>>
>>> * Rename tegra-cpufreq.c to tegra20-cpufreq.c since this file supports
>>>    only Tegra20.
>>> * Add probe function so defer probe can be used when we're going to
>>>    support DVFS.
>>> * Create a fake cpufreq platform device with its name being
>>>    "${root_compatible}-cpufreq" so SoC cpufreq driver can bind to it
>>>    accordingly.
>>
>>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>>
>>> +config ARM_TEGRA20_CPUFREQ
>>> +    bool "NVIDIA TEGRA20"
>>> +    depends on ARM_TEGRA_CPUFREQ && ARCH_TEGRA_2x_SOC
>>> +    default y
>>> +    help
>>> +      This enables Tegra20 cpufreq functionality, it adds
>>> +      Tegra20 CPU frequency ladder and the call back functions
>>> +      to set CPU rate. All the non-SoC dependant codes are
>>> +      controlled by the config ARM_TEGRA20_CPUFREQ.
>>
>> I think that last sentence is no longer true in this patch version. Or,
>> did you mean to write ARM_TEGRA_CPUFREQ rather than ARM_TEGRA20_CPUFREQ?
> 
> Right, should be ARM_TEGRA_CPUFREQ, thanks for catching this.
>>
>>> diff --git a/drivers/cpufreq/tegra-cpufreq.c
>>> b/drivers/cpufreq/tegra-cpufreq.c
>>
>>> +static const char * const tegra_soc_compat[] = {
>>> +    "nvidia,tegra124",
>>> +    "nvidia,tegra114",
>>> +    "nvidia,tegra30",
>>> +    "nvidia,tegra20",
>>> +    NULL
>>>   };
>>
>> That table will need editing for each chip. I wonder if you can do
>> something like always use the very last entry in /compatible. That would
>> assume a particular ordering of the compatible entries, but they should
>> be in the order $board, $soc anyway...
> 
> How do we get subset of a string and making sure it is the last? There
> must be some assumptions here (though they will possibly be true) I
> guess, for example, they should be in the order $board, $soc... and the
> last "nvidia" should be the start of the last compatible id we would
> like to get.

The compatible property is an array of strings, rather than one big
string, so you can just keep getting index 0, 1, 2, ... until you find
there aren't any more entries. I think it's reasonable to assume that
the SoC compatible value must be last, and it should be in practice,
although perhaps that is fragile. If you want, we can leave this as-is
for now, and modify it later if it becomes a problem.
--
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/