[PATCH RFC] ACPI: processor: idle: Do not propagate acpi_processor_ffh_lpi_probe() -ENODEV

[Sudeep Holla]

On Tue, Apr 14, 2026 at 09:31:33AM -0700, Breno Leitao wrote:
> Hello Sudeep,
> 
> On Tue, Apr 14, 2026 at 03:10:03PM +0100, Sudeep Holla wrote:
> > On Tue, Apr 14, 2026 at 06:14:19AM -0700, Breno Leitao wrote:
> > > Hello Sudeep,
> > >
> > > On Tue, Apr 14, 2026 at 01:25:53PM +0100, Sudeep Holla wrote:
> > > > So while I understand that the kernel did not report an error previously, that
> > > > does not mean the _LPI table is merely moot on this platform when it contains
> > > > only a WFI state.
> > >
> > > Can you clarify whether datacenter ARM systems are expected to expose
> > > deeper idle states beyond WFI in their _LPI tables?
> > >
> >
> > Of course any system that prefers to save power when its idling must have
> > these _LPI deeper idle states.
> >
> > > Backing up, I'm observing 72 pr_err() messages during boot on these
> > > hosts and trying to determine whether this indicates a firmware issue or
> > > if the kernel needs adjustment.
> >
> > I consider this a firmware issue, but not a fatal one. What matters more is
> > the behavior after those errors are reported.
> 
> I understand. While I'm not a hardware or firmware vendor myself, I can
> see how they might consider power management features _optional_ for certain
> server configurations.
> 
> > If you force success, either through your change or through the PSCI approach
> > suggested by lihuisong, then in practice you are only enabling a cpuidle
> > driver with a single usable state: WFI. That is not inherently wrong, but it
> > also does not provide much benefit.
> 
> Given that this isn't a critical error, would it make sense to downgrade
> the pr_err() to pr_debug()? is it a reasonable compromise. I just want
> to avoid these pr_err() all accross the board, affecting kernel health
> metrics in large fleets.
> 
> My proposal:
> 
> commit c98007f9e10fe229672d29c3844c96705cecaed5
> Author: Breno Leitao <leitao at debian.org>
> Date:   Tue Apr 14 05:28:28 2026 -0700
> 
>     ACPI: processor: idle: Downgrade FFH LPI probe failure message to pr_debug()
>     
>     The "Invalid FFH LPI data" message is printed at pr_err() level for every
>     CPU when acpi_processor_ffh_lpi_probe() fails. On platforms where the FFH
>     probe legitimately returns an error (e.g., no deep idle states beyond
>     WFI), this floods the kernel log with per-CPU error messages that are not
>     actionable.
>     
>     Downgrade to pr_debug() since this is a diagnostic message, not a
>     critical error.
>     
>     Signed-off-by: Breno Leitao <leitao at debian.org>
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index ee5facccbe10c..ab93a2c10a9ad 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1259,7 +1259,7 @@ static int acpi_processor_get_power_info(struct acpi_processor *pr)
>  	if (pr->flags.has_lpi) {
>  		ret = acpi_processor_ffh_lpi_probe(pr->id);
>  		if (ret)
> -			pr_err("CPU%u: Invalid FFH LPI data\n", pr->id);
> +			pr_debug("CPU%u: Invalid FFH LPI data\n", pr->id);

I am afraid if this might mask the real _LPI table entry errors.
Need to think, I am still of the opinion that we need warn on that system
as _LPI with just WFI is simply useless.

-- 
Regards,
Sudeep