From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Miguel Luis <miguel.luis@oracle.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <rmk+kernel@armlinux.org.uk>
Subject: Re: [RFC PATCH 0/4] ACPI: processor: refactor acpi_processor_{get_info|remove}
Date: Wed, 10 Apr 2024 14:35:25 +0100 [thread overview]
Message-ID: <20240410143525.0000620a@Huawei.com> (raw)
In-Reply-To: <20240409150536.9933-1-miguel.luis@oracle.com>
On Tue, 9 Apr 2024 15:05:29 +0000
Miguel Luis <miguel.luis@oracle.com> wrote:
> Both acpi_processor_get_info and acpi_processor_remove functions have
> architecture dependent functionality enabled via CONFIG_ACPI_HOTPLUG_CPU.
>
> Current pre-processor guards are restricting too much of functionality which
> makes it dificult to integrate other features such as Virtual CPU
> hotplug/unplug for arm64.
>
> This series, applied on top of v6.9-rc3, suggests a refactoring on these two
> functions with the intent to understand them better and hopefully ease
> integration of more functionality.
>
> Apart from patches 2/4 and 3/4, which could be squashed but left them separated
> intentionally so it would ease reviewing, changes are self-contained.
>
> So far I've boot tested it successfully alone and as a prefix for vCPU hotplug/unplug
> patches [1], on arm64.
Hi Miguel,
Great to see an attempt to keep this moving. My apologies that I've been rather
quiet on this so far this cycle - a few things came up that ended up more urgent :(
In the thread you link there was a discussion on whether to stub out these functions
as a possible way forwards. I did some analysis of what was going on in
https://lore.kernel.org/linux-arm-kernel/20240322185327.00002416@Huawei.com/
and my conclusion was that to do so would mostly be misleading.
The flows for make present and make enabled are and should be different
(though not as different as they were in v4!)
Jonathan
>
> [1]: https://lore.kernel.org/linux-arm-kernel/Zbp5xzmFhKDAgHws@shell.armlinux.org.uk/
>
> Miguel Luis (4):
> ACPI: processor: refactor acpi_processor_get_info: evaluation of
> processor declaration
> ACPI: processor: refactor acpi_processor_get_info: isolate cpu hotpug
> init delay
> ACPI: processor: refactor acpi_processor_get_info: isolate
> acpi_{map|unmap}_cpu under CONFIG_ACPI_HOTPLUG_CPU
> ACPI: processor: refactor acpi_processor_remove: isolate
> acpi_unmap_cpu under CONFIG_ACPI_HOTPLUG_CPU
>
> drivers/acpi/acpi_processor.c | 138 ++++++++++++++++++++++------------
> 1 file changed, 91 insertions(+), 47 deletions(-)
>
> --
> 2.43.0
>
prev parent reply other threads:[~2024-04-10 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 15:05 [RFC PATCH 0/4] ACPI: processor: refactor acpi_processor_{get_info|remove} Miguel Luis
2024-04-09 15:05 ` [RFC PATCH 1/4] ACPI: processor: refactor acpi_processor_get_info: evaluation of processor declaration Miguel Luis
2024-04-10 13:13 ` Jonathan Cameron
2024-04-10 15:35 ` Miguel Luis
2024-04-09 15:05 ` [RFC PATCH 2/4] ACPI: processor: refactor acpi_processor_get_info: isolate cpu hotpug init delay Miguel Luis
2024-04-10 13:20 ` Jonathan Cameron
2024-04-10 17:20 ` Miguel Luis
2024-04-10 19:40 ` Jonathan Cameron
2024-04-09 15:05 ` [RFC PATCH 3/4] ACPI: processor: refactor acpi_processor_get_info: isolate acpi_{map|unmap}_cpu under CONFIG_ACPI_HOTPLUG_CPU Miguel Luis
2024-04-10 13:23 ` Jonathan Cameron
2024-04-10 18:29 ` Miguel Luis
2024-04-10 19:44 ` Jonathan Cameron
2024-04-11 10:52 ` Miguel Luis
2024-04-11 13:57 ` Jonathan Cameron
2024-04-11 15:55 ` Miguel Luis
2024-04-09 15:05 ` [RFC PATCH 4/4] ACPI: processor: refactor acpi_processor_remove: isolate acpi_unmap_cpu " Miguel Luis
2024-04-10 13:31 ` Jonathan Cameron
2024-04-11 11:02 ` Miguel Luis
2024-04-11 14:02 ` Jonathan Cameron
2024-04-10 13:35 ` Jonathan Cameron [this message]
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=20240410143525.0000620a@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.luis@oracle.com \
--cc=rafael@kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox