[PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Lifeng Zheng]

Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
even though they're eligible.

Changelog:

v6:

 - discard the modifications in cpufreq.c, and instead, make
   supports_scale_freq_counters() checks that at least one CPU in the
   policy supports AMU FIE, instead of all
 - based on Beata's feedback, optimize cpuhp_topology_online() to make it
   more readable
 - use pr_warn instead of WARN_ON to show warning message when the
   freq_counters_valid() check fails in cpuhp_topology_online()
 - modify commit message as Beata and Rafael suggested

v5:

 - add a default implementation for cpufreq_cpu_policy() when
   CONFIG_CPU_FREQ is not defined

v4:

 - change the function's name in patch 2 from
   'cpufreq_cpu_get_raw_no_check' to 'cpufreq_cpu_policy'
 - use only one line in the function body of cpufreq_cpu_policy()
 - use cpus mask instead of related_cpus when calling arch_set_freq_scale()
   in cpufreq.c
 - add a warning when the freq_counters_valid() check fails in
   cpuhp_topology_online()

v3:

 - add a patch to optimize amu_fie_setup()
 - add a patch to add a function to get cpufreq policy without checking if
   the CPU is online
 - discard the reuse of amu_fie_setup() in cpuhp_topology_online() and keep
   all the new logic in cpuhp_topology_online()
 - test only the CPU which is going online in cpuhp_topology_online()
 - when the freq_counters_valid() check fails, not only clear the scale
   freq source but also clear all the related CPUs from amu_fie_cpus mask
 - add some comments

v2:

 - keep init_amu_fie_notifier for setting up AMU FIE when the cpufreq
   policy is being created
 - set up AMU FIE only for online CPUs instead of related_cpus in
   init_amu_fie_callback()
 - check and set all the online CPUs in the same policy when hotplug one
 - clear scale freq source for all the online CPUs in the same policy to
   avoid using different source of the freq scale

---
Discussions of previous version:
v1: https://lore.kernel.org/all/20250607094533.416368-1-zhenglifeng1@huawei.com/
v2: https://lore.kernel.org/all/20250725102813.1404322-1-zhenglifeng1@huawei.com/
v3: https://lore.kernel.org/all/20250805093330.3715444-1-zhenglifeng1@huawei.com/
v4: https://lore.kernel.org/all/20250814072853.3426386-1-zhenglifeng1@huawei.com/
v5: https://lore.kernel.org/all/20250819072931.1647431-1-zhenglifeng1@huawei.com/

Lifeng Zheng (3):
  arm64: topology: Skip already covered CPUs when setting freq source
  cpufreq: Add new helper function returning cpufreq policy
  arm64: topology: Handle AMU FIE setup on CPU hotplug

 arch/arm64/kernel/topology.c | 67 ++++++++++++++++++++++++++++++++++--
 drivers/base/arch_topology.c |  9 ++++-
 drivers/cpufreq/cpufreq.c    |  6 ++++
 include/linux/cpufreq.h      |  5 +++
 4 files changed, 83 insertions(+), 4 deletions(-)

-- 
2.33.0

[PATCH v6 1/3] arm64: topology: Skip already covered CPUs when setting freq source

[Lifeng Zheng]

The scale freq source of the CPUs in 'amu_fie_cpus' mask are already set to
AMU tick before, so in amu_fie_setup(), only the CPUs in the 'cpus' mask
should be set.

Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Reviewed-by: Beata Michalska <beata.michalska@arm.com>
Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
---
 arch/arm64/kernel/topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 5d07ee85bdae..9317a618bb87 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -373,7 +373,7 @@ static void amu_fie_setup(const struct cpumask *cpus)
 
 	cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus);
 
-	topology_set_scale_freq_source(&amu_sfd, amu_fie_cpus);
+	topology_set_scale_freq_source(&amu_sfd, cpus);
 
 	pr_debug("CPUs[%*pbl]: counters will be used for FIE.",
 		 cpumask_pr_args(cpus));
-- 
2.33.0

[PATCH v6 2/3] cpufreq: Add new helper function returning cpufreq policy

[Lifeng Zheng]

cpufreq_cpu_get_raw() gets cpufreq policy only if the CPU is in
policy->cpus mask, which means the CPU is already online. But in some
cases, the policy is needed before the CPU is added to cpus mask. Add a
function to get the policy in these cases.

Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
---
 drivers/cpufreq/cpufreq.c | 6 ++++++
 include/linux/cpufreq.h   | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 852e024facc3..e8d7544b77b8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -198,6 +198,12 @@ struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
 }
 EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
 
