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]
Message-ID: <dd4a32fe-4942-83a8-a2c4-336e3c6e55b3@microchip.com>
Date:   Tue, 19 Mar 2019 08:28:40 +0000
From:   <Nicolas.Ferre@...rochip.com>
To:     <sboyd@...nel.org>, <linux-clk@...r.kernel.org>
CC:     <alexandre.belloni@...tlin.com>, <Ludovic.Desroches@...rochip.com>,
        <Claudiu.Beznea@...rochip.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <mturquette@...libre.com>,
        <matthias.wieloch@...-bauer.de>, <stable@...r.kernel.org>
Subject: Re: [PATCH v2] clk: at91: fix programmable clock for sama5d2

Stephen,

Thanks for the review

On 18/03/2019 at 20:54, Stephen Boyd wrote:
> Quoting Nicolas Ferre (2019-03-18 03:50:45)
>> From: Matthias Wieloch <matthias.wieloch@...-bauer.de>
>>
>> The prescaler formula of the programmable clock has changed for sama5d2. Update
>> the driver accordingly.
>>
>> Fixes: a2038077de9a ("clk: at91: add sama5d2 PMC driver")
>> Cc: <stable@...r.kernel.org> # v4.20+
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@...rochip.com>
>> [nicolas.ferre@...rochip.com: adapt the prescaler range,
>>                  fix clk_programmable_recalc_rate, split patch]
>> Signed-off-by: Matthias Wieloch <matthias.wieloch@...-bauer.de>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@...tlin.com>
>> ---
>> v2: adapt to v5.1-rc1
>>      remove unneeded sentence about DT in commit message
>>
>> Stephen,
>>
>> I think it would be good to see this fix going upstream during v5.1-rc phase.
> 
> Ok. I can apply this clk-fixes. I presume that things are real bad and
> it can't wait until v5.2?

To be perfectly clear, it's not a regression.
But as we're at the very beginning of the '-rc' phase and as it's a bug, 
I was thinking about adding it now. But you to choose, no problem either 
way.

>> @@ -60,10 +68,18 @@ static int clk_programmable_determine_rate(struct clk_hw *hw,
>>                          continue;
>>   
>>                  parent_rate = clk_hw_get_rate(parent);
>> -               for (shift = 0; shift < PROG_PRES_MASK; shift++) {
>> -                       tmp_rate = parent_rate >> shift;
>> -                       if (tmp_rate <= req->rate)
>> -                               break;
>> +               if (layout->is_pres_direct) {
>> +                       for (shift = 0; shift <= layout->pres_mask; shift++) {
>> +                               tmp_rate = parent_rate / (shift + 1);
>> +                               if (tmp_rate <= req->rate)
>> +                                       break;
>> +                       }
>> +               } else {
>> +                       for (shift = 0; shift < layout->pres_mask; shift++) {
>> +                               tmp_rate = parent_rate >> shift;
>> +                               if (tmp_rate <= req->rate)
>> +                                       break;
>> +                       }
> 
> This looks like a lot of copy paste when the if statement could have been
> pulled into the for loop instead of duplicating the loops and
> surrounding if condition check for tmp_rate.

Stop condition of loops not being the same made me separate them instead 
of adding artificial test conditions for shift == layout->pres_mask. I'm 
not sure the other way around is more obvious then...

> 
>>                  }
>>   
>>                  if (tmp_rate > req->rate)


-- 
Nicolas Ferre

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