[PATCH 3/3] arm_pmu: rework ACPI probing

Mark Rutland mark.rutland at arm.com
Tue Nov 8 01:42:28 PST 2022


On Mon, Nov 07, 2022 at 07:10:18PM +0000, Will Deacon wrote:
> On Fri, Sep 30, 2022 at 12:18:44PM +0100, Mark Rutland wrote:
> > @@ -320,13 +320,26 @@ int arm_pmu_acpi_probe(armpmu_init_fn init_fn)
> >  	 * For the moment, as with the platform/DT case, we need at least one
> >  	 * of a PMU's CPUs to be online at probe time.
> >  	 */
> > -	for_each_possible_cpu(cpu) {
> > +	for_each_online_cpu(cpu) {
> >  		struct arm_pmu *pmu = per_cpu(probed_pmus, cpu);
> > +		unsigned long cpuid;
> >  		char *base_name;
> >  
> > -		if (!pmu || pmu->name)
> > +		/* If we've already probed this CPU, we have nothing to do */
> > +		if (pmu)
> >  			continue;
> >  
> > +		pmu = armpmu_alloc();
> > +		if (!pmu) {
> > +			pr_warn("Unable to allocate PMU for CPU%d\n",
> > +				cpu);
> > +		}
> > +
> > +		cpuid = per_cpu(cpu_data, cpu).reg_midr;
> > +		pmu->acpi_cpuid = cpuid;
> 
> I've queued this, but if armpmu_alloc() fails we now deference NULL here
> whereas we should probably propagate the error.

Whoops; that was meant to return -ENOMEM, as with the other allocation failure.
 
> Please can you send a fix on top of for-next/acpi?

Done:

  https://lore.kernel.org/r/20221108093725.1239563-1-mark.rutland@arm.com

Thanks,
Mark.



More information about the linux-arm-kernel mailing list