On 11/25/2013 09:03 PM, viresh kumar wrote:
On Tuesday 26 November 2013 07:31 AM, Paul Walmsley wrote:diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index d4585ce2346c..0faf756f6197 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -44,7 +44,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index) int ret; freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000); - if (freq_Hz < 0) + if (freq_Hz <= 0) freq_Hz = freq_table[index].frequency * 1000; freq_exact = freq_Hz;So, we will see another patch where you will do: s/<=/== ??
Probably so for this driver - along with converting the type of freq_Hz to be u64 or unsigned long. Not sure yet about all of the other drivers, since many of them are unlikely to see rates above (2^31)-1 Hz.
I am wondering if there is any other way we can get this solved, i.e. in a single patchset.
I'm trying to avoid sending up a large series that touches drivers all over the tree :-(
Otherwise, for both SPEAr and cpu0 patches: Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Thanks! But I was instead hoping you might queue them up for merging for v3.14? That should greatly reduce the risk of merge conflicts.
- Paul -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
