[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240424181857.00000e0f@Huawei.com>
Date: Wed, 24 Apr 2024 18:18:57 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Hanjun Guo <guohanjun@...wei.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
<peterz@...radead.org>, <linux-pm@...r.kernel.org>,
<loongarch@...ts.linux.dev>, <linux-acpi@...r.kernel.org>,
<linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <kvmarm@...ts.linux.dev>,
<x86@...nel.org>, Russell King <linux@...linux.org.uk>, "Rafael J . Wysocki"
<rafael@...nel.org>, Miguel Luis <miguel.luis@...cle.com>, "James Morse"
<james.morse@....com>, Salil Mehta <salil.mehta@...wei.com>, Jean-Philippe
Brucker <jean-philippe@...aro.org>, Catalin Marinas
<catalin.marinas@....com>, Will Deacon <will@...nel.org>, Ingo Molnar
<mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
<dave.hansen@...ux.intel.com>, <linuxarm@...wei.com>, <justin.he@....com>,
<jianyong.wu@....com>
Subject: Re: [PATCH v7 04/16] ACPI: processor: Move checks and availability
of acpi_processor earlier
On Tue, 23 Apr 2024 19:53:34 +0800
Hanjun Guo <guohanjun@...wei.com> wrote:
> > @@ -232,6 +263,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
> > acpi_status status = AE_OK;
> > static int cpu0_initialized;
> > unsigned long long value;
> > + int ret;
> >
> > acpi_processor_errata();
> >
> > @@ -316,10 +348,12 @@ static int acpi_processor_get_info(struct acpi_device *device)
> > * because cpuid <-> apicid mapping is persistent now.
> > */
> > if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
> > - int ret = acpi_processor_hotadd_init(pr);
> > + ret = acpi_processor_hotadd_init(pr, device);
> >
> > if (ret)
> > - return ret;
> > + goto err;
> > + } else {
> > + acpi_processor_set_per_cpu(pr, device);
> > }
> >
> > /*
> > @@ -357,6 +391,10 @@ static int acpi_processor_get_info(struct acpi_device *device)
> > arch_fix_phys_package_id(pr->id, value);
> >
> > return 0;
> > +
> > +err:
> > + per_cpu(processors, pr->id) = NULL;
>
> ...
>
> > + return ret;
> > }
> >
> > /*
> > @@ -365,8 +403,6 @@ static int acpi_processor_get_info(struct acpi_device *device)
> > * (cpu_data(cpu)) values, like CPU feature flags, family, model, etc.
> > * Such things have to be put in and set up by the processor driver's .probe().
> > */
> > -static DEFINE_PER_CPU(void *, processor_device_array);
> > -
> > static int acpi_processor_add(struct acpi_device *device,
> > const struct acpi_device_id *id)
> > {
> > @@ -395,28 +431,6 @@ static int acpi_processor_add(struct acpi_device *device,
> > if (result) /* Processor is not physically present or unavailable */
> > return 0;
> >
> > - BUG_ON(pr->id >= nr_cpu_ids);
> > -
> > - /*
> > - * Buggy BIOS check.
> > - * ACPI id of processors can be reported wrongly by the BIOS.
> > - * Don't trust it blindly
> > - */
> > - if (per_cpu(processor_device_array, pr->id) != NULL &&
> > - per_cpu(processor_device_array, pr->id) != device) {
> > - dev_warn(&device->dev,
> > - "BIOS reported wrong ACPI id %d for the processor\n",
> > - pr->id);
> > - /* Give up, but do not abort the namespace scan. */
> > - goto err;
> > - }
> > - /*
> > - * processor_device_array is not cleared on errors to allow buggy BIOS
> > - * checks.
> > - */
> > - per_cpu(processor_device_array, pr->id) = device;
> > - per_cpu(processors, pr->id) = pr;
>
> Nit: seems we need to remove the duplicated
> per_cpu(processors, pr->id) = NULL; in acpi_processor_add():
>
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -446,7 +446,6 @@ static int acpi_processor_add(struct acpi_device
> *device,
> err:
> free_cpumask_var(pr->throttling.shared_cpu_map);
> device->driver_data = NULL;
> - per_cpu(processors, pr->id) = NULL;
I don't follow. This path is used if processor_get_info() succeeded and
we later fail. I don't see where the the duplication is?
> err_free_pr:
> kfree(pr);
> return result;
>
> Thanks
> Hanjun
Powered by blists - more mailing lists