Re: [PATCH 1/2] clk: divider: Fix the divisor for rates above 4.29 GHz

[David Laight <david.laight.linux@gmail.com>]

On Wed, 04 Nov 2026 16:52:04 -0500
Brian Masney <masneyb@kernel.org> wrote:

> > DIV_ROUND_UP_ULL() takes a 32-bit divisor, so on 64-bit platforms a
> > requested rate above 4.29 GHz is truncated. A divider fed by a 5.94 GHz
> > PLL then computes a divisor of 7, not 1, for 5.94 GHz.
> > 
> > Use DIV64_U64_ROUND_UP(), which takes a 64-bit divisor.
> > 
> > Fixes: 9556f9dad8f5 ("clk: divider: handle integer overflow when dividing large clock rates")
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > Signed-off-by: Carlo Caione <ccaione@baylibre.com>  
> 
> Reviewed-by: Brian Masney <masneyb@kernel.org>
> 
> Since this is a core change to the framework, I'd also like to see what
> Jerome thinks before we merge this.

I've wondered about whether using 'unsigned long' for clock frequencies
was ever right.
Clearly the type should be the same size for 32 bit and 64 bit, and I'm
pretty sure the choice of long predates 64bit (I guess someone was worried
'int' might only be 16 bits?).

But if frequencies can be over 4GHz (which no one would have imagined a few
years back) they can be that high on 32 bit systems as well as 64bit ones.
So there is a big 'bag of worms' being opened.

Changing the type to 64 bits is hard to check (unless you manage to build
a kernel with the value embedded in a structure using accessor functions)
and will be a lot of bloat for most uses on 32 bit.
Alternatively you enforce a different api for clocks that might exceed 4GHz.

David

> 
> Brian
>