All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>, <linux-pm@vger.kernel.org>,
	<loongarch@lists.linux.dev>, <linux-acpi@vger.kernel.org>,
	<linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	Miguel Luis <miguel.luis@oracle.com>,
	James Morse <james.morse@arm.com>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"Gavin Shan" <gshan@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <linuxarm@huawei.com>,
	<justin.he@arm.com>, <jianyong.wu@arm.com>
Subject: Re: [PATCH v9 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier
Date: Wed, 8 May 2024 09:44:11 +0100	[thread overview]
Message-ID: <20240508094411.00001b92@Huawei.com> (raw)
In-Reply-To: <CAJZ5v0g-Aenoj5H+pNPtoqTgV5U7K5RGNjdOnqobqxkyL5NMVQ@mail.gmail.com>

On Tue, 7 May 2024 21:04:26 +0200
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Tue, Apr 30, 2024 at 4:27 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > Make the per_cpu(processors, cpu) entries available earlier so that
> > they are available in arch_register_cpu() as ARM64 will need access
> > to the acpi_handle to distinguish between acpi_processor_add()
> > and earlier registration attempts (which will fail as _STA cannot
> > be checked).
> >
> > Reorder the remove flow to clear this per_cpu() after
> > arch_unregister_cpu() has completed, allowing it to be used in
> > there as well.
> >
> > Note that on x86 for the CPU hotplug case, the pr->id prior to
> > acpi_map_cpu() may be invalid. Thus the per_cpu() structures
> > must be initialized after that call or after checking the ID
> > is valid (not hotplug path).
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>  
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> One nit below.

Thanks.  Given timing, this is looking like 6.11 material.
I'll tidy this up and post a v10 in a couple of weeks (so around
rc1 time). Maybe we'll pick up some more tags for the ARM
specific bits in the meantime.

Thanks for all your help!

Jonathan

> 
> > ---
> > v9: Add back a blank line accidentally removed in code move.
> >     Fix up error returns so that the new cleanup in processor_add()
> >     is triggered on detection of the bios bug.
> >     Combined with the previous 2 patches, should solve the leak
> >     that Gavin identified.
> > ---
> >  drivers/acpi/acpi_processor.c | 80 +++++++++++++++++++++--------------
> >  1 file changed, 49 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 16e36e55a560..4a79b42d649e 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
> >  #endif /* CONFIG_X86 */
> >
> >  /* Initialization */
> > +static DEFINE_PER_CPU(void *, processor_device_array);
> > +
> > +static bool acpi_processor_set_per_cpu(struct acpi_processor *pr,
> > +                                      struct acpi_device *device)
> > +{
> > +       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);
> > +               return false;
> > +       }
> > +       /*
> > +        * 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;
> > +
> > +       return true;
> > +}
> > +
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > -static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> > +static int acpi_processor_hotadd_init(struct acpi_processor *pr,
> > +                                     struct acpi_device *device)
> >  {
> >         int ret;
> >
> > @@ -198,8 +228,16 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> >         if (ret)
> >                 goto out;
> >
> > +       if (!acpi_processor_set_per_cpu(pr, device)) {
> > +               ret = -EINVAL;
> > +               acpi_unmap_cpu(pr->id);
> > +               goto out;
> > +       }
> > +
> >         ret = arch_register_cpu(pr->id);
> >         if (ret) {
> > +               /* Leave the processor device array in place to detect buggy bios */
> > +               per_cpu(processors, pr->id) = NULL;
> >                 acpi_unmap_cpu(pr->id);
> >                 goto out;
> >         }
> > @@ -217,7 +255,8 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> >         return ret;
> >  }
> >  #else
> > -static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
> > +static inline int acpi_processor_hotadd_init(struct acpi_processor *pr,
> > +                                            struct acpi_device *device)
> >  {
> >         return -ENODEV;
> >  }
> > @@ -316,10 +355,13 @@ 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);
> > +               int ret = acpi_processor_hotadd_init(pr, device);
> >
> >                 if (ret)
> >                         return ret;
> > +       } else {
> > +               if (!acpi_processor_set_per_cpu(pr, device))
> > +                       return -EINVAL;
> >         }  
> 
> This looks a bit odd.
> 
> I would make acpi_processor_set_per_cpu() return 0 on success and
> -EINVAL on failure and the above would become
> 
> if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id))
>          ret = acpi_processor_hotadd_init(pr, device);
> else
>         ret = acpi_processor_set_per_cpu(pr, device);
> 
> if (ret)
>         return ret;
> 
> (and of course ret needs to be defined at the beginning of the function).
> 
> >
> >         /*
> > @@ -365,8 +407,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 +435,6 @@ static int acpi_processor_add(struct acpi_device *device,
> >         if (result) /* Processor is not physically present or unavailable */
> >                 goto err_clear_driver_data;
> >
> > -       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_clear_driver_data;
> > -       }
> > -       /*
> > -        * 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;
> > -
> >         dev = get_cpu_device(pr->id);
> >         if (!dev) {
> >                 result = -ENODEV;
> > @@ -470,10 +488,6 @@ static void acpi_processor_remove(struct acpi_device *device)
> >         device_release_driver(pr->dev);
> >         acpi_unbind_one(pr->dev);
> >
> > -       /* Clean up. */
> > -       per_cpu(processor_device_array, pr->id) = NULL;
> > -       per_cpu(processors, pr->id) = NULL;
> > -
> >         cpu_maps_update_begin();
> >         cpus_write_lock();
> >
> > @@ -481,6 +495,10 @@ static void acpi_processor_remove(struct acpi_device *device)
> >         arch_unregister_cpu(pr->id);
> >         acpi_unmap_cpu(pr->id);
> >
> > +       /* Clean up. */
> > +       per_cpu(processor_device_array, pr->id) = NULL;
> > +       per_cpu(processors, pr->id) = NULL;
> > +
> >         cpus_write_unlock();
> >         cpu_maps_update_done();
> >
> > --
> > 2.39.2
> >  


WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>, <linux-pm@vger.kernel.org>,
	<loongarch@lists.linux.dev>, <linux-acpi@vger.kernel.org>,
	<linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	Miguel Luis <miguel.luis@oracle.com>,
	James Morse <james.morse@arm.com>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"Gavin Shan" <gshan@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <linuxarm@huawei.com>,
	<justin.he@arm.com>, <jianyong.wu@arm.com>
Subject: Re: [PATCH v9 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier
Date: Wed, 8 May 2024 09:44:11 +0100	[thread overview]
Message-ID: <20240508094411.00001b92@Huawei.com> (raw)
In-Reply-To: <CAJZ5v0g-Aenoj5H+pNPtoqTgV5U7K5RGNjdOnqobqxkyL5NMVQ@mail.gmail.com>

On Tue, 7 May 2024 21:04:26 +0200
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Tue, Apr 30, 2024 at 4:27 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > Make the per_cpu(processors, cpu) entries available earlier so that
> > they are available in arch_register_cpu() as ARM64 will need access
> > to the acpi_handle to distinguish between acpi_processor_add()
> > and earlier registration attempts (which will fail as _STA cannot
> > be checked).
> >
> > Reorder the remove flow to clear this per_cpu() after
> > arch_unregister_cpu() has completed, allowing it to be used in
> > there as well.
> >
> > Note that on x86 for the CPU hotplug case, the pr->id prior to
> > acpi_map_cpu() may be invalid. Thus the per_cpu() structures
> > must be initialized after that call or after checking the ID
> > is valid (not hotplug path).
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>  
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> One nit below.

Thanks.  Given timing, this is looking like 6.11 material.
I'll tidy this up and post a v10 in a couple of weeks (so around
rc1 time). Maybe we'll pick up some more tags for the ARM
specific bits in the meantime.

Thanks for all your help!

Jonathan

