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

Andre Przywara
2025-02-21T01:39:29Z

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;