linux-csky.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	"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 v3 01/21] ACPI: Only enumerate enabled (or functional) devices
Date: Thu, 11 Jan 2024 10:19:49 +0000	[thread overview]
Message-ID: <20240111101949.000075dc@Huawei.com> (raw)
In-Reply-To: <20240102143925.00004361@Huawei.com>

On Tue, 2 Jan 2024 14:39:25 +0000
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Fri, 15 Dec 2023 20:47:31 +0100
> "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> 
> > On Friday, December 15, 2023 5:15:39 PM CET Jonathan Cameron wrote:  
> > > On Fri, 15 Dec 2023 15:31:55 +0000
> > > "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> > >     
> > > > On Thu, Dec 14, 2023 at 07:37:10PM +0100, Rafael J. Wysocki wrote:    
> > > > > On Thu, Dec 14, 2023 at 7:16 PM Rafael J. Wysocki <rafael@kernel.org> wrote:      
> > > > > >
> > > > > > On Thu, Dec 14, 2023 at 7:10 PM Russell King (Oracle)
> > > > > > <linux@armlinux.org.uk> wrote:      
> > > > > > > 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?      
> > > > > >
> > > > > > Yes, something like this.      
> > > > > 
> > > > > However, that is not sufficient, because there are
> > > > > ACPI_BUS_TYPE_DEVICE devices representing processors.
> > > > > 
> > > > > I'm not sure about a clean way to do it ATM.      
> > > > 
> > > > Ok, how about:
> > > > 
> > > > static bool acpi_dev_is_processor(const struct acpi_device *device)
> > > > {
> > > > 	struct acpi_hardware_id *hwid;
> > > > 
> > > > 	if (device->device_type == ACPI_BUS_TYPE_PROCESSOR)
> > > > 		return true;
> > > > 
> > > > 	if (device->device_type != ACPI_BUS_TYPE_DEVICE)
> > > > 		return false;
> > > > 
> > > > 	list_for_each_entry(hwid, &device->pnp.ids, list)
> > > > 		if (!strcmp(ACPI_PROCESSOR_OBJECT_HID, hwid->id) ||
> > > > 		    !strcmp(ACPI_PROCESSOR_DEVICE_HID, hwid->id))
> > > > 			return true;
> > > > 
> > > > 	return false;
> > > > }
> > > > 
> > > > and then:
> > > > 
> > > > 	if (device->status.present)
> > > > 		return !acpi_dev_is_processor(device) || device->status.enabled;
> > > > 	else
> > > > 		return device->status.functional;
> > > > 
> > > > ?
> > > >     
> > > Changing it to CPU only for now makes sense to me and I think this code snippet should do the
> > > job.  Nice and simple.    
> > 
> > Well, except that it does checks that are done elsewhere slightly
> > differently, which from the maintenance POV is not nice.
> > 
> > Maybe something like the appended patch (untested).  
> 
> Hi Rafael,
> 
> As far as I can see that's functionally equivalent, so looks good to me.
> I'm not set up to test this today though, so will defer to Russell on whether
> there is anything missing
> 
> Thanks for putting this together.

This is rather embarrassing...

I span this up on a QEMU instance with some prints to find out we need
the !acpi_device_is_processor() restriction.
On my 'random' test setup it fails on one device. ACPI0017 - which I
happen to know rather well. It's the weird pseudo device that lets
a CXL aware OS know there is a CEDT table to probe.

Whilst I really don't like that hack (it is all about making software
distribution of out of tree modules easier rather than something
fundamental), I'm the CXL QEMU maintainer :(

Will fix that, but it shows there is at least one broken firmware out
there.

On plus side, Rafael's code seems to work as expected and lets that
buggy firwmare carry on working :) So lets pretend the bug in qemu
is a deliberate test case!

Jonathan

p.s. My test setup blows up later for an unrelated reason with latest
kernel, so I'll be off debugging that for a while :(


