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

On 7/4/2026 2:52 AM, 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.

Hi Sasha,

> 
> Signed-off-by: Sasha Finkelstein <[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..6a0f1d36578f 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_policy *policy)
>   
>   	/* Get OPP levels (p-state indexes) and stash them in driver_data */
>   	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
> -		unsigned long rate = freq_table[i].frequency * 1000 + 999;
> +		unsigned long rate = freq_table[i].frequency * 1000UL + 999UL;

A couple of minor comments:

1. The `999UL` doesn't seem necessary, since the multiplication is
already carried out in `unsigned long` due to `1000UL`, and the
constant would be promoted automatically.

2. David's point about using `unsigned long` for frequencies is worth
considering. That said, the type here is effectively dictated by the
OPP API (`dev_pm_opp_find_freq_floor()` takes an `unsigned long *`),
and this driver already depends on 64BIT, so the proposed change seems
reasonable to me in practice.


>   		struct dev_pm_opp *opp = dev_pm_opp_find_freq_floor(cpu_dev, &rate);
>   
>   		if (IS_ERR(opp)) {
> 
> ---
> base-commit: 4a50a141f05a8d1737661b19ee22ff8455b94409
> change-id: 20260703-cpufreq-64-2a23d7261e09
> 
> Best regards,
> --
> Sasha Finkelstein <[email protected]>
> 
> 


-- 
Thx and BRs,
Zhongqiu Han