+struct cpufreq_policy *cpufreq_cpu_policy(unsigned int cpu)
+{
+	return per_cpu(cpufreq_cpu_data, cpu);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_policy);
+
 unsigned int cpufreq_generic_get(unsigned int cpu)
 {
 	struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 0465d1e6f72a..cc894fc38971 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -203,6 +203,7 @@ struct cpufreq_freqs {
 
 #ifdef CONFIG_CPU_FREQ
 struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu);
+struct cpufreq_policy *cpufreq_cpu_policy(unsigned int cpu);
 struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
 void cpufreq_cpu_put(struct cpufreq_policy *policy);
 #else
@@ -210,6 +211,10 @@ static inline struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
 {
 	return NULL;
 }
+static inline struct cpufreq_policy *cpufreq_cpu_policy(unsigned int cpu)
+{
+	return NULL;
+}
 static inline struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
 {
 	return NULL;
-- 
2.33.0

[PATCH v6 3/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Lifeng Zheng]

Currently, when a cpufreq policy is created, the AMU FIE setup process
checks all CPUs in the policy -- including those that are offline. If any
of these CPUs are offline at that time, their AMU capability flag hasn't
been verified yet, leading the check fail. As a result, AMU FIE is not
enabled, even if the CPUs that are online do support it.

Later, when the previously offline CPUs come online and report AMU support,
there's no mechanism in place to re-enable AMU FIE for the policy. This
leaves the entire frequency domain without AMU FIE, despite being eligible.

Restrict the initial AMU FIE check to only those CPUs that are online at
the time the policy is created, and allow CPUs that come online later to
join the policy with AMU FIE enabled.

Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
---
 arch/arm64/kernel/topology.c | 65 ++++++++++++++++++++++++++++++++++--
 drivers/base/arch_topology.c |  9 ++++-
 2 files changed, 71 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 9317a618bb87..4935a593e37a 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -385,7 +385,7 @@ static int init_amu_fie_callback(struct notifier_block *nb, unsigned long val,
 	struct cpufreq_policy *policy = data;
 
 	if (val == CPUFREQ_CREATE_POLICY)
-		amu_fie_setup(policy->related_cpus);
+		amu_fie_setup(policy->cpus);
 
 	/*
 	 * We don't need to handle CPUFREQ_REMOVE_POLICY event as the AMU
@@ -404,10 +404,71 @@ static struct notifier_block init_amu_fie_notifier = {
 	.notifier_call = init_amu_fie_callback,
 };
 
+static int cpuhp_topology_online(unsigned int cpu)
+{
+	struct cpufreq_policy *policy = cpufreq_cpu_policy(cpu);
+
+	/* Those are cheap checks */
+
+	/*
+	 * Skip this CPU if:
+	 *  - it has no cpufreq policy assigned yet,
+	 *  - no policy exists that spans CPUs with AMU counters, or
+	 *  - it was already handled.
+	 */
+	if (unlikely(!policy) || !cpumask_available(amu_fie_cpus) ||
+	    cpumask_test_cpu(cpu, amu_fie_cpus))
+		return 0;
+
+	/*
+	 * Only proceed if all already-online CPUs in this policy
+	 * support AMU counters.
+	 */
+	if (unlikely(!cpumask_subset(policy->cpus, amu_fie_cpus)))
+		return 0;
+
+	/*
+	 * If the new online CPU cannot pass this check, all the CPUs related to
+	 * the same policy should be clear from amu_fie_cpus mask, otherwise they
+	 * may use different source of the freq scale.
+	 */
+	if (!freq_counters_valid(cpu)) {
+		pr_warn("CPU[%u] doesn't support AMU counters\n", cpu);
+		topology_clear_scale_freq_source(SCALE_FREQ_SOURCE_ARCH,
+						 policy->related_cpus);
+		cpumask_andnot(amu_fie_cpus, amu_fie_cpus, policy->related_cpus);
+		return 0;
+	}
+
+	cpumask_set_cpu(cpu, amu_fie_cpus);
+
+	topology_set_scale_freq_source(&amu_sfd, cpumask_of(cpu));
+
+	pr_debug("CPU[%u]: counter will be used for FIE.", cpu);
+
+	return 0;
+}
+
 static int __init init_amu_fie(void)
 {
-	return cpufreq_register_notifier(&init_amu_fie_notifier,
+	int ret;
+
+	ret = cpufreq_register_notifier(&init_amu_fie_notifier,
 					CPUFREQ_POLICY_NOTIFIER);
+	if (ret)
+		return ret;
+
+	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+					"arm64/topology:online",
+					cpuhp_topology_online,
+					NULL);
+	if (ret < 0) {
+		cpufreq_unregister_notifier(&init_amu_fie_notifier,
+					    CPUFREQ_POLICY_NOTIFIER);
+		return ret;
+	}
+
+	return 0;
 }
 core_initcall(init_amu_fie);
 
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index e1eff05bea4a..331a0654f3dc 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -34,7 +34,14 @@ EXPORT_PER_CPU_SYMBOL_GPL(capacity_freq_ref);
 
 static bool supports_scale_freq_counters(const struct cpumask *cpus)
 {
-	return cpumask_subset(cpus, &scale_freq_counters_mask);
+	int i;
+
+	for_each_cpu(i, cpus) {
+		if (cpumask_test_cpu(i, &scale_freq_counters_mask))
+			return true;
+	}
+
+	return false;
 }
 
 bool topology_scale_freq_invariant(void)
-- 
2.33.0

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Catalin Marinas]

On Wed, 19 Nov 2025 16:13:53 +0800, Lifeng Zheng wrote:
> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
> even though they're eligible.
> 
> Changelog:
> 
> v6:
> 
> [...]

Applied to arm64 (for-next/topology), thanks!

[1/3] arm64: topology: Skip already covered CPUs when setting freq source
      https://git.kernel.org/arm64/c/a04fd8bcd6aa
[2/3] cpufreq: Add new helper function returning cpufreq policy
      https://git.kernel.org/arm64/c/709a16bebc54
[3/3] arm64: topology: Handle AMU FIE setup on CPU hotplug
      https://git.kernel.org/arm64/c/1ea7e37e26b3

-- 
Catalin


-- 
Catalin

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Catalin Marinas]

