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: <2E69FE3D-5D1B-4952-959F-06603BA21D98@toblux.com>
Date: Wed, 31 Jul 2024 00:13:34 +0200
From: Thorsten Blum <thorsten.blum@...lux.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: abel.vesa@...aro.org,
 angelogioacchino.delregno@...labora.com,
 christophe.jaillet@...adoo.fr,
 dinguyen@...nel.org,
 erick.archer@....com,
 mturquette@...libre.com,
 robh@...nel.org,
 linux-clk@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: hisilicon: Remove unnecessary local variable

On 30. Jul 2024, at 01:23, Stephen Boyd <sboyd@...nel.org> wrote:
> Quoting Thorsten Blum (2024-07-10 13:18:45)
>> diff --git a/drivers/clk/hisilicon/clk-hi3559a.c b/drivers/clk/hisilicon/clk-hi3559a.c
>> index c79a94f6d9d2..30d5a6ba8fa5 100644
>> --- a/drivers/clk/hisilicon/clk-hi3559a.c
>> +++ b/drivers/clk/hisilicon/clk-hi3559a.c
>> @@ -407,7 +407,7 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
>>                unsigned long parent_rate)
>> {
>>        struct hi3559av100_clk_pll *clk = to_pll_clk(hw);
>> -       u64 frac_val, fbdiv_val, refdiv_val;
>> +       u64 frac_val, fbdiv_val;
>>        u32 postdiv1_val, postdiv2_val;
>>        u32 val;
> 
> I see 'val' is u32 here.
> 
>>        u64 tmp, rate;
>> @@ -435,13 +435,12 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
>>        val = readl_relaxed(clk->ctrl_reg2);
>>        val = val >> clk->refdiv_shift;
>>        val &= ((1 << clk->refdiv_width) - 1);
>> -       refdiv_val = val;
>> 
>>        /* rate = 24000000 * (fbdiv + frac / (1<<24) ) / refdiv  */
>>        rate = 0;
>>        tmp = 24000000 * fbdiv_val + (24000000 * frac_val) / (1 << 24);
>>        rate += tmp;
>> -       do_div(rate, refdiv_val);
>> +       do_div(rate, val);
> 
> So this can be div_u64() now?

Yes, it could be.

Is div_u64() preferred over do_div() when the remainder doesn't matter?

Thanks,
Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