cpuidle: warn and fixup on sanity check instead of rejecting the driver

[PATCH] cpuidle: warn and fixup on sanity check instead of rejecting the driver

Posted by Val Packett 1 week, 4 days ago

On Device Tree platforms, the latency and target residency values come
directly from device trees, which are numerous and weren't all written
with cpuidle invariants in mind. For example, qcom/hamoa.dtsi currently
trips this check: exit latency 680000 > residency 600000.

Instead of harshly rejecting the entire cpuidle driver with a mysterious
error message, print a warning and set the target residency value to be
equal to the exit latency.

Fixes: 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency")
Signed-off-by: Val Packett <val@packett.cool>
---
 drivers/cpuidle/driver.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 1c295a93d582..06aeb59c1017 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -199,8 +199,11 @@ static int __cpuidle_driver_init(struct cpuidle_driver *drv)
 		 * exceed its target residency which is assumed in cpuidle in
 		 * multiple places.
 		 */
-		if (s->exit_latency_ns > s->target_residency_ns)
-			return -EINVAL;
+		if (s->exit_latency_ns > s->target_residency_ns) {
+			pr_warn("cpuidle: state %d: exit latency %lld > residency %lld (fixing)\n",
+				i, s->exit_latency_ns, s->target_residency_ns);
+			s->target_residency_ns = s->exit_latency_ns;
+		}
 	}
 
 	return 0;
-- 
2.51.0

Re: [PATCH] cpuidle: warn and fixup on sanity check instead of rejecting the driver

Posted by Konrad Dybcio 1 week, 3 days ago

On 11/21/25 2:06 AM, Val Packett wrote:
> On Device Tree platforms, the latency and target residency values come
> directly from device trees, which are numerous and weren't all written
> with cpuidle invariants in mind. For example, qcom/hamoa.dtsi currently
> trips this check: exit latency 680000 > residency 600000.
> 
> Instead of harshly rejecting the entire cpuidle driver with a mysterious
> error message, print a warning and set the target residency value to be
> equal to the exit latency.
> 
> Fixes: 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency")
> Signed-off-by: Val Packett <val@packett.cool>
> ---

FWIW this is caused by:

--- hamoa.dtsi
cluster_c4: cpu-sleep-0 {
	compatible = "arm,idle-state";
	idle-state-name = "ret";
	arm,psci-suspend-param = <0x00000004>;
	entry-latency-us = <180>;
	exit-latency-us = <500>;
	min-residency-us = <600>;
};

which notably lacks 'wakeup-latency-us', which triggers this code path:

/*
 * If wakeup-latency-us is missing, default to entry+exit
 * latencies as defined in idle states bindings
 */
idle_state->exit_latency = entry_latency + exit_latency;

which fails this sanity check because 500+180=680 > 600

(which would have been good to note somewhere)


+Maulik can we fix up the numbers somehow?

Konrad

Re: [PATCH] cpuidle: warn and fixup on sanity check instead of rejecting the driver

Posted by Artem Bityutskiy 1 week, 3 days ago

On Thu, 2025-11-20 at 22:06 -0300, Val Packett wrote:
> On Device Tree platforms, the latency and target residency values come
> directly from device trees, which are numerous and weren't all written
> with cpuidle invariants in mind. For example, qcom/hamoa.dtsi currently
> trips this check: exit latency 680000 > residency 600000.
> 
> Instead of harshly rejecting the entire cpuidle driver with a mysterious
> error message, print a warning and set the target residency value to be
> equal to the exit latency.
> 
> Fixes: 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency")
> Signed-off-by: Val Packett <val@packett.cool>
> ---
>  drivers/cpuidle/driver.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 1c295a93d582..06aeb59c1017 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -199,8 +199,11 @@ static int __cpuidle_driver_init(struct cpuidle_driver *drv)
>  		 * exceed its target residency which is assumed in cpuidle in
>  		 * multiple places.
>  		 */
> -		if (s->exit_latency_ns > s->target_residency_ns)
> -			return -EINVAL;
> +		if (s->exit_latency_ns > s->target_residency_ns) {
> +			pr_warn("cpuidle: state %d: exit latency %lld > residency %lld (fixing)\n",
> +				i, s->exit_latency_ns, s->target_residency_ns);
> +			s->target_residency_ns = s->exit_latency_ns;
> +		}
>  	}

Ideally, in a perfect world, driver.c should verify input data and
reject bad input, rather than correct bad input.

So ideally, if there is an idle driver between DT and driver.c (like
intel_idle.c in case of Intel), that would be its job to correct DT
data.

But I'm not familiar with DT platforms, so I don't know if there is a
driver/piece of SW between DT parsing and driver.c that could handle
this correction at an earlier stage.

The reason I think this patch is not ideal is because it changes the
input data at the core framework level, and in theory the change may be
surprising to users. In general, sometimes rejecting bluntly is better
than correcting in a possibly unexpected way.

