* [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error
@ 2013-11-26 2:01 Paul Walmsley
2013-11-26 5:03 ` viresh kumar
0 siblings, 1 reply; 4+ messages in thread
From: Paul Walmsley @ 2013-11-26 2:01 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki
Cc: Mike Turquette, cpufreq, linux-pm, linux-kernel
Treat both negative and zero return values from clk_round_rate()
as errors. This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather
than a signed type, since some clock sources can generate rates
higher than (2^31)-1 Hz.
Eventually, when calling clk_round_rate(), only a return value of
zero will be considered a error. All other values will be
considered valid rates. The comparison against values less than
0 is kept to preserve the correct behavior in the meantime.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Mike Turquette <mturquette@linaro.org>
---
Applies on v3.13-rc1. See also:
http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
drivers/cpufreq/cpufreq-cpu0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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;
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error
2013-11-26 2:01 [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error Paul Walmsley
@ 2013-11-26 5:03 ` viresh kumar
2013-11-26 23:50 ` Paul Walmsley
0 siblings, 1 reply; 4+ messages in thread
From: viresh kumar @ 2013-11-26 5:03 UTC (permalink / raw)
To: Paul Walmsley, Rafael J. Wysocki
Cc: Mike Turquette, cpufreq, linux-pm, linux-kernel
On Tuesday 26 November 2013 07:31 AM, Paul Walmsley wrote:
>
> Treat both negative and zero return values from clk_round_rate()
> as errors. This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather
> than a signed type, since some clock sources can generate rates
> higher than (2^31)-1 Hz.
>
> Eventually, when calling clk_round_rate(), only a return value of
> zero will be considered a error. All other values will be
> considered valid rates. The comparison against values less than
> 0 is kept to preserve the correct behavior in the meantime.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
> Applies on v3.13-rc1. See also:
>
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
>
> drivers/cpufreq/cpufreq-cpu0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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/<=/== ??
I am wondering if there is any other way we can get this solved, i.e. in a
single patchset.
Otherwise, for both SPEAr and cpu0 patches:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error
2013-11-26 5:03 ` viresh kumar
@ 2013-11-26 23:50 ` Paul Walmsley
2013-11-27 1:28 ` Rafael J. Wysocki
0 siblings, 1 reply; 4+ messages in thread
From: Paul Walmsley @ 2013-11-26 23:50 UTC (permalink / raw)
To: viresh kumar
Cc: Rafael J. Wysocki, Mike Turquette, cpufreq, linux-pm, linux-kernel
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@linaro.org>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error
2013-11-26 23:50 ` Paul Walmsley
@ 2013-11-27 1:28 ` Rafael J. Wysocki
0 siblings, 0 replies; 4+ messages in thread
From: Rafael J. Wysocki @ 2013-11-27 1:28 UTC (permalink / raw)
To: Paul Walmsley
Cc: viresh kumar, Rafael J. Wysocki, Mike Turquette, cpufreq,
linux-pm, linux-kernel
On Tuesday, November 26, 2013 03:50:05 PM Paul Walmsley wrote:
> 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@linaro.org>
>
> 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.
I have a plan to queue them up for 3.14. :-)
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-11-27 1:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-26 2:01 [PATCH] cpufreq: cpufreq-cpu0: clk_round_rate() can return a zero upon error Paul Walmsley
2013-11-26 5:03 ` viresh kumar
2013-11-26 23:50 ` Paul Walmsley
2013-11-27 1:28 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).