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

[Will Deacon <will@kernel.org>]

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