Re: [PATCH 1/3] cpuidle: Add enable_cpuidle() interface

[lihuisong (C)]

On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@xxxxxxxxxx> wrote:
> > On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> > > On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) <lihuisong@xxxxxxxxxx> wrote:
> > > > Hi Rafael,
> > > >
> > > > On 1/30/2026 9:59 AM, lihuisong (C) wrote:
> > > > > Hi Rafael,
> > > > >
> > > > > On 1/15/2026 8:18 PM, lihuisong (C) wrote:
> > > > > > On 1/15/2026 3:18 AM, Rafael J. Wysocki wrote:
> > > > > > > On Tue, Nov 25, 2025 at 8:29 AM Huisong Li <lihuisong@xxxxxxxxxx>
> > > > > > > wrote:
> > > > > > > > The global switch of cpuidle can be turned back on in some case.
> > > > > > > > So add enable_cpuidle().
> > > > > > > No, this is not going to work.  The "off" switch only affects
> > > > > > > initialization AFAICS.
> > > > > > I think it would be work.
> > > > > > The cpuidle_not_available() also see the "off" on do_idle().
> > > > > > And cpuidle_idle_call() check this function first and then select
> > > > > > idle state.
> > > > > > Cpuidle doesn't select and enter idle state if this fuction return true.
> > > > > I verified that disable_cpuidle() effectively prevents all CPUs from
> > > > > entering any idle states and the cpuidle function is correctly
> > > > > restored after calling enable_cpuidle().
> > > > > What do you think?
> > > > Could you pleasetake a look atmy reply?
> > > > If not ok, I will drop this from my upstream list.
> > > Sorry, can you please remind me what problem you wanted to address
> > > with the help of this?
> > Regarding the discussion in the link[1], if driver fail to get power
> > info in power notify,
> > the old idle states may no longer be reliable. Therefore, patch 2/3
> > disables ACPI idle
> > via the new interface introduced in patch 1/3.
> >
> > However, our discussion on whether this new interface can disable ACPI
> > idle has not yet reached a conclusion.
> > Could you please revisit this thread? It's quite brief, and I'd
> > appreciate your further input.
> >
> > [1]
> > https://lore.kernel.org/all/20251103084244.2654432-1-lihuisong@xxxxxxxxxx
> The "off" variable has been intended for disabling cpuidle via kernel
> command line (note that the corresponding module param is read-only).
>
> disable_cpuidle() is only used by Xen now and only at the setup/init stage.
>
> I don't think that using it on idle state list change notifications is
> a good idea.

Understand.

> Something like cpuidle_pause_and_lock() would be a better match I
> think.  acpi_processor_hotplug() uses it already for a similar
> purpose.

Interfaces like cpuidle_pause_and_lock() and cpuidle_pause() disable cpuidle by clearing the global "initialized" flag,
which requires "enabled_devices" to be non-zero.
IIUC, cpuidle_disable_device() isn't called when a CPU goes offline; instead, it's handled in acpi_processor_hotplug() during online.
This means "enabled_devices" stays above zero even if some CPUs are offline.
In this case, the driver can still successfully set initialized to zero when get power information failed in power notify.
So we can disable APCI idle on all CPUs.
But we need to ensure that other threads wouldn't resume the "initialized" flag by interfaces like cpuidle_resume().

I have found a scenario for that where acpi_processor_hotplug enables the cpuidle_device and restores the "initialized" value.
In this case, special processing may be required.
For example, the cpuidle state of the cpuidle driver also need reinitialize or the disable cpuilde state is still maintained.

/Huisong