[PATCH 0/3] ACPI: processor: idle: Fix ACPI idle handling in power notify on failure

[PATCH 0/3] ACPI: processor: idle: Fix ACPI idle handling in power notify on failure

[Huisong Li]

The content in this series was initially discussed in the link [1].
This series disable ACPI idle feature if get power information failed in
power notify becuase the old idle states may not be usable anymore.

In addition, keep the same logical as acpi_processor_register_idle_driver
to get avaiable power information from all online CPUs instead of CPU0.

[1] https://lore.kernel.org/all/20251103084244.2654432-1-lihuisong@huawei.com

Huisong Li (3):
  cpuidle: Add enable_cpuidle() interface
  ACPI: processor: idle: Disable ACPI idle if get power information
    failed in power notify
  ACPI: processor: idle: Update idle states from avaiable power
    information

 drivers/acpi/processor_idle.c | 37 +++++++++++++++++++++++++++++------
 drivers/cpuidle/cpuidle.c     |  5 ++++-
 include/linux/cpuidle.h       |  2 ++
 3 files changed, 37 insertions(+), 7 deletions(-)

-- 
2.33.0

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

[Huisong Li]

The global switch of cpuidle can be turned back on in some case.
So add enable_cpuidle().

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 drivers/cpuidle/cpuidle.c | 5 ++++-
 include/linux/cpuidle.h   | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 56132e843c99..980ddfd3d930 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -48,7 +48,10 @@ void disable_cpuidle(void)
 {
 	off = 1;
 }
-
+void enable_cpuidle(void)
+{
+	off = 0;
+}
 bool cpuidle_not_available(struct cpuidle_driver *drv,
 			   struct cpuidle_device *dev)
 {
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index a9ee4fe55dcf..94c030748af3 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -168,6 +168,7 @@ struct cpuidle_driver {
 };
 
 #ifdef CONFIG_CPU_IDLE
+extern void enable_cpuidle(void);
 extern void disable_cpuidle(void);
 extern bool cpuidle_not_available(struct cpuidle_driver *drv,
 				  struct cpuidle_device *dev);
@@ -203,6 +204,7 @@ extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
 static inline struct cpuidle_device *cpuidle_get_device(void)
 {return __this_cpu_read(cpuidle_devices); }
 #else
+static inline void enable_cpuidle(void) { }
 static inline void disable_cpuidle(void) { }
 static inline bool cpuidle_not_available(struct cpuidle_driver *drv,
 					 struct cpuidle_device *dev)
-- 
2.33.0

[PATCH 2/3] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify

[Huisong Li]

The old states may not be usable any more if get power information
failed in power notify. The ACPI idle should be disabled entirely.

Fixes: f427e5f1cf75 ("ACPI / processor: Get power info before updating the C-states")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 drivers/acpi/processor_idle.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 5f86297c8b23..cd4d1d8d70b0 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1298,6 +1298,7 @@ int acpi_processor_power_state_has_changed(struct acpi_processor *pr)
 	int cpu;
 	struct acpi_processor *_pr;
 	struct cpuidle_device *dev;
+	int ret = 0;
 
 	if (disabled_by_idle_boot_param())
 		return 0;
@@ -1326,27 +1327,44 @@ int acpi_processor_power_state_has_changed(struct acpi_processor *pr)
 			cpuidle_disable_device(dev);
 		}
 
-		/* Populate Updated C-state information */
-		acpi_processor_get_power_info(pr);
+		/*
+		 * Update C-state information based on new power information.
+		 *
+		 * The same idle state is used for all CPUs.
+		 * The old idle state may not be usable anymore if fail to get
+		 * ACPI power information of CPU0.
+		 * The cpuidle of all CPUs should be disabled.
+		 */
+		ret = acpi_processor_get_power_info(pr);
+		if (ret) {
+			/* Ensure cpuidle of offline CPUs are inavaliable. */
+			disable_cpuidle();
+			pr_err("Get processor-%u power information failed, disable cpuidle of all CPUs\n",
+			       pr->id);
+			goto release_lock;
+		}
+
 		acpi_processor_setup_cpuidle_states(pr);
