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: <CAKohpomTt-ajNeh-OwV9X-HNBddJzL=JB+ggFY0msmsuZabvjA@mail.gmail.com>
Date:	Mon, 25 Mar 2013 14:15:46 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Sekhar Nori <nsekhar@...com>
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 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.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