Re: [PATCH v12 03/15] arm64/delay: move some constants out to a separate header

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer overflow in RPMH_USECS_TO_CYCLES causing premature wakeup from cpuidle for sleep durations > 223 seconds.
--

commit 9dcd4c7ce0611e9eee2b5361157ecadfee51f77d
Author: Ankur Arora <ankur.a.arora@oracle.com>

arm64/delay: move some constants out to a separate header

Moves some constants and functions related to xloops, cycles computation
out to a new header. Also make __delay_cycles() available outside of
arch/arm64/lib/delay.c.

> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index c6f7d5c9c493d..ad5ec5c0de0a3 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -146,10 +146,10 @@ enum {
>   *  +---------------------------------------------------+
>   */
>  
> -#define USECS_TO_CYCLES(time_usecs)			\
> -	xloops_to_cycles((time_usecs) * 0x10C7UL)
> +#define RPMH_USECS_TO_CYCLES(time_usecs)		\
> +	rpmh_xloops_to_cycles((time_usecs) * 0x10C7UL)
>  
> -static inline unsigned long xloops_to_cycles(u64 xloops)
> +static inline unsigned long rpmh_xloops_to_cycles(u64 xloops)
>  {
>  	return (xloops * loops_per_jiffy * HZ) >> 32;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but does the multiplication
in rpmh_xloops_to_cycles() overflow for large sleep durations?

On Qualcomm ARM64 SoCs, loops_per_jiffy * HZ evaluates to the arch timer
rate, typically 19.2 MHz. The intermediate 64-bit multiplication will
overflow the 64-bit boundary if wakeup_us exceeds approximately 223
seconds.

[ ... ]

> @@ -819,7 +819,7 @@ void rpmh_rsc_write_next_wakeup(struct rsc_drv *drv)
>  	wakeup_us = ktime_to_us(wakeup);
>  
>  	/* Convert the wakeup to arch timer scale */
> -	wakeup_cycles = USECS_TO_CYCLES(wakeup_us);
> +	wakeup_cycles = RPMH_USECS_TO_CYCLES(wakeup_us);
>  	wakeup_cycles += arch_timer_read_counter();

[Severity: High]
This is a pre-existing issue, but what happens in rpmh_rsc_write_next_wakeup()
when there are no pending timers?

If dev_pm_genpd_get_next_hrtimer() returns a maximum timeout value,
wakeup_us would severely overflow the 64-bit bounds in RPMH_USECS_TO_CYCLES()
multiple times.

Could this overflow cause the macro to return a wrapped, drastically
smaller cycle count, which is then added to arch_timer_read_counter()
and written to the RSC timer registers, causing the SoC to wake up
prematurely from cpuidle instead of remaining in deep sleep?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608080440.127491-1-ankur.a.arora@oracle.com?part=3