On Tue, Nov 25, 2025 at 06:29:53PM +0000, Catalin Marinas wrote:
> On Wed, 19 Nov 2025 16:13:53 +0800, Lifeng Zheng wrote:
> > Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
> > even though they're eligible.
> > 
> > Changelog:
> > 
> > v6:
> > 
> > [...]
> 
> Applied to arm64 (for-next/topology), thanks!
> 
> [1/3] arm64: topology: Skip already covered CPUs when setting freq source
>       https://git.kernel.org/arm64/c/a04fd8bcd6aa
> [2/3] cpufreq: Add new helper function returning cpufreq policy
>       https://git.kernel.org/arm64/c/709a16bebc54
> [3/3] arm64: topology: Handle AMU FIE setup on CPU hotplug
>       https://git.kernel.org/arm64/c/1ea7e37e26b3

I think Beata still has to review the last patch in the series, so I'll
drop it for now from -next. Sorry about this.

-- 
Catalin

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Beata Michalska]

Hi,

Apologies for the delay in reviewing this - currently in progress....
Out of curiosity: what's the cpufreq driver used for testing this series ?

---
BR
Beata
On Wed, Nov 19, 2025 at 04:13:53PM +0800, Lifeng Zheng wrote:
> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
> even though they're eligible.
> 
> Changelog:
> 
> v6:
> 
>  - discard the modifications in cpufreq.c, and instead, make
>    supports_scale_freq_counters() checks that at least one CPU in the
>    policy supports AMU FIE, instead of all
>  - based on Beata's feedback, optimize cpuhp_topology_online() to make it
>    more readable
>  - use pr_warn instead of WARN_ON to show warning message when the
>    freq_counters_valid() check fails in cpuhp_topology_online()
>  - modify commit message as Beata and Rafael suggested
> 
> v5:
> 
>  - add a default implementation for cpufreq_cpu_policy() when
>    CONFIG_CPU_FREQ is not defined
> 
> v4:
> 
>  - change the function's name in patch 2 from
>    'cpufreq_cpu_get_raw_no_check' to 'cpufreq_cpu_policy'
>  - use only one line in the function body of cpufreq_cpu_policy()
>  - use cpus mask instead of related_cpus when calling arch_set_freq_scale()
>    in cpufreq.c
>  - add a warning when the freq_counters_valid() check fails in
>    cpuhp_topology_online()
> 
> v3:
> 
>  - add a patch to optimize amu_fie_setup()
>  - add a patch to add a function to get cpufreq policy without checking if
>    the CPU is online
>  - discard the reuse of amu_fie_setup() in cpuhp_topology_online() and keep
>    all the new logic in cpuhp_topology_online()
>  - test only the CPU which is going online in cpuhp_topology_online()
>  - when the freq_counters_valid() check fails, not only clear the scale
>    freq source but also clear all the related CPUs from amu_fie_cpus mask
>  - add some comments
> 
> v2:
> 
>  - keep init_amu_fie_notifier for setting up AMU FIE when the cpufreq
>    policy is being created
>  - set up AMU FIE only for online CPUs instead of related_cpus in
>    init_amu_fie_callback()
>  - check and set all the online CPUs in the same policy when hotplug one
>  - clear scale freq source for all the online CPUs in the same policy to
>    avoid using different source of the freq scale
> 
> ---
> Discussions of previous version:
> v1: https://lore.kernel.org/all/20250607094533.416368-1-zhenglifeng1@huawei.com/
> v2: https://lore.kernel.org/all/20250725102813.1404322-1-zhenglifeng1@huawei.com/
> v3: https://lore.kernel.org/all/20250805093330.3715444-1-zhenglifeng1@huawei.com/
> v4: https://lore.kernel.org/all/20250814072853.3426386-1-zhenglifeng1@huawei.com/
> v5: https://lore.kernel.org/all/20250819072931.1647431-1-zhenglifeng1@huawei.com/
> 
> Lifeng Zheng (3):
>   arm64: topology: Skip already covered CPUs when setting freq source
>   cpufreq: Add new helper function returning cpufreq policy
>   arm64: topology: Handle AMU FIE setup on CPU hotplug
> 
>  arch/arm64/kernel/topology.c | 67 ++++++++++++++++++++++++++++++++++--
>  drivers/base/arch_topology.c |  9 ++++-
>  drivers/cpufreq/cpufreq.c    |  6 ++++
>  include/linux/cpufreq.h      |  5 +++
>  4 files changed, 83 insertions(+), 4 deletions(-)
> 
> -- 
> 2.33.0
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[zhenglifeng (A)]

