[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