> 
> Jonathan
> 
> > 
> > ---
> >  drivers/acpi/acpi_processor.c |   11 +++++++++++
> >  drivers/acpi/internal.h       |    3 +++
> >  drivers/acpi/scan.c           |   24 +++++++++++++++++++++++-
> >  3 files changed, 37 insertions(+), 1 deletion(-)
> > 
> > Index: linux-pm/drivers/acpi/acpi_processor.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/acpi_processor.c
> > +++ linux-pm/drivers/acpi/acpi_processor.c
> > @@ -644,6 +644,17 @@ static struct acpi_scan_handler processo
> >  	},
> >  };
> >  
> > +bool acpi_device_is_processor(const struct acpi_device *adev)
> > +{
> > +	if (adev->device_type == ACPI_BUS_TYPE_PROCESSOR)
> > +		return true;
> > +
> > +	if (adev->device_type != ACPI_BUS_TYPE_DEVICE)
> > +		return false;
> > +
> > +	return acpi_scan_check_handler(adev, &processor_handler);
> > +}
> > +
> >  static int acpi_processor_container_attach(struct acpi_device *dev,
> >  					   const struct acpi_device_id *id)
> >  {
> > Index: linux-pm/drivers/acpi/internal.h
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/internal.h
> > +++ linux-pm/drivers/acpi/internal.h
> > @@ -62,6 +62,8 @@ void acpi_sysfs_add_hotplug_profile(stru
> >  int acpi_scan_add_handler_with_hotplug(struct acpi_scan_handler *handler,
> >  				       const char *hotplug_profile_name);
> >  void acpi_scan_hotplug_enabled(struct acpi_hotplug_profile *hotplug, bool val);
> > +bool acpi_scan_check_handler(const struct acpi_device *adev,
> > +			     struct acpi_scan_handler *handler);
> >  
> >  #ifdef CONFIG_DEBUG_FS
> >  extern struct dentry *acpi_debugfs_dir;
> > @@ -133,6 +135,7 @@ int acpi_bus_register_early_device(int t
> >  const struct acpi_device *acpi_companion_match(const struct device *dev);
> >  int __acpi_device_uevent_modalias(const struct acpi_device *adev,
> >  				  struct kobj_uevent_env *env);
> > +bool acpi_device_is_processor(const struct acpi_device *adev);
> >  
> >  /* --------------------------------------------------------------------------
> >                                    Power Resource
> > Index: linux-pm/drivers/acpi/scan.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -1938,6 +1938,19 @@ static bool acpi_scan_handler_matching(s
> >  	return false;
> >  }
> >  
> > +bool acpi_scan_check_handler(const struct acpi_device *adev,
> > +			     struct acpi_scan_handler *handler)
> > +{
> > +	struct acpi_hardware_id *hwid;
> > +
> > +	list_for_each_entry(hwid, &adev->pnp.ids, list) {
> > +		if (acpi_scan_handler_matching(handler, hwid->id, NULL))
> > +			return true;
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  static struct acpi_scan_handler *acpi_scan_match_handler(const char *idstr,
> >  					const struct acpi_device_id **matchid)
> >  {
> > @@ -2410,7 +2423,16 @@ bool acpi_dev_ready_for_enumeration(cons
> >  	if (device->flags.honor_deps && device->dep_unmet)
> >  		return false;
> >  
> > -	return acpi_device_is_present(device);
> > +	if (device->status.functional)
> > +		return true;
> > +
> > +	if (!device->status.present)
> > +		return false;
> > +
> > +	if (device->status.enabled)
> > +		return true; /* Fast path. */
> > +
> > +	return !acpi_device_is_processor(device);
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
> >  
> > 
> > 
> >   
> 
> 
> _______________________________________________
> 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-11 10:19 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 [this message]
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
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=20240111101949.000075dc@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=linux@armlinux.org.uk \
    --cc=loongarch@lists.linux.dev \
    --cc=rafael@kernel.org \
    --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 NNTP newsgroup(s).