On Fri, Dec 12, 2025 at 05:27:09PM +0800, zhenglifeng (A) wrote:

On 2025/12/2 23:31, Beata Michalska wrote:

quoted

On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:

quoted

On 2025/12/1 23:27, Beata Michalska wrote:

quoted

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