All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.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,
	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 v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Wed, 10 Apr 2024 19:56:00 +0100	[thread overview]
Message-ID: <ZhbgwBBvh6ccdO7x@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240410145005.00003050@Huawei.com>

On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote:
> If we get rid of this catch all, solution would be to move the
> !acpi_disabled check into the arm64 version of arch_cpu_register()
> because we would only want the delayed registration path to be
> used on ACPI cases where the question of CPU availability can't
> yet be resolved.

Aren't we then needing two arch_register_cpu() implementations?
I'm assuming that you're suggesting that the !acpi_disabled, then
do nothing check is moved into arch_register_cpu() - or to put it
another way, arch_register_cpu() does nothing if ACPI is enabled.

If arch_register_cpu() does nothing if ACPI is enabled, how do
CPUs get registered (and sysfs files get created to control them)
on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(),
so I suspect you'll need an ACPI-specific version of this function.

-- 
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.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,
	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 v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Wed, 10 Apr 2024 19:56:00 +0100	[thread overview]
Message-ID: <ZhbgwBBvh6ccdO7x@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240410145005.00003050@Huawei.com>

On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote:
> If we get rid of this catch all, solution would be to move the
> !acpi_disabled check into the arm64 version of arch_cpu_register()
> because we would only want the delayed registration path to be
> used on ACPI cases where the question of CPU availability can't
> yet be resolved.

Aren't we then needing two arch_register_cpu() implementations?
I'm assuming that you're suggesting that the !acpi_disabled, then
do nothing check is moved into arch_register_cpu() - or to put it
another way, arch_register_cpu() does nothing if ACPI is enabled.

If arch_register_cpu() does nothing if ACPI is enabled, how do
CPUs get registered (and sysfs files get created to control them)
on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(),
so I suspect you'll need an ACPI-specific version of this function.

-- 
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.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,
	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 v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info()
Date: Wed, 10 Apr 2024 19:56:00 +0100	[thread overview]
Message-ID: <ZhbgwBBvh6ccdO7x@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240410145005.00003050@Huawei.com>

On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote:
> If we get rid of this catch all, solution would be to move the
> !acpi_disabled check into the arm64 version of arch_cpu_register()
> because we would only want the delayed registration path to be
> used on ACPI cases where the question of CPU availability can't
> yet be resolved.

Aren't we then needing two arch_register_cpu() implementations?
I'm assuming that you're suggesting that the !acpi_disabled, then
do nothing check is moved into arch_register_cpu() - or to put it
another way, arch_register_cpu() does nothing if ACPI is enabled.

If arch_register_cpu() does nothing if ACPI is enabled, how do
CPUs get registered (and sysfs files get created to control them)
on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(),
so I suspect you'll need an ACPI-specific version of this function.

-- 
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

  parent reply	other threads:[~2024-04-10 19:07 UTC|newest]

