[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b1a456f-b9e3-4722-84ba-ba4fdd4b2ece@huawei.com>
Date: Thu, 15 Jan 2026 20:09:02 +0800
From: "lihuisong (C)" <lihuisong@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: <lenb@...nel.org>, <linux-acpi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <Sudeep.Holla@....com>,
<linuxarm@...wei.com>, <jonathan.cameron@...wei.com>,
<zhanjie9@...ilicon.com>, <zhenglifeng1@...wei.com>, <yubowen8@...wei.com>,
<lihuisong@...wei.com>
Subject: Re: [PATCH 1/3] ACPI: processor: idle: Relocate and verify
acpi_processor_ffh_lpi_probe
Hi Rafael,
On 1/15/2026 1:27 AM, Rafael J. Wysocki wrote:
> On Tue, Nov 25, 2025 at 7:52 AM Huisong Li <lihuisong@...wei.com> wrote:
>> The platform used LPI need check if the LPI support and the entry
>> method is valid by the acpi_processor_ffh_lpi_probe(). But the return
>> of acpi_processor_ffh_lpi_probe() in acpi_processor_setup_cpuidle_dev()
>> isn't verified by any caller.
>>
>> What's more, acpi_processor_get_power_info() is a more logical place for
>> verifying the validity of FFH LPI than acpi_processor_setup_cpuidle_dev().
>> So move acpi_processor_ffh_lpi_probe() from the latter to the former and
>> verify its return.
>>
>> Signed-off-by: Huisong Li <lihuisong@...wei.com>
>> ---
>> drivers/acpi/processor_idle.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>> index 5f86297c8b23..cdf86874a87a 100644
>> --- a/drivers/acpi/processor_idle.c
>> +++ b/drivers/acpi/processor_idle.c
>> @@ -1252,7 +1252,7 @@ static int acpi_processor_setup_cpuidle_dev(struct acpi_processor *pr,
>>
>> dev->cpu = pr->id;
>> if (pr->flags.has_lpi)
>> - return acpi_processor_ffh_lpi_probe(pr->id);
>> + return 0;
>>
>> acpi_processor_setup_cpuidle_cx(pr, dev);
>> return 0;
>> @@ -1264,7 +1264,13 @@ static int acpi_processor_get_power_info(struct acpi_processor *pr)
>>
>> ret = acpi_processor_get_lpi_info(pr);
>> if (ret)
>> - ret = acpi_processor_get_cstate_info(pr);
>> + return acpi_processor_get_cstate_info(pr);
>> +
>> + if (pr->flags.has_lpi) {
>> + ret = acpi_processor_ffh_lpi_probe(pr->id);
>> + if (ret)
>> + pr_err("Processor FFH LPI state is invalid.\n");
>> + }
>>
>> return ret;
>> }
>> --
> Please reorder this behind the next patch in the series.
Patch 2/3 depends on this patch.
So I don't know how to reorder this patch.
>
Powered by blists - more mailing lists