+		enable_cpuidle();
 
 		/* Enable all cpuidle devices */
 		for_each_online_cpu(cpu) {
 			_pr = per_cpu(processors, cpu);
 			if (!_pr || !_pr->flags.power_setup_done)
 				continue;
-			acpi_processor_get_power_info(_pr);
-			if (_pr->flags.power) {
+			ret = acpi_processor_get_power_info(_pr);
+			if (!ret && _pr->flags.power) {
 				dev = per_cpu(acpi_cpuidle_device, cpu);
 				acpi_processor_setup_cpuidle_dev(_pr, dev);
 				cpuidle_enable_device(dev);
 			}
 		}
+release_lock:
 		cpuidle_resume_and_unlock();
 		cpus_read_unlock();
 	}
 
-	return 0;
+	return ret;
 }
 
 void acpi_processor_register_idle_driver(void)
-- 
2.33.0

[PATCH 3/3] ACPI: processor: idle: Update idle states from avaiable power information

[Huisong Li]

Currently, the ACPI power notify makes it once per system instead of once per-cpu.
And driver selects the notify on CPU0 to update idle states.

The same idle state is used for all CPUs. An avaiable power information
is obtained successfully from any CPUs can be used to populate the ACPI idle
states as acpi_processor_register_idle_driver() did.
So keep the same logical to get avaiable power information from online CPUs
instead of CPU0 to update idle states in power notify.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 drivers/acpi/processor_idle.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index cd4d1d8d70b0..8d3122a4e6d0 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1332,19 +1332,26 @@ int acpi_processor_power_state_has_changed(struct acpi_processor *pr)
 		 *
 		 * The same idle state is used for all CPUs.
 		 * The old idle state may not be usable anymore if fail to get
-		 * ACPI power information of CPU0.
+		 * available ACPI power information from any online CPU.
 		 * The cpuidle of all CPUs should be disabled.
 		 */
-		ret = acpi_processor_get_power_info(pr);
+		ret = -ENODEV;
+		for_each_online_cpu(cpu) {
+			_pr = per_cpu(processors, cpu);
+			if (!_pr && !_pr->flags.power_setup_done)
+				continue;
+			ret = acpi_processor_get_power_info(_pr);
+			if (!ret) {
+				acpi_processor_setup_cpuidle_states(_pr);
+				break;
+			}
+		}
 		if (ret) {
 			/* Ensure cpuidle of offline CPUs are inavaliable. */
 			disable_cpuidle();
-			pr_err("Get processor-%u power information failed, disable cpuidle of all CPUs\n",
-			       pr->id);
+			pr_err("No available ACPI power information, disable cpuidle of all CPUs.\n");
 			goto release_lock;
 		}
-
-		acpi_processor_setup_cpuidle_states(pr);
 		enable_cpuidle();
 
 		/* Enable all cpuidle devices */
-- 
2.33.0

Re: [PATCH 2/3] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify

[kernel test robot]

Hi Huisong,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge linus/master v6.18-rc7 next-20251127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Huisong-Li/cpuidle-Add-enable_cpuidle-interface/20251125-153615
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20251125072933.3706006-3-lihuisong%40huawei.com
patch subject: [PATCH 2/3] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify
config: riscv-randconfig-001-20251127 (https://download.01.org/0day-ci/archive/20251127/202511272227.w1fgoiKQ-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 12.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251127/202511272227.w1fgoiKQ-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511272227.w1fgoiKQ-lkp@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "enable_cpuidle" [drivers/acpi/processor.ko] undefined!
>> ERROR: modpost: "disable_cpuidle" [drivers/acpi/processor.ko] undefined!

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 3/3] ACPI: processor: idle: Update idle states from avaiable power information

[Dan Carpenter]

Hi Huisong,

kernel test robot noticed the following build warnings:

