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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23dba70b-aa83-4a21-a33d-733bec215264@arm.com>
Date:   Mon, 26 Feb 2018 08:49:10 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
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 02/22/2018 11:27 PM, Rafael J. Wysocki wrote:
> On Tue, Feb 20, 2018 at 12:10 PM, Dietmar Eggemann
> <dietmar.eggemann@....com> wrote:

[...]

>> 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.

Tried to figure out what would be the better order. Not sure since I saw
different examples. Can you tell what would be the best tag order?

[...]

>> 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.

Yes I can change this.

> 
>> +               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.

Right, this is much better.

 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;
 
-       return ret;
+       if (ret)
+               return ret;
+
+       if (clk_get_rate(priv->clk) != rate)
+               return -EIO;
+
+       arch_set_freq_scale(policy->related_cpus, freq,
+                           policy->cpuinfo.max_freq);
+
+       return 0;

Will send out a v2 as soon as I know the preferred tag order.