Artem.

Re: [PATCH] cpuidle: warn and fixup on sanity check instead of rejecting the driver

Posted by Rafael J. Wysocki 1 week, 3 days ago

On Fri, Nov 21, 2025 at 2:16 PM Artem Bityutskiy
<artem.bityutskiy@linux.intel.com> wrote:
>
> On Thu, 2025-11-20 at 22:06 -0300, Val Packett wrote:
> > On Device Tree platforms, the latency and target residency values come
> > directly from device trees, which are numerous and weren't all written
> > with cpuidle invariants in mind. For example, qcom/hamoa.dtsi currently
> > trips this check: exit latency 680000 > residency 600000.
> >
> > Instead of harshly rejecting the entire cpuidle driver with a mysterious
> > error message, print a warning and set the target residency value to be
> > equal to the exit latency.
> >
> > Fixes: 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency")
> > Signed-off-by: Val Packett <val@packett.cool>
> > ---
> >  drivers/cpuidle/driver.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> > index 1c295a93d582..06aeb59c1017 100644
> > --- a/drivers/cpuidle/driver.c
> > +++ b/drivers/cpuidle/driver.c
> > @@ -199,8 +199,11 @@ static int __cpuidle_driver_init(struct cpuidle_driver *drv)
> >                * exceed its target residency which is assumed in cpuidle in
> >                * multiple places.
> >                */
> > -             if (s->exit_latency_ns > s->target_residency_ns)
> > -                     return -EINVAL;
> > +             if (s->exit_latency_ns > s->target_residency_ns) {
> > +                     pr_warn("cpuidle: state %d: exit latency %lld > residency %lld (fixing)\n",
> > +                             i, s->exit_latency_ns, s->target_residency_ns);
> > +                     s->target_residency_ns = s->exit_latency_ns;
> > +             }
> >       }
>
> Ideally, in a perfect world, driver.c should verify input data and
> reject bad input, rather than correct bad input.
>
> So ideally, if there is an idle driver between DT and driver.c (like
> intel_idle.c in case of Intel), that would be its job to correct DT
> data.
>
> But I'm not familiar with DT platforms, so I don't know if there is a
> driver/piece of SW between DT parsing and driver.c that could handle
> this correction at an earlier stage.
>
> The reason I think this patch is not ideal is because it changes the
> input data at the core framework level, and in theory the change may be
> surprising to users. In general, sometimes rejecting bluntly is better
> than correcting in a possibly unexpected way.

Unless rejecting it causes the functionality to be missing entirely
and users have no straightforward way to fix it up.

As I said in my reply, what can be done in this situation is to print
a warning when assumptions are not met.

Re: [PATCH] cpuidle: warn and fixup on sanity check instead of rejecting the driver

Posted by Rafael J. Wysocki 1 week, 3 days ago

On Fri, Nov 21, 2025 at 2:08 AM Val Packett <val@packett.cool> wrote:
>
> On Device Tree platforms, the latency and target residency values come
> directly from device trees, which are numerous and weren't all written
> with cpuidle invariants in mind. For example, qcom/hamoa.dtsi currently
> trips this check: exit latency 680000 > residency 600000.

So this breaks cpuidle expectations and it doesn't work correctly on
the affected platforms.

> Instead of harshly rejecting the entire cpuidle driver with a mysterious
> error message, print a warning and set the target residency value to be
> equal to the exit latency.

This generally doesn't work because the new target residency may be
greater than the target residency of the next state.

> Fixes: 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency")
> Signed-off-by: Val Packett <val@packett.cool>
> ---
>  drivers/cpuidle/driver.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 1c295a93d582..06aeb59c1017 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -199,8 +199,11 @@ static int __cpuidle_driver_init(struct cpuidle_driver *drv)
>                  * exceed its target residency which is assumed in cpuidle in
>                  * multiple places.
>                  */
> -               if (s->exit_latency_ns > s->target_residency_ns)
> -                       return -EINVAL;
> +               if (s->exit_latency_ns > s->target_residency_ns) {
> +                       pr_warn("cpuidle: state %d: exit latency %lld > residency %lld (fixing)\n",
> +                               i, s->exit_latency_ns, s->target_residency_ns);
> +                       s->target_residency_ns = s->exit_latency_ns;

And you also need to update s->target_residency.

Moreover, that needs to be done when all of the target residency and
exit latency values have been computed and full sanitization of all
the states would need to be done (including the ordering checks), but
the kernel has insufficient information to do that (for instance, if
the ordering is not as expected, it is not clear how to fix it up).
Even the above sanitization is unlikely to result in the intended
behavior.

So if returning the error code doesn't work, printing a warning is as
much as can be done, like in the attached patch.

If this works for you, I'll submit it properly later.

> +               }
>         }
>
>         return 0;
> --