https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Huisong-Li/cpuidle-Add-enable_cpuidle-interface/20251125-153615
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20251125072933.3706006-4-lihuisong%40huawei.com
patch subject: [PATCH 3/3] ACPI: processor: idle: Update idle states from avaiable power information
config: i386-randconfig-141-20251126 (https://download.01.org/0day-ci/archive/20251127/202511272353.nOqEau6n-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202511272353.nOqEau6n-lkp@intel.com/

smatch warnings:
drivers/acpi/processor_idle.c:1339 acpi_processor_power_state_has_changed() error: we previously assumed '_pr' could be null (see line 1339)

vim +/_pr +1339 drivers/acpi/processor_idle.c

a36a7fecfe6071 Sudeep Holla              2016-07-21  1294  int acpi_processor_power_state_has_changed(struct acpi_processor *pr)
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1295  {
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1296  	int cpu;
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1297  	struct acpi_processor *_pr;
3d339dcbb56d8d Daniel Lezcano            2012-09-17  1298  	struct cpuidle_device *dev;
ffff9603ddf90a Huisong Li                2025-11-25  1299  	int ret = 0;
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1300  
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1301  	if (disabled_by_idle_boot_param())
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1302  		return 0;
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1303  
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1304  	if (!pr->flags.power_setup_done)
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1305  		return -ENODEV;
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1306  
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1307  	/*
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1308  	 * FIXME:  Design the ACPI notification to make it once per
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1309  	 * system instead of once per-cpu.  This condition is a hack
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1310  	 * to make the code that updates C-States be called once.
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1311  	 */
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1312  
9505626d7bfeb5 Paul E. McKenney          2012-02-28  1313  	if (pr->id == 0 && cpuidle_get_driver() == &acpi_idle_driver) {
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1314  
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1315  		/* Protect against cpu-hotplug */
95ac706744de78 Sebastian Andrzej Siewior 2021-08-03  1316  		cpus_read_lock();
6726655dfdd2dc Jiri Kosina               2014-09-03  1317  		cpuidle_pause_and_lock();
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1318  
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1319  		/* Disable all cpuidle devices */
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1320  		for_each_online_cpu(cpu) {
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1321  			_pr = per_cpu(processors, cpu);
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1322  			if (!_pr || !_pr->flags.power_setup_done)
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1323  				continue;
3d339dcbb56d8d Daniel Lezcano            2012-09-17  1324  			dev = per_cpu(acpi_cpuidle_device, cpu);
3d339dcbb56d8d Daniel Lezcano            2012-09-17  1325  			cpuidle_disable_device(dev);
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1326  		}
46bcfad7a819bd Deepthi Dharwar           2011-10-28  1327  
ffff9603ddf90a Huisong Li                2025-11-25  1328  		/*
ffff9603ddf90a Huisong Li                2025-11-25  1329  		 * Update C-state information based on new power information.
ffff9603ddf90a Huisong Li                2025-11-25  1330  		 *
ffff9603ddf90a Huisong Li                2025-11-25  1331  		 * The same idle state is used for all CPUs.
ffff9603ddf90a Huisong Li                2025-11-25  1332  		 * The old idle state may not be usable anymore if fail to get
092a52b5417fd4 Huisong Li                2025-11-25  1333  		 * available ACPI power information from any online CPU.
ffff9603ddf90a Huisong Li                2025-11-25  1334  		 * The cpuidle of all CPUs should be disabled.
ffff9603ddf90a Huisong Li                2025-11-25  1335  		 */
092a52b5417fd4 Huisong Li                2025-11-25  1336  		ret = -ENODEV;
092a52b5417fd4 Huisong Li                2025-11-25  1337  		for_each_online_cpu(cpu) {
092a52b5417fd4 Huisong Li                2025-11-25  1338  			_pr = per_cpu(processors, cpu);
092a52b5417fd4 Huisong Li                2025-11-25 @1339  			if (!_pr && !_pr->flags.power_setup_done)
                                                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
if _pr is NULL this will crash.  s/&&/||/

092a52b5417fd4 Huisong Li                2025-11-25  1340  				continue;
092a52b5417fd4 Huisong Li                2025-11-25  1341  			ret = acpi_processor_get_power_info(_pr);
092a52b5417fd4 Huisong Li                2025-11-25  1342  			if (!ret) {
092a52b5417fd4 Huisong Li                2025-11-25  1343  				acpi_processor_setup_cpuidle_states(_pr);

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Rafael J. Wysocki]

On Tue, Nov 25, 2025 at 8:29 AM Huisong Li <lihuisong@huawei.com> 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.

> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> ---
>  drivers/cpuidle/cpuidle.c | 5 ++++-
>  include/linux/cpuidle.h   | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 56132e843c99..980ddfd3d930 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -48,7 +48,10 @@ void disable_cpuidle(void)
>  {
>         off = 1;
>  }
> -
> +void enable_cpuidle(void)
> +{
> +       off = 0;
> +}
>  bool cpuidle_not_available(struct cpuidle_driver *drv,
>                            struct cpuidle_device *dev)
>  {
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index a9ee4fe55dcf..94c030748af3 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -168,6 +168,7 @@ struct cpuidle_driver {
>  };
>
>  #ifdef CONFIG_CPU_IDLE
> +extern void enable_cpuidle(void);
>  extern void disable_cpuidle(void);
>  extern bool cpuidle_not_available(struct cpuidle_driver *drv,
>                                   struct cpuidle_device *dev);
> @@ -203,6 +204,7 @@ extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
>  static inline struct cpuidle_device *cpuidle_get_device(void)
>  {return __this_cpu_read(cpuidle_devices); }
>  #else
> +static inline void enable_cpuidle(void) { }
>  static inline void disable_cpuidle(void) { }
>  static inline bool cpuidle_not_available(struct cpuidle_driver *drv,
>                                          struct cpuidle_device *dev)
> --
> 2.33.0
>

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

[lihuisong (C)]

On 1/15/2026 3:18 AM, Rafael J. Wysocki wrote:
> On Tue, Nov 25, 2025 at 8:29 AM Huisong Li <lihuisong@huawei.com> 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.
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> ---
>>   drivers/cpuidle/cpuidle.c | 5 ++++-
>>   include/linux/cpuidle.h   | 2 ++
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index 56132e843c99..980ddfd3d930 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -48,7 +48,10 @@ void disable_cpuidle(void)
>>   {
>>          off = 1;
>>   }
>> -
>> +void enable_cpuidle(void)
>> +{
>> +       off = 0;
>> +}
>>   bool cpuidle_not_available(struct cpuidle_driver *drv,
>>                             struct cpuidle_device *dev)
>>   {
>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>> index a9ee4fe55dcf..94c030748af3 100644
>> --- a/include/linux/cpuidle.h
>> +++ b/include/linux/cpuidle.h
>> @@ -168,6 +168,7 @@ struct cpuidle_driver {
>>   };
>>
>>   #ifdef CONFIG_CPU_IDLE
>> +extern void enable_cpuidle(void);
>>   extern void disable_cpuidle(void);
>>   extern bool cpuidle_not_available(struct cpuidle_driver *drv,
>>                                    struct cpuidle_device *dev);
>> @@ -203,6 +204,7 @@ extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
>>   static inline struct cpuidle_device *cpuidle_get_device(void)
>>   {return __this_cpu_read(cpuidle_devices); }
>>   #else
>> +static inline void enable_cpuidle(void) { }
>>   static inline void disable_cpuidle(void) { }
>>   static inline bool cpuidle_not_available(struct cpuidle_driver *drv,
>>                                           struct cpuidle_device *dev)
>> --
>> 2.33.0
>>

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

[lihuisong (C)]

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@huawei.com> 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?

Best,
/Huisong
>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>> ---
>>>   drivers/cpuidle/cpuidle.c | 5 ++++-
>>>   include/linux/cpuidle.h   | 2 ++
>>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>>> index 56132e843c99..980ddfd3d930 100644
>>> --- a/drivers/cpuidle/cpuidle.c
>>> +++ b/drivers/cpuidle/cpuidle.c
>>> @@ -48,7 +48,10 @@ void disable_cpuidle(void)
>>>   {
>>>          off = 1;
>>>   }
>>> -
>>> +void enable_cpuidle(void)
>>> +{
>>> +       off = 0;
>>> +}
>>>   bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>                             struct cpuidle_device *dev)
>>>   {
>>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>>> index a9ee4fe55dcf..94c030748af3 100644
>>> --- a/include/linux/cpuidle.h
>>> +++ b/include/linux/cpuidle.h
>>> @@ -168,6 +168,7 @@ struct cpuidle_driver {
>>>   };
>>>
>>>   #ifdef CONFIG_CPU_IDLE
>>> +extern void enable_cpuidle(void);
>>>   extern void disable_cpuidle(void);
>>>   extern bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>                                    struct cpuidle_device *dev);
>>> @@ -203,6 +204,7 @@ extern struct cpuidle_driver 
>>> *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
>>>   static inline struct cpuidle_device *cpuidle_get_device(void)
>>>   {return __this_cpu_read(cpuidle_devices); }
>>>   #else
>>> +static inline void enable_cpuidle(void) { }
>>>   static inline void disable_cpuidle(void) { }
>>>   static inline bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>                                           struct cpuidle_device *dev)
>>> -- 
>>> 2.33.0
>>>

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

[lihuisong (C)]

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@huawei.com> 
>>> 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.

/Huisong
>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>> ---
>>>>   drivers/cpuidle/cpuidle.c | 5 ++++-
>>>>   include/linux/cpuidle.h   | 2 ++
>>>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>>>> index 56132e843c99..980ddfd3d930 100644
>>>> --- a/drivers/cpuidle/cpuidle.c
>>>> +++ b/drivers/cpuidle/cpuidle.c
>>>> @@ -48,7 +48,10 @@ void disable_cpuidle(void)
>>>>   {
>>>>          off = 1;
>>>>   }
>>>> -
>>>> +void enable_cpuidle(void)
>>>> +{
>>>> +       off = 0;
>>>> +}
>>>>   bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>>                             struct cpuidle_device *dev)
>>>>   {
>>>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>>>> index a9ee4fe55dcf..94c030748af3 100644
>>>> --- a/include/linux/cpuidle.h
>>>> +++ b/include/linux/cpuidle.h
>>>> @@ -168,6 +168,7 @@ struct cpuidle_driver {
>>>>   };
>>>>
>>>>   #ifdef CONFIG_CPU_IDLE
>>>> +extern void enable_cpuidle(void);
>>>>   extern void disable_cpuidle(void);
>>>>   extern bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>>                                    struct cpuidle_device *dev);
>>>> @@ -203,6 +204,7 @@ extern struct cpuidle_driver 
>>>> *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
>>>>   static inline struct cpuidle_device *cpuidle_get_device(void)
>>>>   {return __this_cpu_read(cpuidle_devices); }
>>>>   #else
>>>> +static inline void enable_cpuidle(void) { }
>>>>   static inline void disable_cpuidle(void) { }
>>>>   static inline bool cpuidle_not_available(struct cpuidle_driver *drv,
>>>>                                           struct cpuidle_device *dev)
>>>> -- 
>>>> 2.33.0
>>>>
>
>

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

[Rafael J. Wysocki]

On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> 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@huawei.com>
> >>> 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?

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

[lihuisong (C)]

On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> 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@huawei.com>
>>>>> 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@huawei.com

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

[Rafael J. Wysocki]

On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com> wrote:
>
>
> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> > On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> 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@huawei.com>
> >>>>> 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@huawei.com

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.

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

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@huawei.com> wrote:
>>
>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> 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@huawei.com>
>>>>>>> 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@huawei.com
> 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

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

[lihuisong (C)]

On 3/28/2026 12:06 PM, lihuisong (C) wrote:
>
> On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
>> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com> 
>> wrote:
>>>
>>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
>>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C) 
>>>> <lihuisong@huawei.com> 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@huawei.com>
>>>>>>>> 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@huawei.com 
>>>
>> 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.
>
Hi Rafel,

I have thought about this issue for a long time. I feel that it is a bit 
tricky to handle.

First, if the power information fails to be obtained from the power 
notify, we want to disable the ACPI idle of all CPUs by calling 
cpuidle_pause(). However, in the CPU hotplug scenario, when the idle 
state may be unavailable, the idle state needs to be set up again.

Second, I found that the current driver only calls 
acpi_processor_setup_cpuidle_states() to update the idle states in 
acpi_idle_driver.
Other variables in acpi_idle_driver also need to be initialized again. 
For example, target_residency_ns and exit_latency_ns need to be updated.
For details, see the implementation of __cpuidle_register_driver().
These variables are used when selecting the state to enter (please see 
cpuidle_enter_state()).
Therefore, when the idle states information changes, the idle states we 
actually use are still the old values.
This is also a problem.

I am not sure whether we need to remove all cpuidle_device, remove 
acpi_idle_driver, and then re-initialize and register acpi_idle_driver 
and register all cpuidle_device in power notify.
I think it is very likely that we need to do so.

/Huisong
>
>

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

[Rafael J. Wysocki]

Hi,

On Tue, Mar 31, 2026 at 2:01 PM lihuisong (C) <lihuisong@huawei.com> wrote:
>
>
> On 3/28/2026 12:06 PM, lihuisong (C) wrote:
> >
> > On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
> >> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com>
> >> wrote:
> >>>
> >>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> >>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C)
> >>>> <lihuisong@huawei.com> 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@huawei.com>
> >>>>>>>> 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@huawei.com
> >>>
> >> 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.
> >
> Hi Rafel,
>
> I have thought about this issue for a long time. I feel that it is a bit
> tricky to handle.
>
> First, if the power information fails to be obtained from the power
> notify, we want to disable the ACPI idle of all CPUs by calling
> cpuidle_pause(). However, in the CPU hotplug scenario, when the idle
> state may be unavailable, the idle state needs to be set up again.
>
> Second, I found that the current driver only calls
> acpi_processor_setup_cpuidle_states() to update the idle states in
> acpi_idle_driver.
> Other variables in acpi_idle_driver also need to be initialized again.
> For example, target_residency_ns and exit_latency_ns need to be updated.
> For details, see the implementation of __cpuidle_register_driver().
> These variables are used when selecting the state to enter (please see
> cpuidle_enter_state()).
> Therefore, when the idle states information changes, the idle states we
> actually use are still the old values.
> This is also a problem.
>
> I am not sure whether we need to remove all cpuidle_device, remove
> acpi_idle_driver, and then re-initialize and register acpi_idle_driver
> and register all cpuidle_device in power notify.
> I think it is very likely that we need to do so.

Well, yes, we do, but only if the list of available states has
actually changed (that is, the number of states has changed or the
latency values have changed).

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

[Rafael J. Wysocki]

On Tue, Mar 31, 2026 at 2:05 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> Hi,
>
> On Tue, Mar 31, 2026 at 2:01 PM lihuisong (C) <lihuisong@huawei.com> wrote:
> >
> >
> > On 3/28/2026 12:06 PM, lihuisong (C) wrote:
> > >
> > > On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
> > >> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com>
> > >> wrote:
> > >>>
> > >>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> > >>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C)
> > >>>> <lihuisong@huawei.com> 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@huawei.com>
> > >>>>>>>> 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@huawei.com
> > >>>
> > >> 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.
> > >
> > Hi Rafel,
> >
> > I have thought about this issue for a long time. I feel that it is a bit
> > tricky to handle.
> >
> > First, if the power information fails to be obtained from the power
> > notify, we want to disable the ACPI idle of all CPUs by calling
> > cpuidle_pause(). However, in the CPU hotplug scenario, when the idle
> > state may be unavailable, the idle state needs to be set up again.
> >
> > Second, I found that the current driver only calls
> > acpi_processor_setup_cpuidle_states() to update the idle states in
> > acpi_idle_driver.
> > Other variables in acpi_idle_driver also need to be initialized again.
> > For example, target_residency_ns and exit_latency_ns need to be updated.
> > For details, see the implementation of __cpuidle_register_driver().
> > These variables are used when selecting the state to enter (please see
> > cpuidle_enter_state()).
> > Therefore, when the idle states information changes, the idle states we
> > actually use are still the old values.
> > This is also a problem.
> >
> > I am not sure whether we need to remove all cpuidle_device, remove
> > acpi_idle_driver, and then re-initialize and register acpi_idle_driver
> > and register all cpuidle_device in power notify.
> > I think it is very likely that we need to do so.
>
> Well, yes, we do, but only if the list of available states has
> actually changed (that is, the number of states has changed or the
> latency values have changed).

