Re: [PATCH v1 5/9] cpuidle: teo: Clarify two code comments

[Christian Loehle <christian.loehle@arm.com>]

On 1/13/25 18:41, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Rewrite two code comments suposed to explain its behavior that are too

s/suposed/supposed

> concise or not sufficiently clear.
> 
> No functional impact.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/cpuidle/governors/teo.c |   16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -154,9 +154,10 @@
>  
>  	if (cpu_data->time_span_ns >= cpu_data->sleep_length_ns) {
>  		/*
> -		 * One of the safety nets has triggered or the wakeup was close
> -		 * enough to the closest timer event expected at the idle state
> -		 * selection time to be discarded.
> +		 * This causes the wakeup to be counted as a hit regardless of

regardless of twice.

> +		 * regardless of the real idle duration which doesn't need to be
> +		 * computed because the wakeup has been close enough to an
> +		 * anticipated timer.
>  		 */
>  		measured_ns = U64_MAX;
>  	} else {
> @@ -302,8 +303,13 @@
>  
>  	cpu_data->time_span_ns = local_clock();
>  	/*
> -	 * Set the expected sleep length to infinity in case of an early
> -	 * return.
> +	 * Set the sleep length to infitity in case the invocation of

s/infitity/infinity

> +	 * tick_nohz_get_sleep_length() below is skipped, in which case it won't
> +	 * be known whether or not the subsequent wakeup is caused by a timer.
> +	 * It is generally fine to count the wakeup as an intercept then, except
> +	 * for the cases when the CPU is mostly woken up by timers and there may
> +	 * be opportunities to ask for a deeper idle state when no imminent
> +	 * timers are scheduled which may be missed.

With the above typo fixes.
Reviewed-by: Christian Loehle <christian.loehle@arm.com>