On Friday, February 14, 2014 04:30:40 PM Viresh Kumar wrote:
> cpufreq_update_policy() calls cpufreq_driver->get() to get current frequency
> of
> a CPU and it is not supposed to fail or return zero. Return error in case that
> happens.
>
> Signed-off-by: Viresh Kumar <[email protected]>
> ---
> Pierre,
>
> I don't think this will fix the issue you were facing but might supress it
> :)..
> And so you need to understand what causes your ->get() to return zero.
>
> @Rafael: I got to these patches while looking at code recently after Pierre
> complained about. Came to this conclusion after having discussions with
> Srivatsa
> over IRC..
Good to know that you chat with each other, but it really is not a useful piece
of information until you say what *exactly* you were talking about.
> drivers/cpufreq/cpufreq.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 08ca8c9..383362b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2151,6 +2151,13 @@ int cpufreq_update_policy(unsigned int cpu)
> */
> if (cpufreq_driver->get) {
> new_policy.cur = cpufreq_driver->get(cpu);
> +
> + if (!new_policy.cur) {
> + pr_err("%s: ->get() returned 0 KHz\n", __func__);
> + ret = -EINVAL;
That isn't -EINVAL. It may be -EIO or -ENODEV, but not -EINVAL. Please.
> + goto no_policy;
And is it unsafe to continue here? Or can we continue regardless of getting 0?
> + }
> +
> if (!policy->cur) {
> pr_debug("Driver did not initialize current freq");
> policy->cur = new_policy.cur;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