What actually needs to be done there is to unregister the cpuidle
driver and register it again because the list of idle states is a
property of the driver.

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

[lihuisong (C)]

On 3/31/2026 8:10 PM, Rafael J. Wysocki wrote:
> On Tue, Mar 31, 2026 at 2:05 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>> Hi,
>>
>> On Tue, Mar 31, 2026 at 2:01 PM lihuisong (C) <lihuisong@huawei.com> wrote:
>>>
>>> On 3/28/2026 12:06 PM, lihuisong (C) wrote:
>>>> On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
>>>>> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com>
>>>>> wrote:
>>>>>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
>>>>>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C)
>>>>>>> <lihuisong@huawei.com> 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@huawei.com>
>>>>>>>>>>> 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@huawei.com
>>>>>>
>>>>> 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.
>>>>
>>> Hi Rafel,
>>>
>>> I have thought about this issue for a long time. I feel that it is a bit
>>> tricky to handle.
>>>
>>> First, if the power information fails to be obtained from the power
>>> notify, we want to disable the ACPI idle of all CPUs by calling
>>> cpuidle_pause(). However, in the CPU hotplug scenario, when the idle
>>> state may be unavailable, the idle state needs to be set up again.
>>>
>>> Second, I found that the current driver only calls
>>> acpi_processor_setup_cpuidle_states() to update the idle states in
>>> acpi_idle_driver.
>>> Other variables in acpi_idle_driver also need to be initialized again.
>>> For example, target_residency_ns and exit_latency_ns need to be updated.
>>> For details, see the implementation of __cpuidle_register_driver().
>>> These variables are used when selecting the state to enter (please see
>>> cpuidle_enter_state()).
>>> Therefore, when the idle states information changes, the idle states we
>>> actually use are still the old values.
>>> This is also a problem.
>>>
>>> I am not sure whether we need to remove all cpuidle_device, remove
>>> acpi_idle_driver, and then re-initialize and register acpi_idle_driver
>>> and register all cpuidle_device in power notify.
>>> I think it is very likely that we need to do so.
>> Well, yes, we do, but only if the list of available states has
>> actually changed (that is, the number of states has changed or the
>> latency values have changed).
> What actually needs to be done there is to unregister the cpuidle
> driver and register it again because the list of idle states is a
> property of the driver.
We also need to unregister and register cpuidle device again.
Because the state count of ACPI idle driver may be changed, some 
releated sysfs need to be recreated.

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

