From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
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: Mon, 29 Jan 2024 16:34:57 +0100 [thread overview]
Message-ID: <CAJZ5v0gr3ZmLY9m+rYGP36zQYNH4ohL=zbym4LS3Eq+Qt4nZLA@mail.gmail.com> (raw)
In-Reply-To: <ZbfBYgdLzvEX/VjN@shell.armlinux.org.uk>
On Mon, Jan 29, 2024 at 4:17 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Jan 29, 2024 at 04:05:42PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Jan 29, 2024 at 3:55 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > Hi Jonathan,
> > >
> > > On Fri, Jan 12, 2024 at 11:52:05AM +0000, Jonathan Cameron wrote:
> > > > On Thu, 11 Jan 2024 10:26:15 +0000
> > > > "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> > > > > @@ -2381,16 +2388,38 @@ EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies);
> > > > > * acpi_dev_ready_for_enumeration - Check if the ACPI device is ready for enumeration
> > > > > * @device: Pointer to the &struct acpi_device to check
> > > > > *
> > > > > - * Check if the device is present and has no unmet dependencies.
> > > > > + * Check if the device is functional or enabled and has no unmet dependencies.
> > > > > *
> > > > > - * Return true if the device is ready for enumeratino. Otherwise, return false.
> > > > > + * Return true if the device is ready for enumeration. Otherwise, return false.
> > > > > */
> > > > > bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
> > > > > {
> > > > > if (device->flags.honor_deps && device->dep_unmet)
> > > > > return false;
> > > > >
> > > > > - return acpi_device_is_present(device);
> > > > > + /*
> > > > > + * ACPI 6.5's 6.3.7 "_STA (Device Status)" allows firmware to return
> > > > > + * (!present && functional) for certain types of devices that should be
> > > > > + * enumerated. Note that the enabled bit should not be set unless the
> > > > > + * present bit is set.
> > > > > + *
> > > > > + * However, limit this only to processor devices to reduce possible
> > > > > + * regressions with firmware.
> > > > > + */
> > > > > + if (device->status.functional)
> > > > > + return true;
> > >
> > > I have a report from within Oracle that this causes testing failures
> > > with QEMU using -smp cpus=2,maxcpus=4. I think it needs to be:
> > >
> > > if (!device->status.present)
> > > return device->status.functional;
> > >
> > > if (device->status.enabled)
> > > return true;
> > >
> > > return !acpi_device_is_processor(device);
> >
> > The above is fine by me.
> >
> > > So we can better understand the history here, let's list it as a
> > > truth table. P=present, F=functional, E=enabled, Orig=how the code
> > > is in mainline, James=James' original proposal, Rafael=the proposed
> > > replacement but seems to be buggy, Rmk=the fixed version that passes
> > > tests:
> > >
> > > P F E Orig James Rafael Rmk
> > > 0 0 0 0 0 0 0
> > > 0 0 1 0 0 0 0
> > > 0 1 0 1 1 1 1
> > > 0 1 1 1 0 1 1
> > > 1 0 0 1 0 !processor !processor
> > > 1 0 1 1 1 1 1
> > > 1 1 0 1 0 1 !processor
> > > 1 1 1 1 1 1 1
> > >
> > > Any objections to this?
> >
> > So AFAIAC it can return false if not enabled, but present and
> > functional. [Side note: I'm wondering what "functional" means then,
> > but whatever.]
>
> From ACPI v6.5 (bit 3 is our "status.functional":
>
> _STA may return bit 0 clear (not present) with bit [3] set (device is
> functional). This case is used to indicate a valid device for which no
> device driver should be loaded (for example, a bridge device.) Children
> of this device may be present and valid. OSPM should continue
> enumeration below a device whose _STA returns this bit combination.
>
> So, for this case, acpi_dev_ready_for_enumeration() returning true for
> this case is correct, since we're supposed to enumerate it and child
> devices.
>
> It's probably also worth pointing out that in the above table, the two
> combinations with P=0 E=1 goes against the spec, but are included for
> completness.
The difference between the last two columns is the present and
functional, but not enabled combination AFAICS, for which my patch
just returned true, but the firmware disagrees with that.
It is kind of analogous to the "not present and functional" case
covered by the spec, which is why it is fine by me to return "false"
then (for processors), but the spec is not crystal clear about it.
next prev parent reply other threads:[~2024-01-29 15:35 UTC|newest]
Thread overview: 121+ 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:49 ` [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices Russell King
2023-12-14 17:32 ` Jonathan Cameron
2023-12-14 17:47 ` Rafael J. Wysocki
2023-12-14 18:10 ` Russell King (Oracle)
2023-12-14 18:16 ` Rafael J. Wysocki
2023-12-14 18:37 ` Rafael J. Wysocki
2023-12-15 15:31 ` Russell King (Oracle)
2023-12-15 16:15 ` Jonathan Cameron
2023-12-15 19:47 ` Rafael J. Wysocki
2024-01-02 14:39 ` Jonathan Cameron
2024-01-11 10:19 ` Jonathan Cameron
2024-01-11 10:26 ` Russell King (Oracle)
2024-01-12 11:52 ` Jonathan Cameron
2024-01-29 14:55 ` Russell King (Oracle)
2024-01-29 15:05 ` Rafael J. Wysocki
2024-01-29 15:16 ` Russell King (Oracle)
2024-01-29 15:34 ` Rafael J. Wysocki [this message]
2024-01-22 7:31 ` Gavin Shan
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-14 17:36 ` Jonathan Cameron
2023-12-14 17:57 ` Russell King (Oracle)
2023-12-18 20:17 ` Rafael J. Wysocki
2024-01-09 15:49 ` Russell King (Oracle)
2024-01-09 16:05 ` Rafael J. Wysocki
2024-01-09 16:13 ` Russell King (Oracle)
2024-01-11 16:17 ` Jonathan Cameron
2024-01-11 17:59 ` Jonathan Cameron
2024-01-11 18:46 ` Russell King (Oracle)
2024-01-12 9:25 ` Jonathan Cameron
2024-01-12 15:01 ` Rafael J. Wysocki
2024-01-12 15:03 ` Jonathan Cameron
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-18 20:22 ` Rafael J. Wysocki
2024-01-15 11:06 ` Russell King (Oracle)
2024-01-22 16:02 ` Jonathan Cameron
2024-01-22 16:22 ` Rafael J. Wysocki
2024-01-22 17:30 ` Russell King (Oracle)
2024-01-23 9:27 ` Jonathan Cameron
2024-01-25 13:56 ` Miguel Luis
2024-01-25 14:42 ` Rafael J. Wysocki
2024-01-29 13:03 ` Jonathan Cameron
2024-01-29 15:32 ` 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-14 17:38 ` Jonathan Cameron
2023-12-18 20:30 ` Rafael J. Wysocki
2024-01-22 17:44 ` Jonathan Cameron
2024-01-22 18:03 ` Rafael J. Wysocki
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-14 17:41 ` Jonathan Cameron
2023-12-14 18:00 ` Russell King (Oracle)
2023-12-18 20:35 ` Rafael J. Wysocki
2024-01-22 18:00 ` Jonathan Cameron
2024-01-23 13:28 ` Russell King (Oracle)
2024-01-23 16:15 ` Rafael J. Wysocki
2024-01-23 16:36 ` Russell King (Oracle)
2024-01-23 17:43 ` Rafael J. Wysocki
2024-01-23 18:19 ` Russell King (Oracle)
2024-01-23 18:26 ` Rafael J. Wysocki
2024-01-23 18:59 ` Russell King (Oracle)
2024-01-23 19:27 ` Rafael J. Wysocki
2024-01-23 20:09 ` Russell King (Oracle)
2024-01-23 20:17 ` Rafael J. Wysocki
2024-01-23 20:57 ` Russell King (Oracle)
2024-01-23 21:12 ` Russell King (Oracle)
2024-01-23 22:05 ` Rafael J. Wysocki
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 ` [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards Russell King
2023-12-14 17:43 ` Jonathan Cameron
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 ` [PATCH RFC v3 09/21] ACPI: convert acpi_processor_post_eject() to use IS_ENABLED() Russell King (Oracle)
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-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 ` [PATCH RFC v3 12/21] arm64: acpi: Move get_cpu_for_acpi_id() to a header Russell King
2023-12-13 12:50 ` [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields Russell King
2023-12-15 16:23 ` Jonathan Cameron
2023-12-15 16:53 ` Russell King (Oracle)
2023-12-18 9:23 ` Lorenzo Pieralisi
2023-12-18 13:14 ` Rafael J. Wysocki
2023-12-18 16:28 ` 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-15 16:33 ` Jonathan Cameron
2024-01-09 19:27 ` Russell King (Oracle)
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-15 16:38 ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 16/21] arm64: psci: Ignore DENIED CPUs Russell King
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-18 13:03 ` Russell King (Oracle)
2024-01-02 14:53 ` Jonathan Cameron
2024-01-23 10:26 ` Jonathan Cameron
2024-01-23 13:10 ` Russell King (Oracle)
2024-01-23 14:22 ` Jonathan Cameron
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-15 16:50 ` Jonathan Cameron
2023-12-18 12:58 ` Russell King (Oracle)
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-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-15 17:12 ` Jonathan Cameron
2024-01-02 13:07 ` Jose Marinho
2024-01-02 15:16 ` Jonathan Cameron
2024-01-02 15:35 ` Jose Marinho
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-15 17:18 ` Jonathan Cameron
2023-12-18 12:14 ` Russell King (Oracle)
2024-01-02 15:19 ` Jonathan Cameron
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='CAJZ5v0gr3ZmLY9m+rYGP36zQYNH4ohL=zbym4LS3Eq+Qt4nZLA@mail.gmail.com' \
--to=rafael@kernel.org \
--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=linux@armlinux.org.uk \
--cc=loongarch@lists.linux.dev \
--cc=rjw@rjwysocki.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).