From: "lihuisong (C)" <lihuisong@huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: <lenb@kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <Sudeep.Holla@arm.com>,
<linuxarm@huawei.com>, <jonathan.cameron@huawei.com>,
<zhanjie9@hisilicon.com>, <zhenglifeng1@huawei.com>,
<yubowen8@huawei.com>
Subject: Re: [PATCH v2 4/7] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify
Date: Wed, 5 Nov 2025 17:06:56 +0800 [thread overview]
Message-ID: <aad95665-fb6a-477a-b419-4ad88c5db7d2@huawei.com> (raw)
In-Reply-To: <CAJZ5v0ii=ZJeCisXx3EOOMfqe8rRn=FvKBDsNuBucxvM0WXvgg@mail.gmail.com>
在 2025/11/5 0:19, Rafael J. Wysocki 写道:
> On Tue, Nov 4, 2025 at 10:54 AM lihuisong (C) <lihuisong@huawei.com> wrote:
>>
>> 在 2025/11/4 2:09, Rafael J. Wysocki 写道:
>>> On Mon, Nov 3, 2025 at 9:42 AM Huisong Li <lihuisong@huawei.com> wrote:
>>>> The old states may not be usable any more if get power information
>>>> failed in power notify. The ACPI idle should be disabled entirely.
>>> How does it actually disable anything? It only changes the
>>> acpi_processor_power_state_has_changed() return value AFAICS, but that
>>> return value isn't checked.
>> The acpi_processor_power_state_has_changed() will disable all cpuidle
>> device first.
>> AFAICS, the disabled cpuidle_device would not do cpuidle, please see
>> cpuidle_not_available() and cpuidle_idle_call().
>> It's enough for this?
> Well, not really.
>
> acpi_processor_register_idle_driver() has been changed to call
> acpi_processor_get_power_info() for each CPU before registering the
> idle driver and if that is successful, it will set
> flags.power_setup_done for the given processor and call
> acpi_processor_setup_cpuidle_states(). That processor need not be
> CPU0.
>
> However, the code updated by the $subject patch calls
> acpi_processor_get_power_info() for CPU0 and the patch would make it
> skip re-enabling cpuidle for all CPUs if it failed.
>
> It essentially needs to do what is done in
> acpi_processor_register_idle_driver(): find a CPU for which
> acpi_processor_get_power_info() does not fail, then call
> acpi_processor_setup_cpuidle_states() and re-enable cpuidle for all
> CPUs unless acpi_processor_get_power_info() fails for all of them.
From the initialization perspective, I also think this approach is
appropriate.
>
> But there is still a question of whether or not this addresses any
> breakage seen in the field. If not, maybe it's better to leave this
> code as is for the time being?
AFAICS, this power notify can be received on each CPU.
It may be appropriate to update cpuidle state of this CPU if ACPI idle
supports per-cpu idle state.
Now that all CPUs have the same idle state.
I think it is ok to keep here the same as the initialization logic as
you said above.
>
> I don't see why it is part of this series to be honest. It is not a cleanup.
Yes, now it's more like a bugfix.
>
next prev parent reply other threads:[~2025-11-05 9:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 8:42 [PATCH v2 0/7] ACPI: processor: idle: enhance and cleancode for cpuidle state Huisong Li
2025-11-03 8:42 ` [PATCH v2 1/7] ACPI: processor: idle: Mark the state as invalid if its entry method is illegal Huisong Li
2025-11-03 17:49 ` Rafael J. Wysocki
2025-11-04 9:30 ` lihuisong (C)
2025-11-04 15:00 ` Rafael J. Wysocki
2025-11-05 8:53 ` lihuisong (C)
2025-11-03 8:42 ` [PATCH v2 2/7] ACPI: processor: idle: Mark the state as invalid when get lpi_state->arch_flags failed Huisong Li
2025-11-03 17:53 ` Rafael J. Wysocki
2025-11-03 8:42 ` [PATCH v2 3/7] ACPI: processor: idle: Relocate and verify acpi_processor_ffh_lpi_probe Huisong Li
2025-11-03 17:56 ` Rafael J. Wysocki
2025-11-04 9:37 ` lihuisong (C)
2025-11-03 8:42 ` [PATCH v2 4/7] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify Huisong Li
2025-11-03 18:09 ` Rafael J. Wysocki
2025-11-04 9:54 ` lihuisong (C)
2025-11-04 16:19 ` Rafael J. Wysocki
2025-11-05 9:06 ` lihuisong (C) [this message]
2025-11-03 8:42 ` [PATCH v2 5/7] ACPI: processor: idle: Remove useless codes about the verification of cstate count Huisong Li
2025-11-03 18:10 ` Rafael J. Wysocki
2025-11-04 10:03 ` lihuisong (C)
2025-11-04 16:20 ` Rafael J. Wysocki
2025-11-03 8:42 ` [PATCH v2 6/7] ACPI: processor: idle: Redefine setup idle functions to void Huisong Li
2025-11-03 8:42 ` [PATCH v2 7/7] ACPI: processor: idle: Redefine acpi_processor_setup_cpuidle_dev " Huisong Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aad95665-fb6a-477a-b419-4ad88c5db7d2@huawei.com \
--to=lihuisong@huawei.com \
--cc=Sudeep.Holla@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=rafael@kernel.org \
--cc=yubowen8@huawei.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®