> 
> > ---
> > v9: Add back a blank line accidentally removed in code move.
> >     Fix up error returns so that the new cleanup in processor_add()
> >     is triggered on detection of the bios bug.
> >     Combined with the previous 2 patches, should solve the leak
> >     that Gavin identified.
> > ---
> >  drivers/acpi/acpi_processor.c | 80 +++++++++++++++++++++--------------
> >  1 file changed, 49 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 16e36e55a560..4a79b42d649e 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
> >  #endif /* CONFIG_X86 */
> >
> >  /* Initialization */
> > +static DEFINE_PER_CPU(void *, processor_device_array);
> > +
> > +static bool acpi_processor_set_per_cpu(struct acpi_processor *pr,
> > +                                      struct acpi_device *device)
> > +{
> > +       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);
> > +               return false;
> > +       }
> > +       /*
> > +        * 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;
> > +
> > +       return true;
> > +}
> > +
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > -static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> > +static int acpi_processor_hotadd_init(struct acpi_processor *pr,
> > +                                     struct acpi_device *device)
> >  {
> >         int ret;
> >
> > @@ -198,8 +228,16 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> >         if (ret)
> >                 goto out;
> >
> > +       if (!acpi_processor_set_per_cpu(pr, device)) {
> > +               ret = -EINVAL;
> > +               acpi_unmap_cpu(pr->id);
> > +               goto out;
> > +       }
> > +
> >         ret = arch_register_cpu(pr->id);
> >         if (ret) {
> > +               /* Leave the processor device array in place to detect buggy bios */
> > +               per_cpu(processors, pr->id) = NULL;
> >                 acpi_unmap_cpu(pr->id);
> >                 goto out;
> >         }
> > @@ -217,7 +255,8 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> >         return ret;
> >  }
> >  #else
> > -static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
> > +static inline int acpi_processor_hotadd_init(struct acpi_processor *pr,
> > +                                            struct acpi_device *device)
> >  {
> >         return -ENODEV;
> >  }
> > @@ -316,10 +355,13 @@ 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);
> > +               int ret = acpi_processor_hotadd_init(pr, device);
> >
> >                 if (ret)
> >                         return ret;
> > +       } else {
> > +               if (!acpi_processor_set_per_cpu(pr, device))
> > +                       return -EINVAL;
> >         }  
> 
> This looks a bit odd.
> 
> I would make acpi_processor_set_per_cpu() return 0 on success and
> -EINVAL on failure and the above would become
> 
> if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id))
>          ret = acpi_processor_hotadd_init(pr, device);
> else
>         ret = acpi_processor_set_per_cpu(pr, device);
> 
> if (ret)
>         return ret;
> 
> (and of course ret needs to be defined at the beginning of the function).
> 
> >
> >         /*
> > @@ -365,8 +407,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 +435,6 @@ static int acpi_processor_add(struct acpi_device *device,
> >         if (result) /* Processor is not physically present or unavailable */
> >                 goto err_clear_driver_data;
> >
> > -       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_clear_driver_data;
> > -       }
> > -       /*
> > -        * 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;
> > -
> >         dev = get_cpu_device(pr->id);
> >         if (!dev) {
> >                 result = -ENODEV;
> > @@ -470,10 +488,6 @@ static void acpi_processor_remove(struct acpi_device *device)
> >         device_release_driver(pr->dev);
> >         acpi_unbind_one(pr->dev);
> >
> > -       /* Clean up. */
> > -       per_cpu(processor_device_array, pr->id) = NULL;
> > -       per_cpu(processors, pr->id) = NULL;
> > -
> >         cpu_maps_update_begin();
> >         cpus_write_lock();
> >
> > @@ -481,6 +495,10 @@ static void acpi_processor_remove(struct acpi_device *device)
> >         arch_unregister_cpu(pr->id);
> >         acpi_unmap_cpu(pr->id);
> >
> > +       /* Clean up. */
> > +       per_cpu(processor_device_array, pr->id) = NULL;
> > +       per_cpu(processors, pr->id) = NULL;
> > +
> >         cpus_write_unlock();
> >         cpu_maps_update_done();
> >
> > --
> > 2.39.2
> >  


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-08  8:44 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-30 14:24 [PATCH v9 00/19] ACPI/arm64: add support for virtual cpu hotplug Jonathan Cameron
2024-04-30 14:24 ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 01/19] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-02 12:10   ` Miguel Luis
2024-05-02 12:10     ` Miguel Luis
2024-04-30 14:24 ` [PATCH v9 02/19] cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 03/19] ACPI: processor: Drop duplicated check on _STA (enabled + present) Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 04/19] ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add() Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 10:18   ` Gavin Shan
2024-05-01 10:18     ` Gavin Shan
2024-05-07 18:55   ` Rafael J. Wysocki
2024-05-07 18:55     ` Rafael J. Wysocki
2024-04-30 14:24 ` [PATCH v9 05/19] ACPI: processor: Fix memory leaks in error paths of processor_add() Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 10:19   ` Gavin Shan
2024-05-01 10:19     ` Gavin Shan
2024-05-07 18:57   ` Rafael J. Wysocki
2024-05-07 18:57     ` Rafael J. Wysocki
2024-04-30 14:24 ` [PATCH v9 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 10:33   ` Gavin Shan
2024-05-01 10:33     ` Gavin Shan
2024-05-07 19:04   ` Rafael J. Wysocki
2024-05-07 19:04     ` Rafael J. Wysocki
2024-05-08  8:44     ` Jonathan Cameron [this message]
2024-05-08  8:44       ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 07/19] ACPI: processor: Add acpi_get_processor_handle() helper Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-07 19:05   ` Rafael J. Wysocki
2024-05-07 19:05     ` Rafael J. Wysocki
2024-04-30 14:24 ` [PATCH v9 08/19] ACPI: processor: Register deferred CPUs from acpi_processor_get_info() Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 09/19] ACPI: scan: switch to flags for acpi_scan_check_and_detach() Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 10/19] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 11/19] arm64: acpi: Move get_cpu_for_acpi_id() to a header Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 12/19] arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 11:10   ` Gavin Shan
2024-05-01 11:10     ` Gavin Shan
2024-04-30 14:24 ` [PATCH v9 13/19] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 14/19] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 15/19] arm64: psci: Ignore DENIED CPUs Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 16/19] arm64: arch_register_cpu() variant to check if an ACPI handle is now available Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-04-30 14:24 ` [PATCH v9 17/19] arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 11:13   ` Gavin Shan
2024-05-01 11:13     ` Gavin Shan
2024-04-30 14:24 ` [PATCH v9 18/19] arm64: document virtual CPU hotplug's expectations Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 11:32   ` Gavin Shan
2024-05-01 11:32     ` Gavin Shan
2024-04-30 14:24 ` [PATCH v9 19/19] cpumask: Add enabled cpumask for present CPUs that can be brought online Jonathan Cameron
2024-04-30 14:24   ` Jonathan Cameron
2024-05-01 11:14   ` Gavin Shan
2024-05-01 11:14     ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240508094411.00001b92@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gshan@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jean-philippe@linaro.org \
    --cc=jianyong.wu@arm.com \
    --cc=justin.he@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxarm@huawei.com \
    --cc=loongarch@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=miguel.luis@oracle.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=salil.mehta@huawei.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.