[PATCH] clk: sunxi: clean up rate counting
Andre Przywara
andre.przywara at arm.com
Thu Feb 20 17:37:21 PST 2025
On Mon, 3 Feb 2025 14:29:28 +0300
Anastasia Belova <abelova at 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 at 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;
More information about the linux-arm-kernel
mailing list