linux-kernel - Re: [PATCH] cpufreq: scpi: invoke frequency-invariance setter function

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]

Date:   Thu, 22 Feb 2018 23:27:45 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH] cpufreq: scpi: invoke frequency-invariance setter function

On Tue, Feb 20, 2018 at 12:10 PM, Dietmar Eggemann
<dietmar.eggemann@....com> wrote:
> Commit 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency")
> changed the cpufreq driver on juno from arm_big_little to scpi.
>
> The scpi set_target function does not call the frequency-invariance
> setter function arch_set_freq_scale() like the arm_big_little set_target
> function does. As a result the task scheduler load and utilization
> signals are not frequency-invariant on this platform anymore.
>
> Fix this by adding a call to arch_set_freq_scale() into
> scpi_cpufreq_set_target().
>
> Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency")
> Cc: Rafael J. Wysocki <rjw@...ysocki.net>
> Cc: Viresh Kumar <viresh.kumar@...aro.org>
> Cc: Sudeep Holla <sudeep.holla@....com>
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@....com>
> Acked-by: Sudeep Holla <sudeep.holla@....com>

This is really minor, but I would reorder this slightly.

> ---
>  drivers/cpufreq/scpi-cpufreq.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
> index c32a833e1b00..3101d4e9c2de 100644
> --- a/drivers/cpufreq/scpi-cpufreq.c
> +++ b/drivers/cpufreq/scpi-cpufreq.c
> @@ -51,13 +51,19 @@ static unsigned int scpi_cpufreq_get_rate(unsigned int cpu)
>  static int
>  scpi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
>  {
> +       unsigned long freq = policy->freq_table[index].frequency;
>         struct scpi_data *priv = policy->driver_data;
> -       u64 rate = policy->freq_table[index].frequency * 1000;
> +       u64 rate = freq * 1000;
>         int ret;
>
>         ret = clk_set_rate(priv->clk, rate);
> -       if (!ret && (clk_get_rate(priv->clk) != rate))
> -               ret = -EIO;
> +       if (!ret) {

I would do:

if (ret)
        return ret;

arch_set_freq_scale(policy->related_cpus, freq, policy->cpuinfo.max_freq);

if (clk_get_rate(priv->clk) != rate)
        return -EIO;

return 0;

That's somewhat easier to follow for me.

> +               if (clk_get_rate(priv->clk) != rate)
> +                       ret = -EIO;
> +
> +               arch_set_freq_scale(policy->related_cpus, freq,
> +                                   policy->cpuinfo.max_freq);
> +       }
>
>         return ret;
>  }
> --

I also am not sure why you want to call arch_set_freq_scale() even if
the new clock rate didn't stick.