Re: [PATCH v2] cpufreq: apple-soc: Calculate frequency as a 64-bit value

"Joshua Peisach" <[email protected]> Mon, 20 Jul 2026 12:05:17 -0400
Newsgroups dev.linux.lists.asahi,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm
Message-ID <[email protected]>
On Mon Jul 20, 2026 at 3:25 AM EDT, Sasha Finkelstein wrote:
> The current frequency calculation is done in 32 bit, causing problems
> if run on a future SoC that can boost higher than 4.2GHz. Ideally, we
> should use a true u64 instead of unsigned long and "knowning" that this
> only runs on 64 bit machines, but the core code uses ulong everywhere,
> so this should be good enough.
>
> Signed-off-by: Sasha Finkelstein <[email protected]>
> ---
> Changes in v2:
> - Minor style fixes
> - Link to v1: https://patch.msgid.link/20260703-cpufreq-64-v1-1-c406c7053=
[email protected]
> ---
>  drivers/cpufreq/apple-soc-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-=
soc-cpufreq.c
> index 638e5bf72185..5ad274a1e6ae 100644
> --- a/drivers/cpufreq/apple-soc-cpufreq.c
> +++ b/drivers/cpufreq/apple-soc-cpufreq.c
> @@ -288,7 +288,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_poli=
cy *policy)
> =20
>  	/* Get OPP levels (p-state indexes) and stash them in driver_data */
>  	for (i =3D 0; freq_table[i].frequency !=3D CPUFREQ_TABLE_END; i++) {
> -		unsigned long rate =3D freq_table[i].frequency * 1000 + 999;
> +		unsigned long rate =3D freq_table[i].frequency * 1000UL + 999;
>  		struct dev_pm_opp *opp =3D dev_pm_opp_find_freq_floor(cpu_dev, &rate);
> =20
>  		if (IS_ERR(opp)) {
>
> ---
> base-commit: 4a50a141f05a8d1737661b19ee22ff8455b94409
> change-id: 20260703-cpufreq-64-2a23d7261e09
>
> Best regards,
> -- =20
> Sasha Finkelstein <[email protected]>

Reviewed-by: Joshua Peisach <[email protected]>