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: Russell King <rmk+kernel@armlinux.org.uk>,
	<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>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Mon, 22 Jan 2024 17:44:49 +0000	[thread overview]
Message-ID: <20240122174449.00002f78@Huawei.com> (raw)
In-Reply-To: <CAJZ5v0je=-oVnSumZs=dzcyVuVUeVeTgO7yOnjGg1igyrS7EHQ@mail.gmail.com>

On Mon, 18 Dec 2023 21:30:50 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Wed, Dec 13, 2023 at 1:49 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > From: James Morse <james.morse@arm.com>
> >
> > To allow ACPI to skip the call to arch_register_cpu() when the _STA
> > value indicates the CPU can't be brought online right now, move the
> > arch_register_cpu() call into acpi_processor_get_info().  
> 
> This kind of looks backwards to me and has a potential to become
> super-confusing.
> 
> I would instead add a way for the generic code to ask the platform
> firmware whether or not the given CPU is enabled and so it can be
> registered.

Hi Rafael,

The ACPI interpreter isn't up at this stage so we'd need to pull that
forwards. I'm not sure if we can pull the interpreter init early enough.

Perhaps pushing the registration back in all cases is the way to go?
Given the acpi interpretter is initialized via subsys_initcall() it would
need to be after that - I tried pushing cpu_dev_register_generic()
immediately after acpi_bus_init() and that seems fine.
We can't leave the rest of cpu_dev_init() that late because a bunch
of other stuff relies on it (CPU freq blows up first as a core_init()
on my setup).