On 2025/12/1 23:27, Beata Michalska wrote:
> Hi,
> 
> Apologies for the delay in reviewing this - currently in progress....
> Out of curiosity: what's the cpufreq driver used for testing this series ?

I used cppc_cpufreq for testing this. But with some modifications in
processor_driver.c, or you'll find that the driver will fail to load with
maxcpus set. The modification below is only a temporary solution. I'm still
working on that.

---
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 5d824435b26b..2f286a1b0b02 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -33,6 +33,7 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Processor Driver");
 MODULE_LICENSE("GPL");
 
+static int acpi_processor_start(struct device *dev);
 static int acpi_processor_stop(struct device *dev);
 
 static const struct acpi_device_id processor_device_ids[] = {
@@ -46,6 +47,7 @@ static struct device_driver acpi_processor_driver = {
 	.name = "processor",
 	.bus = &cpu_subsys,
 	.acpi_match_table = processor_device_ids,
+	.probe = acpi_processor_start,
 	.remove = acpi_processor_stop,
 };
 
@@ -191,6 +193,21 @@ static int __acpi_processor_start(struct acpi_device *device)
 	return result;
 }
 
+static int acpi_processor_start(struct device *dev)
+{
+	struct acpi_device *device = ACPI_COMPANION(dev);
+	int ret;
+
+	if (!device)
+		return -ENODEV;
+
+	/* Protect against concurrent CPU hotplug operations */
+	cpu_hotplug_disable();
+	ret = __acpi_processor_start(device);
+	cpu_hotplug_enable();
+	return ret;
+}
+
 static int acpi_processor_stop(struct device *dev)
 {
 	struct acpi_device *device = ACPI_COMPANION(dev);
@@ -264,9 +281,9 @@ static int __init acpi_processor_driver_init(void)
 
 	acpi_processor_register_idle_driver();
 
-	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
-				   "acpi/cpu-drv:online",
-				   acpi_soft_cpu_online, NULL);
+	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+					   "acpi/cpu-drv:online",
+					   acpi_soft_cpu_online, NULL);
 	if (result < 0)
 		goto err;
 	hp_online = result;

> 
> ---
> BR
> Beata
> On Wed, Nov 19, 2025 at 04:13:53PM +0800, Lifeng Zheng wrote:
>> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
>> even though they're eligible.
>>
>>
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[zhenglifeng (A)]

On 2025/12/2 11:05, zhenglifeng (A) wrote:
> On 2025/12/1 23:27, Beata Michalska wrote:
>> Hi,
>>
>> Apologies for the delay in reviewing this - currently in progress....
>> Out of curiosity: what's the cpufreq driver used for testing this series ?
> 
> I used cppc_cpufreq for testing this. But with some modifications in
> processor_driver.c, or you'll find that the driver will fail to load with
> maxcpus set. The modification below is only a temporary solution. I'm still
> working on that.

In addition, I exposed some sysfs interfaces for easily checking freq scale
and source as below when testing. Hope this helps.

---
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 331a0654f3dc..ba15c90cf908 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -98,6 +98,23 @@ void topology_set_scale_freq_source(struct scale_freq_data *data,
 }
 EXPORT_SYMBOL_GPL(topology_set_scale_freq_source);
 
+int topology_get_scale_freq_source(int cpu)
+{
+	struct scale_freq_data *sfd;
+	int scale_freq_source;
+
+	rcu_read_lock();
+
+	sfd = rcu_dereference(*per_cpu_ptr(&sft_data, cpu));
+	if (sfd)
+		scale_freq_source = sfd->source;
+
+	rcu_read_unlock();
+
+	return scale_freq_source;
+}
+EXPORT_SYMBOL_GPL(topology_get_scale_freq_source);
+
 void topology_clear_scale_freq_source(enum scale_freq_source source,
 				      const struct cpumask *cpus)
 {
diff --git a/drivers/base/topology.c b/drivers/base/topology.c
index c890e2a5b428..79c0dc8d5361 100644
--- a/drivers/base/topology.c
+++ b/drivers/base/topology.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/hardirq.h>
 #include <linux/topology.h>
+#include <linux/arch_topology.h>
 
 #define define_id_show_func(name, fmt)					\
 static ssize_t name##_show(struct device *dev,				\
@@ -226,7 +227,27 @@ static ssize_t cpu_capacity_show(struct device *dev,
 	return sysfs_emit(buf, "%lu\n", topology_get_cpu_scale(cpu->dev.id));
 }
 
+static ssize_t arch_freq_scale_show(struct device *dev,
+				    struct device_attribute *attr,
+				    char *buf)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+
+	return sysfs_emit(buf, "%lu\n", topology_get_freq_scale(cpu->dev.id));
+}
+
+static ssize_t scale_freq_source_show(struct device *dev,
+				    struct device_attribute *attr,
+				    char *buf)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+
+	return sysfs_emit(buf, "%d\n", topology_get_scale_freq_source(cpu->dev.id));
+}
+
 static DEVICE_ATTR_RO(cpu_capacity);