[Rafael J. Wysocki]

On Tue, Mar 31, 2026 at 2:48 PM lihuisong (C) <lihuisong@huawei.com> wrote:
>
>
> On 3/31/2026 8:10 PM, Rafael J. Wysocki wrote:
> > On Tue, Mar 31, 2026 at 2:05 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >> Hi,
> >>
> >> On Tue, Mar 31, 2026 at 2:01 PM lihuisong (C) <lihuisong@huawei.com> wrote:
> >>>
> >>> On 3/28/2026 12:06 PM, lihuisong (C) wrote:
> >>>> On 3/27/2026 7:33 PM, Rafael J. Wysocki wrote:
> >>>>> On Fri, Mar 27, 2026 at 7:23 AM lihuisong (C) <lihuisong@huawei.com>
> >>>>> wrote:
> >>>>>> On 3/26/2026 9:39 PM, Rafael J. Wysocki wrote:
> >>>>>>> On Thu, Mar 26, 2026 at 1:17 PM lihuisong (C)
> >>>>>>> <lihuisong@huawei.com> 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@huawei.com>
> >>>>>>>>>>> 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@huawei.com
> >>>>>>
> >>>>> 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.
> >>>>
> >>> Hi Rafel,
> >>>
> >>> I have thought about this issue for a long time. I feel that it is a bit
> >>> tricky to handle.
> >>>
> >>> First, if the power information fails to be obtained from the power
> >>> notify, we want to disable the ACPI idle of all CPUs by calling
> >>> cpuidle_pause(). However, in the CPU hotplug scenario, when the idle
> >>> state may be unavailable, the idle state needs to be set up again.
> >>>
> >>> Second, I found that the current driver only calls
> >>> acpi_processor_setup_cpuidle_states() to update the idle states in
> >>> acpi_idle_driver.
> >>> Other variables in acpi_idle_driver also need to be initialized again.
> >>> For example, target_residency_ns and exit_latency_ns need to be updated.
> >>> For details, see the implementation of __cpuidle_register_driver().
> >>> These variables are used when selecting the state to enter (please see
> >>> cpuidle_enter_state()).
> >>> Therefore, when the idle states information changes, the idle states we
> >>> actually use are still the old values.
> >>> This is also a problem.
> >>>
> >>> I am not sure whether we need to remove all cpuidle_device, remove
> >>> acpi_idle_driver, and then re-initialize and register acpi_idle_driver
> >>> and register all cpuidle_device in power notify.
> >>> I think it is very likely that we need to do so.
> >> Well, yes, we do, but only if the list of available states has
> >> actually changed (that is, the number of states has changed or the
> >> latency values have changed).
> > What actually needs to be done there is to unregister the cpuidle
> > driver and register it again because the list of idle states is a
> > property of the driver.
>
> We also need to unregister and register cpuidle device again.
> Because the state count of ACPI idle driver may be changed, some
> releated sysfs need to be recreated.

Ah, right.  So all cpuidle needs to be torn down and re-created from
scratch then.

I'm starting to wonder if that's really worth it.