From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
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 01/21] ACPI: Only enumerate enabled (or functional) devices
Date: Thu, 14 Dec 2023 18:10:13 +0000 [thread overview]
Message-ID: <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 6:32 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 13 Dec 2023 12:49:16 +0000
> > Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:
> >
> > > From: James Morse <james.morse@arm.com>
> > >
> > > Today the ACPI enumeration code 'visits' all devices that are present.
> > >
> > > This is a problem for arm64, where CPUs are always present, but not
> > > always enabled. When a device-check occurs because the firmware-policy
> > > has changed and a CPU is now enabled, the following error occurs:
> > > | acpi ACPI0007:48: Enumeration failure
> > >
> > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > true for a device that is not enabled. The ACPI Processor driver
> > > will not register such CPUs as they are not 'decoding their resources'.
> > >
> > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > ACPI allows a device to be functional instead of maintaining the
> > > present and enabled bit. Make this behaviour an explicit check with
> > > a reference to the spec, and then check the present and enabled bits.
> > > This is needed to avoid enumerating present && functional devices that
> > > are not enabled.
> > >
> > > Signed-off-by: James Morse <james.morse@arm.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>
> > > ---
> > > If this change causes problems on deployed hardware, I suggest an
> > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > acpi_dev_ready_for_enumeration() to only check the present bit.
> >
> > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > horribly broken firmware and had to be reverted) is reduce the blast
> > radius preemptively from the start. I'd love to live in a world were
> > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > make it though - arch opt in might be narrow enough.
>
> A chicken bit wouldn't help much IMO, especially in the cases when
> working setups get broken.
>
> I would very much prefer to limit the scope of it, say to processors
> only, in the first place.
Thanks for the feedback and the idea.
I guess we need something like:
if (device->status.present)
return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
device->status.enabled;
else
return device->status.functional;
so we only check device->status.enabled for processor-type devices?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
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 01/21] ACPI: Only enumerate enabled (or functional) devices
Date: Thu, 14 Dec 2023 18:10:13 +0000 [thread overview]
Message-ID: <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 6:32 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 13 Dec 2023 12:49:16 +0000
> > Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:
> >
> > > From: James Morse <james.morse@arm.com>
> > >
> > > Today the ACPI enumeration code 'visits' all devices that are present.
> > >
> > > This is a problem for arm64, where CPUs are always present, but not
> > > always enabled. When a device-check occurs because the firmware-policy
> > > has changed and a CPU is now enabled, the following error occurs:
> > > | acpi ACPI0007:48: Enumeration failure
> > >
> > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > true for a device that is not enabled. The ACPI Processor driver
> > > will not register such CPUs as they are not 'decoding their resources'.
> > >
> > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > ACPI allows a device to be functional instead of maintaining the
> > > present and enabled bit. Make this behaviour an explicit check with
> > > a reference to the spec, and then check the present and enabled bits.
> > > This is needed to avoid enumerating present && functional devices that
> > > are not enabled.
> > >
> > > Signed-off-by: James Morse <james.morse@arm.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>
> > > ---
> > > If this change causes problems on deployed hardware, I suggest an
> > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > acpi_dev_ready_for_enumeration() to only check the present bit.
> >
> > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > horribly broken firmware and had to be reverted) is reduce the blast
> > radius preemptively from the start. I'd love to live in a world were
> > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > make it though - arch opt in might be narrow enough.
>
> A chicken bit wouldn't help much IMO, especially in the cases when
> working setups get broken.
>
> I would very much prefer to limit the scope of it, say to processors
> only, in the first place.
Thanks for the feedback and the idea.
I guess we need something like:
if (device->status.present)
return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
device->status.enabled;
else
return device->status.functional;
so we only check device->status.enabled for processor-type devices?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
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 01/21] ACPI: Only enumerate enabled (or functional) devices
Date: Thu, 14 Dec 2023 18:10:13 +0000 [thread overview]
Message-ID: <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 6:32 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 13 Dec 2023 12:49:16 +0000
> > Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:
> >
> > > From: James Morse <james.morse@arm.com>
> > >
> > > Today the ACPI enumeration code 'visits' all devices that are present.
> > >
> > > This is a problem for arm64, where CPUs are always present, but not
> > > always enabled. When a device-check occurs because the firmware-policy
> > > has changed and a CPU is now enabled, the following error occurs:
> > > | acpi ACPI0007:48: Enumeration failure
> > >
> > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > true for a device that is not enabled. The ACPI Processor driver
> > > will not register such CPUs as they are not 'decoding their resources'.
> > >
> > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > ACPI allows a device to be functional instead of maintaining the
> > > present and enabled bit. Make this behaviour an explicit check with
> > > a reference to the spec, and then check the present and enabled bits.
> > > This is needed to avoid enumerating present && functional devices that
> > > are not enabled.
> > >
> > > Signed-off-by: James Morse <james.morse@arm.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>
> > > ---
> > > If this change causes problems on deployed hardware, I suggest an
> > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > acpi_dev_ready_for_enumeration() to only check the present bit.
> >
> > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > horribly broken firmware and had to be reverted) is reduce the blast
> > radius preemptively from the start. I'd love to live in a world were
> > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > make it though - arch opt in might be narrow enough.
>
> A chicken bit wouldn't help much IMO, especially in the cases when
> working setups get broken.
>
> I would very much prefer to limit the scope of it, say to processors
> only, in the first place.
Thanks for the feedback and the idea.
I guess we need something like:
if (device->status.present)
return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
device->status.enabled;
else
return device->status.functional;
so we only check device->status.enabled for processor-type devices?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-12-14 18:10 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) [this message]
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
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=ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=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=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.