+static DEVICE_ATTR_RO(arch_freq_scale);
+static DEVICE_ATTR_RO(scale_freq_source);
 
 static int cpu_capacity_sysctl_add(unsigned int cpu)
 {
@@ -236,6 +257,8 @@ static int cpu_capacity_sysctl_add(unsigned int cpu)
 		return -ENOENT;
 
 	device_create_file(cpu_dev, &dev_attr_cpu_capacity);
+	device_create_file(cpu_dev, &dev_attr_arch_freq_scale);
+	device_create_file(cpu_dev, &dev_attr_scale_freq_source);
 
 	return 0;
 }
@@ -248,6 +271,8 @@ static int cpu_capacity_sysctl_remove(unsigned int cpu)
 		return -ENOENT;
 
 	device_remove_file(cpu_dev, &dev_attr_cpu_capacity);
+	device_remove_file(cpu_dev, &dev_attr_arch_freq_scale);
+	device_remove_file(cpu_dev, &dev_attr_scale_freq_source);
 
 	return 0;
 }
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index d72d6e5aa200..0149aef7b684 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -47,6 +47,7 @@ struct scale_freq_data {
 
 void topology_scale_freq_tick(void);
 void topology_set_scale_freq_source(struct scale_freq_data *data, const struct cpumask *cpus);
+int topology_get_scale_freq_source(int cpu);
 void topology_clear_scale_freq_source(enum scale_freq_source source, const struct cpumask *cpus);
 
 DECLARE_PER_CPU(unsigned long, hw_pressure);

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Beata Michalska]

On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
> On 2025/12/1 23:27, Beata Michalska wrote:
> > Hi,
> > 
> > Apologies for the delay in reviewing this - currently in progress....
> > Out of curiosity: what's the cpufreq driver used for testing this series ?
> 
> I used cppc_cpufreq for testing this. But with some modifications in
> processor_driver.c, or you'll find that the driver will fail to load with
> maxcpus set. The modification below is only a temporary solution. I'm still
> working on that.
>
Right, so overall the implementation looks good - thanks for that.
There are two issues though with the cppc cpufreq driver.

One: as you have already noticed - it fails to register when
cpumask_present != cpumask_online.

Second: it will mix the sources of the freq scale if not all CPUs within the
policy have AMUs enabled/valid. This is due to the fact that at the time of
registering the driver and initializing the FIE support policy->cpus ==
policy->related_cpus. Assuming scenario when there are two CPUs within the
policy, one being offline and missing valid AMU counters,
the topology_set_scale_freq_source from cppc cpufreq driver will register
the tick handler for both CPUs, whereas AMU support will (rightly so) register
only for the firs one. When the second CPU comes online, the mismatch will be
detected and the arch callback will get cleared for the first CPU, but the
second one will remain unchanged.

That said, I do not think any of those issues is a blocker for this series.
But both would need fixing.

---
BR
Beata


> ---
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 5d824435b26b..2f286a1b0b02 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -33,6 +33,7 @@ MODULE_AUTHOR("Paul Diefenbaugh");
>  MODULE_DESCRIPTION("ACPI Processor Driver");
>  MODULE_LICENSE("GPL");
>  
> +static int acpi_processor_start(struct device *dev);
>  static int acpi_processor_stop(struct device *dev);
>  
>  static const struct acpi_device_id processor_device_ids[] = {
> @@ -46,6 +47,7 @@ static struct device_driver acpi_processor_driver = {
>  	.name = "processor",
>  	.bus = &cpu_subsys,
>  	.acpi_match_table = processor_device_ids,
> +	.probe = acpi_processor_start,
>  	.remove = acpi_processor_stop,
>  };
>  
> @@ -191,6 +193,21 @@ static int __acpi_processor_start(struct acpi_device *device)
>  	return result;
>  }
>  
> +static int acpi_processor_start(struct device *dev)
> +{
> +	struct acpi_device *device = ACPI_COMPANION(dev);
> +	int ret;
> +
> +	if (!device)
> +		return -ENODEV;
> +
> +	/* Protect against concurrent CPU hotplug operations */
> +	cpu_hotplug_disable();
> +	ret = __acpi_processor_start(device);
> +	cpu_hotplug_enable();
> +	return ret;
> +}
> +
>  static int acpi_processor_stop(struct device *dev)
>  {
>  	struct acpi_device *device = ACPI_COMPANION(dev);
> @@ -264,9 +281,9 @@ static int __init acpi_processor_driver_init(void)
>  
>  	acpi_processor_register_idle_driver();
>  
> -	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
> -				   "acpi/cpu-drv:online",
> -				   acpi_soft_cpu_online, NULL);
> +	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
> +					   "acpi/cpu-drv:online",
> +					   acpi_soft_cpu_online, NULL);
>  	if (result < 0)
>  		goto err;
>  	hp_online = result;
> 
> > 
> > ---
> > BR
> > Beata
> > On Wed, Nov 19, 2025 at 04:13:53PM +0800, Lifeng Zheng wrote:
> >> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
> >> even though they're eligible.
> >>
> >>
> > 
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[zhenglifeng (A)]

