Re: [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states

[Sudeep Holla]

On Tue, Apr 21, 2026 at 02:51:42AM -0700, Breno Leitao wrote:
> On Mon, Apr 20, 2026 at 04:12:38PM +0100, Sudeep Holla wrote:
> > On Mon, Apr 20, 2026 at 02:27:13AM -0700, Breno Leitao wrote:
> > > -	count = pr->power.count - 1;
> > > -	if (count <= 0)
> > > -		return -ENODEV;
> > > -
> >
> > Does it make sense to retain this check like
> >   if (pr->power.count < 1)
> >   	return -EINVAL;
> >
> > Though I see the assignment to pr->power.count in drivers/acpi/processor_idle.c
> > is through unsigned int. So I am fine even without the above check.
> 
> I don't think the check is necessary. When count is 0 or 1, the loop
> for (i = 1; i < pr->power.count; i++) body won't execute, and the
> function will return 0.
>

Yes but the point is to handle invalid pr->power.count(0 or less) which
is not possible here though it is signed it because it is assigned from
an unsigned int during initialisation.

> This seems like the correct behavior — if there are no FFH PSCI states
> to validate, there's nothing that should fail.
> 

Agreed, but I was thinking of error in parsing _LPI being propogated here
but again that's not happening here.

> Additionally, returning -ENODEV would trigger the "Invalid FFH LPI data"
> error message, which would be misleading since the LPI data isn't
> invalid, it's just not present.
> 

The point was to throw that error if _LPI parsing fails.

> That said, please take this with a grain of salt since I'm not deeply
> familiar with _LPI states and their expected behavior.
> 

No worries, I agree the check I asked for is not needed.

-- 
Regards,
Sudeep