So to make this work we need it to always move the registration later
than the necessary infrastructure, perhaps to subsys_initcall_sync()
as is done for missing CPUs (we'd need to combine the two given that
needs to run after this, or potentially just stop checking for acpi_disabled
and don't taint the kernel!).  I think this is probably the most consistent
option on basis it at least moves the registration to the same point
whatever is going on and can easily use the arch callback you suggest
to hide away the logic on deciding if a CPU is there or not.

What do you think is the best way to do this?


> 
> > Systems can still be booted with 'acpi=off', or not include ano
> > ACPI description at all. For these, the CPUs continue to be
> > registered by cpu_dev_register_generic().
> >
> > This moves the CPU register logic back to a subsys_initcall(),
> > while the memory nodes will have been registered earlier.  
> 
> Isn't this somewhat risky?
> 
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > Tested-by: Miguel Luis <miguel.luis@oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu@arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > ---
> > Changes since RFC v2:
> >  * Fixup comment in acpi_processor_get_info() (Gavin Shan)
> >  * Add comment in cpu_dev_register_generic() (Gavin Shan)
> > ---
> >  drivers/acpi/acpi_processor.c | 12 ++++++++++++
> >  drivers/base/cpu.c            |  6 +++++-
> >  2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 0511f2bc10bc..e7ed4730cbbe 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
> >                         cpufreq_add_device("acpi-cpufreq");
> >         }
> >
> > +       /*
> > +        * Register CPUs that are present. get_cpu_device() is used to skip
> > +        * duplicate CPU descriptions from firmware.
> > +        */
> > +       if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
> > +           !get_cpu_device(pr->id)) {
> > +               int ret = arch_register_cpu(pr->id);
> > +
> > +               if (ret)
> > +                       return ret;
> > +       }
> > +
> >         /*
> >          *  Extra Processor objects may be enumerated on MP systems with
> >          *  less than the max # of CPUs. They should be ignored _iff
> > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > index 47de0f140ba6..13d052bf13f4 100644
> > --- a/drivers/base/cpu.c
> > +++ b/drivers/base/cpu.c
> > @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
> >  {
> >         int i, ret;
> >
> > -       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
> > +       /*
> > +        * When ACPI is enabled, CPUs are registered via
> > +        * acpi_processor_get_info().
> > +        */
> > +       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
> >                 return;
> >
> >         for_each_present_cpu(i) {
> > --
> > 2.30.2
> >
> >  
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>,
	<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>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Mon, 22 Jan 2024 17:44:49 +0000	[thread overview]
Message-ID: <20240122174449.00002f78@Huawei.com> (raw)
In-Reply-To: <CAJZ5v0je=-oVnSumZs=dzcyVuVUeVeTgO7yOnjGg1igyrS7EHQ@mail.gmail.com>

On Mon, 18 Dec 2023 21:30:50 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Wed, Dec 13, 2023 at 1:49 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > From: James Morse <james.morse@arm.com>
> >
> > To allow ACPI to skip the call to arch_register_cpu() when the _STA
> > value indicates the CPU can't be brought online right now, move the
> > arch_register_cpu() call into acpi_processor_get_info().  
> 
> This kind of looks backwards to me and has a potential to become
> super-confusing.
> 
> I would instead add a way for the generic code to ask the platform
> firmware whether or not the given CPU is enabled and so it can be
> registered.

Hi Rafael,

The ACPI interpreter isn't up at this stage so we'd need to pull that
forwards. I'm not sure if we can pull the interpreter init early enough.

Perhaps pushing the registration back in all cases is the way to go?
Given the acpi interpretter is initialized via subsys_initcall() it would
need to be after that - I tried pushing cpu_dev_register_generic()
immediately after acpi_bus_init() and that seems fine.
We can't leave the rest of cpu_dev_init() that late because a bunch
of other stuff relies on it (CPU freq blows up first as a core_init()
on my setup).

So to make this work we need it to always move the registration later
than the necessary infrastructure, perhaps to subsys_initcall_sync()
as is done for missing CPUs (we'd need to combine the two given that
needs to run after this, or potentially just stop checking for acpi_disabled
and don't taint the kernel!).  I think this is probably the most consistent
option on basis it at least moves the registration to the same point
whatever is going on and can easily use the arch callback you suggest
to hide away the logic on deciding if a CPU is there or not.

What do you think is the best way to do this?


> 
> > Systems can still be booted with 'acpi=off', or not include ano
> > ACPI description at all. For these, the CPUs continue to be
> > registered by cpu_dev_register_generic().
> >
> > This moves the CPU register logic back to a subsys_initcall(),
> > while the memory nodes will have been registered earlier.  
> 
> Isn't this somewhat risky?
> 
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > Tested-by: Miguel Luis <miguel.luis@oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu@arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > ---
> > Changes since RFC v2:
> >  * Fixup comment in acpi_processor_get_info() (Gavin Shan)
> >  * Add comment in cpu_dev_register_generic() (Gavin Shan)
> > ---
> >  drivers/acpi/acpi_processor.c | 12 ++++++++++++
> >  drivers/base/cpu.c            |  6 +++++-
> >  2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 0511f2bc10bc..e7ed4730cbbe 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
> >                         cpufreq_add_device("acpi-cpufreq");
> >         }
> >
> > +       /*
> > +        * Register CPUs that are present. get_cpu_device() is used to skip
> > +        * duplicate CPU descriptions from firmware.
> > +        */
> > +       if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
> > +           !get_cpu_device(pr->id)) {
> > +               int ret = arch_register_cpu(pr->id);
> > +
> > +               if (ret)
> > +                       return ret;
> > +       }
> > +
> >         /*
> >          *  Extra Processor objects may be enumerated on MP systems with
> >          *  less than the max # of CPUs. They should be ignored _iff
> > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > index 47de0f140ba6..13d052bf13f4 100644
> > --- a/drivers/base/cpu.c
> > +++ b/drivers/base/cpu.c
> > @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
> >  {
> >         int i, ret;
> >
> > -       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
> > +       /*
> > +        * When ACPI is enabled, CPUs are registered via
> > +        * acpi_processor_get_info().
> > +        */
> > +       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
> >                 return;
> >
> >         for_each_present_cpu(i) {
> > --
> > 2.30.2
> >
> >  
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>,
	<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>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Mon, 22 Jan 2024 17:44:49 +0000	[thread overview]
Message-ID: <20240122174449.00002f78@Huawei.com> (raw)
In-Reply-To: <CAJZ5v0je=-oVnSumZs=dzcyVuVUeVeTgO7yOnjGg1igyrS7EHQ@mail.gmail.com>

On Mon, 18 Dec 2023 21:30:50 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> On Wed, Dec 13, 2023 at 1:49 PM Russell King <rmk+kernel@armlinux.org.uk> wrote:
> >
> > From: James Morse <james.morse@arm.com>
> >
> > To allow ACPI to skip the call to arch_register_cpu() when the _STA
> > value indicates the CPU can't be brought online right now, move the
> > arch_register_cpu() call into acpi_processor_get_info().  
> 
> This kind of looks backwards to me and has a potential to become
> super-confusing.
> 
> I would instead add a way for the generic code to ask the platform
> firmware whether or not the given CPU is enabled and so it can be
> registered.

Hi Rafael,

The ACPI interpreter isn't up at this stage so we'd need to pull that
forwards. I'm not sure if we can pull the interpreter init early enough.

Perhaps pushing the registration back in all cases is the way to go?
Given the acpi interpretter is initialized via subsys_initcall() it would
need to be after that - I tried pushing cpu_dev_register_generic()
immediately after acpi_bus_init() and that seems fine.
We can't leave the rest of cpu_dev_init() that late because a bunch
of other stuff relies on it (CPU freq blows up first as a core_init()
on my setup).

So to make this work we need it to always move the registration later
than the necessary infrastructure, perhaps to subsys_initcall_sync()
as is done for missing CPUs (we'd need to combine the two given that
needs to run after this, or potentially just stop checking for acpi_disabled
and don't taint the kernel!).  I think this is probably the most consistent
option on basis it at least moves the registration to the same point
whatever is going on and can easily use the arch callback you suggest
to hide away the logic on deciding if a CPU is there or not.

What do you think is the best way to do this?


> 
> > Systems can still be booted with 'acpi=off', or not include ano
> > ACPI description at all. For these, the CPUs continue to be
> > registered by cpu_dev_register_generic().
> >
> > This moves the CPU register logic back to a subsys_initcall(),
> > while the memory nodes will have been registered earlier.  
> 
> Isn't this somewhat risky?
> 
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > Tested-by: Miguel Luis <miguel.luis@oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu@arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > ---
> > Changes since RFC v2:
> >  * Fixup comment in acpi_processor_get_info() (Gavin Shan)
> >  * Add comment in cpu_dev_register_generic() (Gavin Shan)
> > ---
> >  drivers/acpi/acpi_processor.c | 12 ++++++++++++
> >  drivers/base/cpu.c            |  6 +++++-
> >  2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 0511f2bc10bc..e7ed4730cbbe 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
> >                         cpufreq_add_device("acpi-cpufreq");
> >         }
> >
> > +       /*
> > +        * Register CPUs that are present. get_cpu_device() is used to skip
> > +        * duplicate CPU descriptions from firmware.
> > +        */
> > +       if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
> > +           !get_cpu_device(pr->id)) {
> > +               int ret = arch_register_cpu(pr->id);
> > +
> > +               if (ret)
> > +                       return ret;
> > +       }
> > +
> >         /*
> >          *  Extra Processor objects may be enumerated on MP systems with
> >          *  less than the max # of CPUs. They should be ignored _iff
> > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > index 47de0f140ba6..13d052bf13f4 100644
> > --- a/drivers/base/cpu.c
> > +++ b/drivers/base/cpu.c
> > @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
> >  {
> >         int i, ret;
> >
> > -       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
> > +       /*
> > +        * When ACPI is enabled, CPUs are registered via
> > +        * acpi_processor_get_info().
> > +        */
> > +       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
> >                 return;
> >
> >         for_each_present_cpu(i) {
> > --
> > 2.30.2
> >
> >  
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

  reply	other threads:[~2024-01-22 17:44 UTC|newest]

Thread overview: 363+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 12:47 [RFC PATCH v3 00/21] ACPI/arm64: add support for virtual cpu hotplug Russell King (Oracle)
2023-12-13 12:47 ` Russell King (Oracle)
2023-12-13 12:47 ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:32   ` Jonathan Cameron
2023-12-14 17:32     ` Jonathan Cameron
2023-12-14 17:32     ` Jonathan Cameron
2023-12-14 17:47     ` Rafael J. Wysocki
2023-12-14 17:47       ` Rafael J. Wysocki
2023-12-14 17:47       ` Rafael J. Wysocki
2023-12-14 18:10       ` Russell King (Oracle)
2023-12-14 18:10         ` Russell King (Oracle)
2023-12-14 18:10         ` Russell King (Oracle)
2023-12-14 18:16         ` Rafael J. Wysocki
2023-12-14 18:16           ` Rafael J. Wysocki
2023-12-14 18:16           ` Rafael J. Wysocki
2023-12-14 18:37           ` Rafael J. Wysocki
2023-12-14 18:37             ` Rafael J. Wysocki
2023-12-14 18:37             ` Rafael J. Wysocki
2023-12-15 15:31             ` Russell King (Oracle)
2023-12-15 15:31               ` Russell King (Oracle)
2023-12-15 15:31               ` Russell King (Oracle)
2023-12-15 16:15               ` Jonathan Cameron
2023-12-15 16:15                 ` Jonathan Cameron
2023-12-15 16:15                 ` Jonathan Cameron
2023-12-15 19:47                 ` Rafael J. Wysocki
2023-12-15 19:47                   ` Rafael J. Wysocki
2023-12-15 19:47                   ` Rafael J. Wysocki
2024-01-02 14:39                   ` Jonathan Cameron
2024-01-02 14:39                     ` Jonathan Cameron
2024-01-02 14:39                     ` Jonathan Cameron
2024-01-11 10:19                     ` Jonathan Cameron
2024-01-11 10:19                       ` Jonathan Cameron
2024-01-11 10:19                       ` Jonathan Cameron
2024-01-11 10:26                       ` Russell King (Oracle)
2024-01-11 10:26                         ` Russell King (Oracle)
2024-01-11 10:26                         ` Russell King (Oracle)
2024-01-12 11:52                         ` Jonathan Cameron
2024-01-12 11:52                           ` Jonathan Cameron
2024-01-12 11:52                           ` Jonathan Cameron
2024-01-29 14:55                           ` Russell King (Oracle)
2024-01-29 14:55                             ` Russell King (Oracle)
2024-01-29 14:55                             ` Russell King (Oracle)
2024-01-29 15:05                             ` Rafael J. Wysocki
2024-01-29 15:05                               ` Rafael J. Wysocki
2024-01-29 15:05                               ` Rafael J. Wysocki
2024-01-29 15:16                               ` Russell King (Oracle)
2024-01-29 15:16                                 ` Russell King (Oracle)
2024-01-29 15:16                                 ` Russell King (Oracle)
2024-01-29 15:34                                 ` Rafael J. Wysocki
2024-01-29 15:34                                   ` Rafael J. Wysocki
2024-01-29 15:34                                   ` Rafael J. Wysocki
2024-01-22  7:31                         ` Gavin Shan
2024-01-22  7:31                           ` Gavin Shan
2024-01-22  7:31                           ` Gavin Shan
2023-12-14 17:55     ` Russell King (Oracle)
2023-12-14 17:55       ` Russell King (Oracle)
2023-12-14 17:55       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 02/21] ACPI: processor: Add support for processors described as container packages Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:36   ` Jonathan Cameron
2023-12-14 17:36     ` Jonathan Cameron
2023-12-14 17:36     ` Jonathan Cameron
2023-12-14 17:57     ` Russell King (Oracle)
2023-12-14 17:57       ` Russell King (Oracle)
2023-12-14 17:57       ` Russell King (Oracle)
2023-12-18 20:17   ` Rafael J. Wysocki
2023-12-18 20:17     ` Rafael J. Wysocki
2023-12-18 20:17     ` Rafael J. Wysocki
2024-01-09 15:49     ` Russell King (Oracle)
2024-01-09 15:49       ` Russell King (Oracle)
2024-01-09 15:49       ` Russell King (Oracle)
2024-01-09 16:05       ` Rafael J. Wysocki
2024-01-09 16:05         ` Rafael J. Wysocki
2024-01-09 16:05         ` Rafael J. Wysocki
2024-01-09 16:13         ` Russell King (Oracle)
2024-01-09 16:13           ` Russell King (Oracle)
2024-01-09 16:13           ` Russell King (Oracle)
2024-01-11 16:17           ` Jonathan Cameron
2024-01-11 16:17             ` Jonathan Cameron
2024-01-11 16:17             ` Jonathan Cameron
2024-01-11 17:59     ` Jonathan Cameron
2024-01-11 17:59       ` Jonathan Cameron
2024-01-11 17:59       ` Jonathan Cameron
2024-01-11 18:46       ` Russell King (Oracle)
2024-01-11 18:46         ` Russell King (Oracle)
2024-01-11 18:46         ` Russell King (Oracle)
2024-01-12  9:25         ` Jonathan Cameron
2024-01-12  9:25           ` Jonathan Cameron
2024-01-12  9:25           ` Jonathan Cameron
2024-01-12 15:01           ` Rafael J. Wysocki
2024-01-12 15:01             ` Rafael J. Wysocki
2024-01-12 15:01             ` Rafael J. Wysocki
2024-01-12 15:03             ` Jonathan Cameron
2024-01-12 15:03               ` Jonathan Cameron
2024-01-12 15:03               ` Jonathan Cameron
2024-01-15 10:47             ` Russell King (Oracle)
2024-01-15 10:47               ` Russell King (Oracle)
2024-01-15 10:47               ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 03/21] ACPI: processor: Register CPUs that are online, but not described in the DSDT Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-18 20:22   ` Rafael J. Wysocki
2023-12-18 20:22     ` Rafael J. Wysocki
2023-12-18 20:22     ` Rafael J. Wysocki
2024-01-15 11:06     ` Russell King (Oracle)
2024-01-15 11:06       ` Russell King (Oracle)
2024-01-15 11:06       ` Russell King (Oracle)
2024-01-22 16:02       ` Jonathan Cameron
2024-01-22 16:02         ` Jonathan Cameron
2024-01-22 16:02         ` Jonathan Cameron
2024-01-22 16:22         ` Rafael J. Wysocki
2024-01-22 16:22           ` Rafael J. Wysocki
2024-01-22 16:22           ` Rafael J. Wysocki
2024-01-22 17:30           ` Russell King (Oracle)
2024-01-22 17:30             ` Russell King (Oracle)
2024-01-22 17:30             ` Russell King (Oracle)
2024-01-23  9:27             ` Jonathan Cameron
2024-01-23  9:27               ` Jonathan Cameron
2024-01-23  9:27               ` Jonathan Cameron
2024-01-25 13:56               ` Miguel Luis
2024-01-25 13:56                 ` Miguel Luis
2024-01-25 13:56                 ` Miguel Luis
2024-01-25 14:42                 ` Rafael J. Wysocki
2024-01-25 14:42                   ` Rafael J. Wysocki
2024-01-25 14:42                   ` Rafael J. Wysocki
2024-01-29 13:03               ` Jonathan Cameron
2024-01-29 13:03                 ` Jonathan Cameron
2024-01-29 13:03                 ` Jonathan Cameron
2024-01-29 15:32                 ` Russell King (Oracle)
2024-01-29 15:32                   ` Russell King (Oracle)
2024-01-29 15:32                   ` Russell King (Oracle)
2024-01-22 17:27         ` Russell King (Oracle)
2024-01-22 17:27           ` Russell King (Oracle)
2024-01-22 17:27           ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info() Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:38   ` Jonathan Cameron
2023-12-14 17:38     ` Jonathan Cameron
2023-12-14 17:38     ` Jonathan Cameron
2023-12-18 20:30   ` Rafael J. Wysocki
2023-12-18 20:30     ` Rafael J. Wysocki
2023-12-18 20:30     ` Rafael J. Wysocki
2024-01-22 17:44     ` Jonathan Cameron [this message]
2024-01-22 17:44       ` Jonathan Cameron
2024-01-22 17:44       ` Jonathan Cameron
2024-01-22 18:03       ` Rafael J. Wysocki
2024-01-22 18:03         ` Rafael J. Wysocki
2024-01-22 18:03         ` Rafael J. Wysocki
2024-01-22 21:56     ` Russell King (Oracle)
2024-01-22 21:56       ` Russell King (Oracle)
2024-01-22 21:56       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include 'present' Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:41   ` Jonathan Cameron
2023-12-14 17:41     ` Jonathan Cameron
2023-12-14 17:41     ` Jonathan Cameron
2023-12-14 18:00     ` Russell King (Oracle)
2023-12-14 18:00       ` Russell King (Oracle)
2023-12-14 18:00       ` Russell King (Oracle)
2023-12-18 20:35   ` Rafael J. Wysocki
2023-12-18 20:35     ` Rafael J. Wysocki
2023-12-18 20:35     ` Rafael J. Wysocki
2024-01-22 18:00     ` Jonathan Cameron
2024-01-22 18:00       ` Jonathan Cameron
2024-01-22 18:00       ` Jonathan Cameron
2024-01-23 13:28       ` Russell King (Oracle)
2024-01-23 13:28         ` Russell King (Oracle)
2024-01-23 13:28         ` Russell King (Oracle)
2024-01-23 16:15         ` Rafael J. Wysocki
2024-01-23 16:15           ` Rafael J. Wysocki
2024-01-23 16:15           ` Rafael J. Wysocki
2024-01-23 16:36           ` Russell King (Oracle)
2024-01-23 16:36             ` Russell King (Oracle)
2024-01-23 16:36             ` Russell King (Oracle)
2024-01-23 17:43             ` Rafael J. Wysocki
2024-01-23 17:43               ` Rafael J. Wysocki
2024-01-23 17:43               ` Rafael J. Wysocki
2024-01-23 18:19               ` Russell King (Oracle)
2024-01-23 18:19                 ` Russell King (Oracle)
2024-01-23 18:19                 ` Russell King (Oracle)
2024-01-23 18:26                 ` Rafael J. Wysocki
2024-01-23 18:26                   ` Rafael J. Wysocki
2024-01-23 18:26                   ` Rafael J. Wysocki
2024-01-23 18:59                   ` Russell King (Oracle)
2024-01-23 18:59                     ` Russell King (Oracle)
2024-01-23 18:59                     ` Russell King (Oracle)
2024-01-23 19:27                     ` Rafael J. Wysocki
2024-01-23 19:27                       ` Rafael J. Wysocki
2024-01-23 19:27                       ` Rafael J. Wysocki
2024-01-23 20:09                       ` Russell King (Oracle)
2024-01-23 20:09                         ` Russell King (Oracle)
2024-01-23 20:09                         ` Russell King (Oracle)
2024-01-23 20:17                         ` Rafael J. Wysocki
2024-01-23 20:17                           ` Rafael J. Wysocki
2024-01-23 20:17                           ` Rafael J. Wysocki
2024-01-23 20:57                           ` Russell King (Oracle)
2024-01-23 20:57                             ` Russell King (Oracle)
2024-01-23 20:57                             ` Russell King (Oracle)
2024-01-23 21:12                             ` Russell King (Oracle)
2024-01-23 21:12                               ` Russell King (Oracle)
2024-01-23 21:12                               ` Russell King (Oracle)
2024-01-23 22:05                               ` Rafael J. Wysocki
2024-01-23 22:05                                 ` Rafael J. Wysocki
2024-01-23 22:05                                 ` Rafael J. Wysocki
2024-01-24  8:45                                 ` Russell King (Oracle)
2024-01-24  8:45                                   ` Russell King (Oracle)
2024-01-24  8:45                                   ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 06/21] ACPI: Move acpi_bus_trim_one() before acpi_scan_hot_remove() Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49 ` [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:43   ` Jonathan Cameron
2023-12-14 17:43     ` Jonathan Cameron
2023-12-14 17:43     ` Jonathan Cameron
2023-12-14 18:03     ` Russell King (Oracle)
2023-12-14 18:03       ` Russell King (Oracle)
2023-12-14 18:03       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 08/21] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49 ` [PATCH RFC v3 09/21] ACPI: convert acpi_processor_post_eject() to use IS_ENABLED() Russell King (Oracle)
2023-12-13 12:49   ` Russell King (Oracle)
2023-12-13 12:49   ` Russell King (Oracle)
2023-12-15 16:11   ` Jonathan Cameron
2023-12-15 16:11     ` Jonathan Cameron
2023-12-15 16:11     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 10/21] ACPI: Check _STA present bit before making CPUs not present Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:18   ` Jonathan Cameron
2023-12-15 16:18     ` Jonathan Cameron
2023-12-15 16:18     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 11/21] ACPI: Warn when the present bit changes but the feature is not enabled Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50 ` [PATCH RFC v3 12/21] arm64: acpi: Move get_cpu_for_acpi_id() to a header Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50 ` [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:23   ` Jonathan Cameron
2023-12-15 16:23     ` Jonathan Cameron
2023-12-15 16:23     ` Jonathan Cameron
2023-12-15 16:53     ` Russell King (Oracle)
2023-12-15 16:53       ` Russell King (Oracle)
2023-12-15 16:53       ` Russell King (Oracle)
2023-12-18  9:23       ` Lorenzo Pieralisi
2023-12-18  9:23         ` Lorenzo Pieralisi
2023-12-18  9:23         ` Lorenzo Pieralisi
2023-12-18 13:14         ` Rafael J. Wysocki
2023-12-18 13:14           ` Rafael J. Wysocki
2023-12-18 13:14           ` Rafael J. Wysocki
2023-12-18 16:28           ` Lorenzo Pieralisi
2023-12-18 16:28             ` Lorenzo Pieralisi
2023-12-18 16:28             ` Lorenzo Pieralisi
2023-12-27 11:15           ` Lorenzo Pieralisi
2023-12-27 11:15             ` Lorenzo Pieralisi
2023-12-27 11:15             ` Lorenzo Pieralisi
2023-12-13 12:50 ` [PATCH RFC v3 14/21] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:33   ` Jonathan Cameron
2023-12-15 16:33     ` Jonathan Cameron
2023-12-15 16:33     ` Jonathan Cameron
2024-01-09 19:27     ` Russell King (Oracle)
2024-01-09 19:27       ` Russell King (Oracle)
2024-01-09 19:27       ` Russell King (Oracle)
2024-01-23 10:08       ` Jonathan Cameron
2024-01-23 10:08         ` Jonathan Cameron
2024-01-23 10:08         ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 15/21] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:38   ` Jonathan Cameron
2023-12-15 16:38     ` Jonathan Cameron
2023-12-15 16:38     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 16/21] arm64: psci: Ignore DENIED CPUs Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:40   ` Jonathan Cameron
2023-12-15 16:40     ` Jonathan Cameron
2023-12-15 16:40     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 17/21] ACPI: add support to register CPUs based on the _STA enabled bit Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-18 13:03   ` Russell King (Oracle)
2023-12-18 13:03     ` Russell King (Oracle)
2023-12-18 13:03     ` Russell King (Oracle)
2024-01-02 14:53     ` Jonathan Cameron
2024-01-02 14:53       ` Jonathan Cameron
2024-01-02 14:53       ` Jonathan Cameron
2024-01-23 10:26       ` Jonathan Cameron
2024-01-23 10:26         ` Jonathan Cameron
2024-01-23 10:26         ` Jonathan Cameron
2024-01-23 13:10         ` Russell King (Oracle)
2024-01-23 13:10           ` Russell King (Oracle)
2024-01-23 13:10           ` Russell King (Oracle)
2024-01-23 14:22           ` Jonathan Cameron
2024-01-23 14:22             ` Jonathan Cameron
2024-01-23 14:22             ` Jonathan Cameron
2024-01-23 14:59             ` Russell King (Oracle)
2024-01-23 14:59               ` Russell King (Oracle)
2024-01-23 14:59               ` Russell King (Oracle)
2023-12-13 12:50 ` [PATCH RFC v3 18/21] ACPI: processor: Only call arch_unregister_cpu() if HOTPLUG_CPU is selected Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:50   ` Jonathan Cameron
2023-12-15 16:50     ` Jonathan Cameron
2023-12-15 16:50     ` Jonathan Cameron
2023-12-18 12:58     ` Russell King (Oracle)
2023-12-18 12:58       ` Russell King (Oracle)
2023-12-18 12:58       ` Russell King (Oracle)
2024-01-23 10:29       ` Jonathan Cameron
2024-01-23 10:29         ` Jonathan Cameron
2024-01-23 10:29         ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's expectations Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:04   ` Jonathan Cameron
2023-12-15 17:04     ` Jonathan Cameron
2023-12-15 17:04     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS support for toggling CPU present/enabled Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:12   ` Jonathan Cameron
2023-12-15 17:12     ` Jonathan Cameron
2023-12-15 17:12     ` Jonathan Cameron
2024-01-02 13:07     ` Jose Marinho
2024-01-02 13:07       ` Jose Marinho
2024-01-02 13:07       ` Jose Marinho
2024-01-02 15:16       ` Jonathan Cameron
2024-01-02 15:16         ` Jonathan Cameron
2024-01-02 15:16         ` Jonathan Cameron
2024-01-02 15:35         ` Jose Marinho
2024-01-02 15:35           ` Jose Marinho
2024-01-02 15:35           ` Jose Marinho
2024-01-23 10:51           ` Jonathan Cameron
2024-01-23 10:51             ` Jonathan Cameron
2024-01-23 10:51             ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present CPUs that can be brought online Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:18   ` Jonathan Cameron
2023-12-15 17:18     ` Jonathan Cameron
2023-12-15 17:18     ` Jonathan Cameron
2023-12-18 12:14     ` Russell King (Oracle)
2023-12-18 12:14       ` Russell King (Oracle)
2023-12-18 12:14       ` Russell King (Oracle)
2024-01-02 15:19       ` Jonathan Cameron
2024-01-02 15:19         ` Jonathan Cameron
2024-01-02 15:19         ` Jonathan Cameron
2023-12-15 19:40   ` Thomas Gleixner
2023-12-15 19:40     ` Thomas Gleixner
2023-12-15 19:40     ` Thomas Gleixner

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=20240122174449.00002f78@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=acpica-devel@lists.linuxfoundation.org \
    --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-csky@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=loongarch@lists.linux.dev \
    --cc=rafael@kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=salil.mehta@huawei.com \
    --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.