On 2025/12/2 23:31, Beata Michalska wrote:
> On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
>> On 2025/12/1 23:27, Beata Michalska wrote:
>>> Hi,
>>>
>>> Apologies for the delay in reviewing this - currently in progress....
>>> Out of curiosity: what's the cpufreq driver used for testing this series ?
>>
>> I used cppc_cpufreq for testing this. But with some modifications in
>> processor_driver.c, or you'll find that the driver will fail to load with
>> maxcpus set. The modification below is only a temporary solution. I'm still
>> working on that.
>>
> Right, so overall the implementation looks good - thanks for that.
> There are two issues though with the cppc cpufreq driver.
> 
> One: as you have already noticed - it fails to register when
> cpumask_present != cpumask_online.
> 
> Second: it will mix the sources of the freq scale if not all CPUs within the
> policy have AMUs enabled/valid. This is due to the fact that at the time of
> registering the driver and initializing the FIE support policy->cpus ==
> policy->related_cpus. Assuming scenario when there are two CPUs within the
> policy, one being offline and missing valid AMU counters,
> the topology_set_scale_freq_source from cppc cpufreq driver will register
> the tick handler for both CPUs, whereas AMU support will (rightly so) register
> only for the firs one. When the second CPU comes online, the mismatch will be
> detected and the arch callback will get cleared for the first CPU, but the
> second one will remain unchanged.

Thanks for pointing them out. I'll try to fix these issues after this series.

> 
> That said, I do not think any of those issues is a blocker for this series.
> But both would need fixing.
> 
> ---
> BR
> Beata
> 
> 
>> ---
>> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
>> index 5d824435b26b..2f286a1b0b02 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -33,6 +33,7 @@ MODULE_AUTHOR("Paul Diefenbaugh");
>>  MODULE_DESCRIPTION("ACPI Processor Driver");
>>  MODULE_LICENSE("GPL");
>>  
>> +static int acpi_processor_start(struct device *dev);
>>  static int acpi_processor_stop(struct device *dev);
>>  
>>  static const struct acpi_device_id processor_device_ids[] = {
>> @@ -46,6 +47,7 @@ static struct device_driver acpi_processor_driver = {
>>  	.name = "processor",
>>  	.bus = &cpu_subsys,
>>  	.acpi_match_table = processor_device_ids,
>> +	.probe = acpi_processor_start,
>>  	.remove = acpi_processor_stop,
>>  };
>>  
>> @@ -191,6 +193,21 @@ static int __acpi_processor_start(struct acpi_device *device)
>>  	return result;
>>  }
>>  
>> +static int acpi_processor_start(struct device *dev)
>> +{
>> +	struct acpi_device *device = ACPI_COMPANION(dev);
>> +	int ret;
>> +
>> +	if (!device)
>> +		return -ENODEV;
>> +
>> +	/* Protect against concurrent CPU hotplug operations */
>> +	cpu_hotplug_disable();
>> +	ret = __acpi_processor_start(device);
>> +	cpu_hotplug_enable();
>> +	return ret;
>> +}
>> +
>>  static int acpi_processor_stop(struct device *dev)
>>  {
>>  	struct acpi_device *device = ACPI_COMPANION(dev);
>> @@ -264,9 +281,9 @@ static int __init acpi_processor_driver_init(void)
>>  
>>  	acpi_processor_register_idle_driver();
>>  
>> -	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
>> -				   "acpi/cpu-drv:online",
>> -				   acpi_soft_cpu_online, NULL);
>> +	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
>> +					   "acpi/cpu-drv:online",
>> +					   acpi_soft_cpu_online, NULL);
>>  	if (result < 0)
>>  		goto err;
>>  	hp_online = result;
>>
>>>
>>> ---
>>> BR
>>> Beata
>>> On Wed, Nov 19, 2025 at 04:13:53PM +0800, Lifeng Zheng wrote:
>>>> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
>>>> even though they're eligible.
>>>>
>>>>
>>>
>>
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[zhenglifeng (A)]

