linux-kernel - Re: [PATCH V1 resend] cpufreq: Raname index as data in cpufreq_frequency

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: <CAKohponZaka9MCfnHAq602oQ42+SR7D1oM6ggODHAzQy==Y4WQ@mail.gmail.com>
Date:	Wed, 15 May 2013 11:55:36 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	rjw@...k.pl, linaro-kernel@...ts.linaro.org, patches@...aro.org,
	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, robin.randhawa@....com,
	Steve.Bannister@....com, Liviu.Dudau@....com,
	charles.garcia-tobin@....com, arvind.chauhan@....com,
	Sekhar Nori <nsekhar@...com>, Ben Dooks <ben-linux@...ff.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Simon Horman <horms@...ge.net.au>,
	Magnus Damm <magnus.damm@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Arnd Bergmann <arnd@...db.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Olof Johansson <olof@...om.net>,
	Srinidhi Kasagar <srinidhi.kasagar@...ricsson.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH V1 resend] cpufreq: Raname index as data in cpufreq_frequency_table

On 14 May 2013 21:45, Stephen Warren <swarren@...dotorg.org> wrote:
> On 05/14/2013 07:46 AM, Viresh Kumar wrote:
> ...
>> This must address your concerns:
>> @Rafael: I have attached both patches now for you to apply.
>>
>> From: Viresh Kumar <viresh.kumar@...aro.org>
>> Date: Tue, 14 May 2013 19:08:50 +0530
>> Subject: [PATCH 1/2] cpufreq: tegra: Remove irrelevant comment
>>
>> Tegra cpufreq driver doesn't use .index field of cpufreq_frequency_table and so
>> comment mentioning order of .index is irrelevant. Remove it.
>
>> diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
>
>> -/* Frequency table index must be sequential starting at 0 */
>>  static struct cpufreq_frequency_table freq_table[] = {
>>       { 0, 216000 },
>>       { 1, 312000 },
>
> Does the .index/.data field even need to be filled in any more?

No. But i didn't wanted to write following code: { .frequency = *** }, as
earlier one was fine too.

Ack whichever version you want (Attached too):

-----------x-----------------x-----------------

From: Viresh Kumar <viresh.kumar@...aro.org>
Date: Tue, 14 May 2013 19:08:50 +0530
Subject: [PATCH] cpufreq: tegra: Don't initialize .index field of
 cpufreq_frequency_table

Tegra cpufreq driver doesn't use .index field of cpufreq_frequency_table and so
we don't need to initialize it. Don't initialize it.

Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 drivers/cpufreq/tegra-cpufreq.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index c74c0e1..81561be 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -28,17 +28,16 @@
 #include <linux/io.h>
 #include <linux/suspend.h>

-/* Frequency table index must be sequential starting at 0 */
 static struct cpufreq_frequency_table freq_table[] = {
-	{ 0, 216000 },
-	{ 1, 312000 },
-	{ 2, 456000 },
-	{ 3, 608000 },
-	{ 4, 760000 },
-	{ 5, 816000 },
-	{ 6, 912000 },
-	{ 7, 1000000 },
-	{ 8, CPUFREQ_TABLE_END },
+	{ .frequency = 216000 },
+	{ .frequency = 312000 },
+	{ .frequency = 456000 },
+	{ .frequency = 608000 },
+	{ .frequency = 760000 },
+	{ .frequency = 816000 },
+	{ .frequency = 912000 },
+	{ .frequency = 1000000 },
+	{ .frequency = CPUFREQ_TABLE_END },
 };

 #define NUM_CPUS	2

Download attachment "0001-cpufreq-tegra-Don-t-initialize-.index-field-of-cpufr.patch" of type "application/octet-stream" (1491 bytes)