[PATCH v6] arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz

[Catalin Marinas]

On Wed, Sep 23, 2026 at 02:56:04PM +0200, Oleg Keri wrote:
> arch_freq_get_on_cpu() computes the product of the frequency scale and
> the reference frequency as a u64, but assigns it to an unsigned int
> before shifting it back down:
> 
> 	freq = scale * arch_scale_freq_ref(cpu);
> 	freq >>= SCHED_CAPACITY_SHIFT;
> 
> The product is truncated to 32 bits before the shift, so the result
> wraps once arch_scale_freq_ref() exceeds 2^32 / SCHED_CAPACITY_SCALE,
> i.e. 4194304 kHz.
> 
> On a Snapdragon X2 Elite (Glymur) laptop, whose boost OPP is 4723200
> kHz, cpuinfo_avg_freq reports 524283 kHz instead of ~4723200 kHz while
> the CPU demonstrably runs at the boost frequency: a fixed workload
> completes in 1.72 s at the 4723200 kHz OPP versus 2.01 s at 4032000
> kHz, matching the 1.171 frequency ratio.
> 
> Shift the u64 product and narrow only at the return.
> 
> Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
> Signed-off-by: Oleg Keri <okerixx at gmail.com>
> ---
> Changes in v6:
> - Drop the cap_scale() change. As a u64 static inline in a shared
>   header it would cost future 32-bit callers a 64-bit multiply that the
>   macro did not (Will); the truncation is the unsigned int temporary, so
>   drop that and leave kernel/sched untouched. Will's Ack on v5 not
>   carried since the arm64 hunk changed.
> - v5: https://lore.kernel.org/all/20260917182059.2851-1-okerixx@gmail.com/

I assume Dietmar and Will's acks still stand. I can add them from v5
(let me know if you disagree).

-- 
Catalin