Thread overview: 126+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 16:48 [RFC PATCH v4 00/15] ACPI/arm64: add support for virtual cpu hotplug Russell King (Oracle)
2024-01-31 16:48 ` Russell King (Oracle)
2024-01-31 16:48 ` Russell King (Oracle)
2024-01-31 16:49 ` [PATCH RFC v4 01/15] ACPI: Only enumerate enabled (or functional) processor devices Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 17:25   ` Miguel Luis
2024-01-31 17:25     ` Miguel Luis
2024-01-31 17:25     ` Miguel Luis
2024-02-15 20:10   ` Rafael J. Wysocki
2024-02-15 20:10     ` Rafael J. Wysocki
2024-02-15 20:10     ` Rafael J. Wysocki
2024-02-19  9:45     ` Jonathan Cameron
2024-02-19  9:45       ` Jonathan Cameron
2024-02-19  9:45       ` Jonathan Cameron
2024-02-20 11:30     ` Russell King (Oracle)
2024-02-20 11:30       ` Russell King (Oracle)
2024-02-20 11:30       ` Russell King (Oracle)
2024-02-21 13:01   ` Rafael J. Wysocki
2024-02-21 13:01     ` Rafael J. Wysocki
2024-02-21 13:01     ` Rafael J. Wysocki
2024-01-31 16:49 ` [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info() Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:49   ` Russell King
2024-02-15 19:22   ` Rafael J. Wysocki
2024-02-15 19:22     ` Rafael J. Wysocki
2024-02-15 19:22     ` Rafael J. Wysocki
2024-02-20 11:27     ` Russell King (Oracle)
2024-02-20 11:27       ` Russell King (Oracle)
2024-02-20 11:27       ` Russell King (Oracle)
2024-02-20 15:13       ` Russell King (Oracle)
2024-02-20 15:13         ` Russell King (Oracle)
2024-02-20 15:13         ` Russell King (Oracle)
2024-02-20 16:24         ` Jonathan Cameron
2024-02-20 16:24           ` Jonathan Cameron
2024-02-20 16:24           ` Jonathan Cameron
2024-02-20 19:59           ` Rafael J. Wysocki
2024-02-20 19:59             ` Rafael J. Wysocki
2024-02-20 19:59             ` Rafael J. Wysocki
2024-02-21 12:04             ` Rafael J. Wysocki
2024-02-21 12:04               ` Rafael J. Wysocki
2024-02-21 12:04               ` Rafael J. Wysocki
2024-02-20 20:59     ` Thomas Gleixner
2024-02-20 20:59       ` Thomas Gleixner
2024-02-20 20:59       ` Thomas Gleixner
2024-03-22 18:53     ` Jonathan Cameron
2024-03-22 18:53       ` Jonathan Cameron
2024-03-22 18:53       ` Jonathan Cameron
2024-04-10 12:43       ` Jonathan Cameron
2024-04-10 12:43         ` Jonathan Cameron
2024-04-10 12:43         ` Jonathan Cameron
2024-04-10 13:28         ` Rafael J. Wysocki
2024-04-10 13:28           ` Rafael J. Wysocki
2024-04-10 13:28           ` Rafael J. Wysocki
2024-04-10 13:50           ` Jonathan Cameron
2024-04-10 13:50             ` Jonathan Cameron
2024-04-10 13:50             ` Jonathan Cameron
2024-04-10 14:19             ` Rafael J. Wysocki
2024-04-10 14:19               ` Rafael J. Wysocki
2024-04-10 14:19               ` Rafael J. Wysocki
2024-04-10 15:58               ` Jonathan Cameron
2024-04-10 15:58                 ` Jonathan Cameron
2024-04-10 15:58                 ` Jonathan Cameron
2024-04-10 18:56             ` Russell King (Oracle) [this message]
2024-04-10 18:56               ` Russell King (Oracle)
2024-04-10 18:56               ` Russell King (Oracle)
2024-04-10 19:08               ` Rafael J. Wysocki
2024-04-10 19:08                 ` Rafael J. Wysocki
2024-04-10 19:08                 ` Rafael J. Wysocki
2024-04-10 21:07                 ` Jonathan Cameron
2024-04-10 21:07                   ` Jonathan Cameron
2024-04-10 21:07                   ` Jonathan Cameron
2024-01-31 16:49 ` [PATCH RFC v4 03/15] ACPI: Move acpi_bus_trim_one() before acpi_scan_hot_remove() Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:49 ` [PATCH RFC v4 04/15] ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:49   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 05/15] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 06/15] ACPI: convert acpi_processor_post_eject() to use IS_ENABLED() Russell King (Oracle)
2024-01-31 16:50   ` Russell King (Oracle)
2024-01-31 16:50   ` Russell King (Oracle)
2024-01-31 16:50 ` [PATCH RFC v4 07/15] ACPI: Check _STA present bit before making CPUs not present Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 08/15] ACPI: Warn when the present bit changes but the feature is not enabled Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 09/15] arm64: acpi: Move get_cpu_for_acpi_id() to a header Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 10/15] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-02-02 16:44   ` Jonathan Cameron
2024-02-02 16:44     ` Jonathan Cameron
2024-02-02 16:44     ` Jonathan Cameron
2024-01-31 16:50 ` [PATCH RFC v4 11/15] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-02-02 16:47   ` Jonathan Cameron
2024-02-02 16:47     ` Jonathan Cameron
2024-02-02 16:47     ` Jonathan Cameron
2024-01-31 16:50 ` [PATCH RFC v4 12/15] arm64: psci: Ignore DENIED CPUs Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-04-11 11:35   ` Jonathan Cameron
2024-04-11 11:35     ` Jonathan Cameron
2024-04-11 11:35     ` Jonathan Cameron
2024-04-11 13:25     ` Jonathan Cameron
2024-04-11 13:25       ` Jonathan Cameron
2024-04-11 13:25       ` Jonathan Cameron
2024-01-31 16:50 ` [PATCH RFC v4 13/15] ACPI: add support to (un)register CPUs based on the _STA enabled bit Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50 ` [PATCH RFC v4 14/15] arm64: document virtual CPU hotplug's expectations Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King
2024-02-02 17:04   ` Jonathan Cameron
2024-02-02 17:04     ` Jonathan Cameron
2024-02-02 17:04     ` Jonathan Cameron
2024-01-31 16:50 ` [PATCH RFC v4 15/15] cpumask: Add enabled cpumask for present CPUs that can be brought online Russell King
2024-01-31 16:50   ` Russell King
2024-01-31 16:50   ` Russell King

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=ZhbgwBBvh6ccdO7x@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.