Re: [PATCH v1] cpuidle: Warn instead of bailing out if target residency check fails

[Val Packett]

On 11/25/25 1:23 PM, Rafael J. Wysocki wrote:
> On Friday, November 21, 2025 2:10:57 PM CET Rafael J. Wysocki wrote:
> > On Fri, Nov 21, 2025 at 2:08 AM Val Packett <val@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > ---
> > >   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.
> No response, so I assume no objections. [..]

Right, only printing a warning is fine of course.

~val