On 2025/12/2 23:31, Beata Michalska wrote:
> On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
>> On 2025/12/1 23:27, Beata Michalska wrote:
>>> Hi,
>>>
>>> Apologies for the delay in reviewing this - currently in progress....
>>> Out of curiosity: what's the cpufreq driver used for testing this series ?
>>
>> I used cppc_cpufreq for testing this. But with some modifications in
>> processor_driver.c, or you'll find that the driver will fail to load with
>> maxcpus set. The modification below is only a temporary solution. I'm still
>> working on that.
>>
> Right, so overall the implementation looks good - thanks for that.
> There are two issues though with the cppc cpufreq driver.
> 
> One: as you have already noticed - it fails to register when
> cpumask_present != cpumask_online.
> 
> Second: it will mix the sources of the freq scale if not all CPUs within the
> policy have AMUs enabled/valid. This is due to the fact that at the time of
> registering the driver and initializing the FIE support policy->cpus ==
> policy->related_cpus. Assuming scenario when there are two CPUs within the
> policy, one being offline and missing valid AMU counters,
> the topology_set_scale_freq_source from cppc cpufreq driver will register
> the tick handler for both CPUs, whereas AMU support will (rightly so) register
> only for the firs one. When the second CPU comes online, the mismatch will be
> detected and the arch callback will get cleared for the first CPU, but the
> second one will remain unchanged.
> 
> That said, I do not think any of those issues is a blocker for this series.
> But both would need fixing.

Hi Catalin,

I believe Beata is OK with this series. So I think we can move ahead with it
now.

Thanks.

> 
> ---
> BR
> Beata
> 
> 
>> ---
>> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
>> index 5d824435b26b..2f286a1b0b02 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -33,6 +33,7 @@ MODULE_AUTHOR("Paul Diefenbaugh");
>>  MODULE_DESCRIPTION("ACPI Processor Driver");
>>  MODULE_LICENSE("GPL");
>>  
>> +static int acpi_processor_start(struct device *dev);
>>  static int acpi_processor_stop(struct device *dev);
>>  
>>  static const struct acpi_device_id processor_device_ids[] = {
>> @@ -46,6 +47,7 @@ static struct device_driver acpi_processor_driver = {
>>  	.name = "processor",
>>  	.bus = &cpu_subsys,
>>  	.acpi_match_table = processor_device_ids,
>> +	.probe = acpi_processor_start,
>>  	.remove = acpi_processor_stop,
>>  };
>>  
>> @@ -191,6 +193,21 @@ static int __acpi_processor_start(struct acpi_device *device)
>>  	return result;
>>  }
>>  
>> +static int acpi_processor_start(struct device *dev)
>> +{
>> +	struct acpi_device *device = ACPI_COMPANION(dev);
>> +	int ret;
>> +
>> +	if (!device)
>> +		return -ENODEV;
>> +
>> +	/* Protect against concurrent CPU hotplug operations */
>> +	cpu_hotplug_disable();
>> +	ret = __acpi_processor_start(device);
>> +	cpu_hotplug_enable();
>> +	return ret;
>> +}
>> +
>>  static int acpi_processor_stop(struct device *dev)
>>  {
>>  	struct acpi_device *device = ACPI_COMPANION(dev);
>> @@ -264,9 +281,9 @@ static int __init acpi_processor_driver_init(void)
>>  
>>  	acpi_processor_register_idle_driver();
>>  
>> -	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
>> -				   "acpi/cpu-drv:online",
>> -				   acpi_soft_cpu_online, NULL);
>> +	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
>> +					   "acpi/cpu-drv:online",
>> +					   acpi_soft_cpu_online, NULL);
>>  	if (result < 0)
>>  		goto err;
>>  	hp_online = result;
>>
>>>
>>> ---
>>> BR
>>> Beata
>>> On Wed, Nov 19, 2025 at 04:13:53PM +0800, Lifeng Zheng wrote:
>>>> Solve a problem that causes CPUs Setup AMU FIE failed in a corner case,
>>>> even though they're eligible.
>>>>
>>>>
>>>
>>
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Will Deacon]

On Fri, Dec 12, 2025 at 05:27:09PM +0800, zhenglifeng (A) wrote:
> On 2025/12/2 23:31, Beata Michalska wrote:
> > On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
> >> On 2025/12/1 23:27, Beata Michalska wrote:
> >>> Hi,
> >>>
> >>> Apologies for the delay in reviewing this - currently in progress....
> >>> Out of curiosity: what's the cpufreq driver used for testing this series ?
> >>
> >> I used cppc_cpufreq for testing this. But with some modifications in
> >> processor_driver.c, or you'll find that the driver will fail to load with
> >> maxcpus set. The modification below is only a temporary solution. I'm still
> >> working on that.
> >>
> > Right, so overall the implementation looks good - thanks for that.
> > There are two issues though with the cppc cpufreq driver.
> > 
> > One: as you have already noticed - it fails to register when
> > cpumask_present != cpumask_online.
> > 
> > Second: it will mix the sources of the freq scale if not all CPUs within the
> > policy have AMUs enabled/valid. This is due to the fact that at the time of
> > registering the driver and initializing the FIE support policy->cpus ==
> > policy->related_cpus. Assuming scenario when there are two CPUs within the
> > policy, one being offline and missing valid AMU counters,
> > the topology_set_scale_freq_source from cppc cpufreq driver will register
> > the tick handler for both CPUs, whereas AMU support will (rightly so) register
> > only for the firs one. When the second CPU comes online, the mismatch will be
> > detected and the arch callback will get cleared for the first CPU, but the
> > second one will remain unchanged.
> > 
> > That said, I do not think any of those issues is a blocker for this series.
> > But both would need fixing.
> 
> I believe Beata is OK with this series. So I think we can move ahead with it
> now.

