linux-kernel - Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy-> members

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: <51501BD5.2070807@ti.com>
Date:	Mon, 25 Mar 2013 15:11:41 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	<rjw@...k.pl>, <arvind.chauhan@....com>, <robin.randhawa@....com>,
	<Steve.Bannister@....com>, <Liviu.Dudau@....com>,
	<charles.garcia-tobin@....com>, <cpufreq@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linaro-kernel@...ts.linaro.org>,
	Sascha Hauer <kernel@...gutronix.de>,
	Paul Mundt <lethal@...ux-sh.org>, <linux-sh@...r.kernel.org>,
	<linux-omap@...r.kernel.org>
Subject: Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments
 of policy-> members

On 3/25/2013 2:15 PM, Viresh Kumar wrote:
> On 25 March 2013 14:06, Sekhar Nori <nsekhar@...com> wrote:
>> There is a line in the code a little above the ones you deleted that
>> also sets these same variables. I guess you were relying on that line to
>> set policy->cur, but that also sets policy->{min, max} which can be
>> cleaned up.
> 
> This code is rather confusing or wrong, this was the state of code before
> this patch:
> 
> 	policy->cur = policy->min = policy->max = davinci_getspeed(0);
> 
> 	if (freq_table) {
> 		result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
> 		if (!result)
> 			cpufreq_frequency_table_get_attr(freq_table,
> 							policy->cpu);
> 	} else {
> 		policy->cpuinfo.min_freq = policy->min;
> 		policy->cpuinfo.max_freq = policy->max;
> 	}
> 
>         policy->min = policy->cpuinfo.min_freq;
>         policy->max = policy->cpuinfo.max_freq;
>         policy->cur = davinci_getspeed(0);
> 
> 
> The tricky part is if/else, where if don't return error if
> cpufreq_frequency_table_cpuinfo() fails. We want to set ->min[max]
> and cpuinfo.min[max] always. And i can see this code not doing that for some
> case even with my patch.
> 
> Possible scenarios:
> 1. Valid freq_table: My patch + what you suggested is required.
> 2. Invalid freq_table: We never set cpuinfo.min[max] with or without my patch
> 3. No freq_table: Only my patch is required.
> 
> If i do what you suggested then 2 and 3 would fail... If you want to
> return error
> in case cpufreq_frequency_table_cpuinfo(), then i can fix it properly.

So down in the cpufreq driver probe below, we bail out if freq_table is
not provided. So all this checking for freq_table in the code you pasted
above is superfluous. If you can clean that part up and add checking for
cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to
test it out ;)

Thanks,
Sekhar
--
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/