Re: [PATCH] clk: sunxi: clean up rate counting

[Andre Przywara <andre.przywara@arm.com>]

On Mon,  3 Feb 2025 14:29:28 +0300
Anastasia Belova <abelova@astralinux.ru> wrote:

Hi,

> If n = 255, the result of multiplication of n and 24000000
> may not fit int type. Swap division and shift with multiplication.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.

I guess this is effectively a v2 of this patch?
https://lore.kernel.org/linux-sunxi/20250120084719.63116-1-abelova@astralinux.ru/T/#u

In this case, and for the records, I'd like to repeat some comments of
mine from this former patch, about this being mostly irrelevant:
- PLL4 is PLL_PERIPH0, which is meant to be fixed to 960MHz. Linux
  would not change this frequency.
- the Allwinner A80 is both old and quite rare/obscure: the most
  prominent board (Cubieboard4) was broken for a while and nobody
  noticed
- this "allwinner,sun9i-a80-pll4-clk" clock is not used by any DT
  in the kernel, so it's effectively dead code

So do we really need this change? Or asked another way: What does this
patch fix, exactly?

Some comments still, regardless:

> Fixes: 6424e0aeebc4 ("clk: sunxi: rewrite sun9i_a80_get_pll4_factors()")
> Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
> ---
>  drivers/clk/sunxi/clk-sun9i-core.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sun9i-core.c b/drivers/clk/sunxi/clk-sun9i-core.c
> index d93c7a53c6c0..639c83ed63b8 100644
> --- a/drivers/clk/sunxi/clk-sun9i-core.c
> +++ b/drivers/clk/sunxi/clk-sun9i-core.c
> @@ -25,12 +25,12 @@
>  
>  static void sun9i_a80_get_pll4_factors(struct factors_request *req)
>  {
> -	int n;
> -	int m = 1;
> -	int p = 1;
> +	unsigned int n;
> +	unsigned int m = 1;
> +	unsigned int p = 1;
>  
>  	/* Normalize value to a 6 MHz multiple (24 MHz / 4) */
> -	n = DIV_ROUND_UP(req->rate, 6000000);
> +	n = DIV_ROUND_UP(req->rate, 6000000ul);

What would the "unsigned long" change here? This is 32-bit code, so int
and long are the same size. And regardless, how does changing the
divisor type help anyway?

>  
>  	/* If n is too large switch to steps of 12 MHz */
>  	if (n > 255) {
> @@ -50,7 +50,11 @@ static void sun9i_a80_get_pll4_factors(struct factors_request *req)
>  	else if (n < 12)
>  		n = 12;
>  
> -	req->rate = ((24000000 * n) >> p) / (m + 1);
> +	/* Division and shift should be done before multiplication to
> +	 * avoid overflow. The result will be correct because '>> p' and
> +	 * '/ (m + 1)' are both just conditional 'divide by 2'
> +	 */
> +	req->rate = ((24000000ul >> p) / (m + 1)) * n;

This looks OKish, since indeed the divisors are just 1 or 2, so we
don't lose any precision here. But again: what is "ul" supposed to fix?

Also the comment reads slightly wrong to me: Normally division
and shift _should_ be done *after* multiplication to avoid loss of
precision. The comment here should state that we _can_ do it the other
way around here, since the divisors are small and divide the dividend
"cleanly".

Cheers,
Andre


>  	req->n = n;
>  	req->m = m;
>  	req->p = p;