Please repost at -rc1. It would be nice to have an Ack from Beata...

Will

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[zhenglifeng (A)]

On 2025/12/13 4:08, Will Deacon wrote:
> On Fri, Dec 12, 2025 at 05:27:09PM +0800, zhenglifeng (A) wrote:
>> On 2025/12/2 23:31, Beata Michalska wrote:
>>> On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
>>>> On 2025/12/1 23:27, Beata Michalska wrote:
>>>>> Hi,
>>>>>
>>>>> Apologies for the delay in reviewing this - currently in progress....
>>>>> Out of curiosity: what's the cpufreq driver used for testing this series ?
>>>>
>>>> I used cppc_cpufreq for testing this. But with some modifications in
>>>> processor_driver.c, or you'll find that the driver will fail to load with
>>>> maxcpus set. The modification below is only a temporary solution. I'm still
>>>> working on that.
>>>>
>>> Right, so overall the implementation looks good - thanks for that.
>>> There are two issues though with the cppc cpufreq driver.
>>>
>>> One: as you have already noticed - it fails to register when
>>> cpumask_present != cpumask_online.
>>>
>>> Second: it will mix the sources of the freq scale if not all CPUs within the
>>> policy have AMUs enabled/valid. This is due to the fact that at the time of
>>> registering the driver and initializing the FIE support policy->cpus ==
>>> policy->related_cpus. Assuming scenario when there are two CPUs within the
>>> policy, one being offline and missing valid AMU counters,
>>> the topology_set_scale_freq_source from cppc cpufreq driver will register
>>> the tick handler for both CPUs, whereas AMU support will (rightly so) register
>>> only for the firs one. When the second CPU comes online, the mismatch will be
>>> detected and the arch callback will get cleared for the first CPU, but the
>>> second one will remain unchanged.
>>>
>>> That said, I do not think any of those issues is a blocker for this series.
>>> But both would need fixing.
>>
>> I believe Beata is OK with this series. So I think we can move ahead with it
>> now.
> 
> Please repost at -rc1. It would be nice to have an Ack from Beata...

Hi Beata,

It would be nice if you could give this patch an Ack.

Thanks.

> 
> Will
> 

Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

[Beata Michalska]

On Sat, Dec 20, 2025 at 05:09:52PM +0800, zhenglifeng (A) wrote:
> On 2025/12/13 4:08, Will Deacon wrote:
> > On Fri, Dec 12, 2025 at 05:27:09PM +0800, zhenglifeng (A) wrote:
> >> On 2025/12/2 23:31, Beata Michalska wrote:
> >>> On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
> >>>> On 2025/12/1 23:27, Beata Michalska wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Apologies for the delay in reviewing this - currently in progress....
> >>>>> Out of curiosity: what's the cpufreq driver used for testing this series ?
> >>>>
> >>>> I used cppc_cpufreq for testing this. But with some modifications in
> >>>> processor_driver.c, or you'll find that the driver will fail to load with
> >>>> maxcpus set. The modification below is only a temporary solution. I'm still
> >>>> working on that.
> >>>>
> >>> Right, so overall the implementation looks good - thanks for that.
> >>> There are two issues though with the cppc cpufreq driver.
> >>>
> >>> One: as you have already noticed - it fails to register when
> >>> cpumask_present != cpumask_online.
> >>>
> >>> Second: it will mix the sources of the freq scale if not all CPUs within the
> >>> policy have AMUs enabled/valid. This is due to the fact that at the time of
> >>> registering the driver and initializing the FIE support policy->cpus ==
> >>> policy->related_cpus. Assuming scenario when there are two CPUs within the
> >>> policy, one being offline and missing valid AMU counters,
> >>> the topology_set_scale_freq_source from cppc cpufreq driver will register
> >>> the tick handler for both CPUs, whereas AMU support will (rightly so) register
> >>> only for the firs one. When the second CPU comes online, the mismatch will be
> >>> detected and the arch callback will get cleared for the first CPU, but the
> >>> second one will remain unchanged.
> >>>
> >>> That said, I do not think any of those issues is a blocker for this series.
> >>> But both would need fixing.
> >>
> >> I believe Beata is OK with this series. So I think we can move ahead with it
> >> now.
> > 
> > Please repost at -rc1. It would be nice to have an Ack from Beata...
> 
> Hi Beata,
> 
> It would be nice if you could give this patch an Ack.
> 
> Thanks.
> 
Apologies, 've been away.

Acked-by: Beata Michalska <beata.michalska@arm.com>

---
BR
Beata
> > 
> > Will
> > 
>