public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: <rafael@kernel.org>, <lenb@kernel.org>, <robert.moore@intel.com>,
	<andrew@kernel.org>, <bfaccini@nvidia.com>,
	<eahariha@linux.microsoft.com>, <dan.j.williams@intel.com>,
	<thorsten.blum@linux.dev>, <gourry@gourry.net>,
	<nunodasneves@linux.microsoft.com>,
	<wangyuquan1236@phytium.com.cn>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <acpica-devel@lists.linux.dev>
Subject: Re: [PATCH] acpi,srat: Fix incorrect device handle check for Generic Initiator
Date: Wed, 10 Sep 2025 10:57:29 +0100	[thread overview]
Message-ID: <20250910105729.000070a5@huawei.com> (raw)
In-Reply-To: <20250910093949.5793-1-xueshuai@linux.alibaba.com>

On Wed, 10 Sep 2025 17:39:49 +0800
Shuai Xue <xueshuai@linux.alibaba.com> wrote:

> The Generic Initiator Affinity Structure in SRAT table uses device
> handle type field to indicate the device type. According to ACPI
> specification, the device handle type value of 1 represents PCI device,
> not 0.
> 
> Fix this by defining explicit macros for device handle types and using
> the correct check for PCI devices:
> 
> - ACPI_SRAT_ACPI_DEVICE_HANDLE (0): ACPI device handle
> - ACPI_SRAT_PCI_DEVICE_HANDLE (1): PCI device handle
> 
> Fixes: 894c26a1c274 ("ACPI: Support Generic Initiator only domains")
> Reported-by: Wu Zongyong <wuzongyong@linux.alibaba.com>
> Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>

The actbl3.h additions need to go through acpcia and then have a link
tag in here to show that it was merged.  Perhaps just fix it with a number
for now and follow up with the acpcia stuff in the longer run?

Also note clearly this only affects a debug print - no functional bug.
That may change whether people choose to backport this or not.

I'm curious on whether you are thinking of wiring this up so that
we can set the appropriate nodes on PCI Devices other than by doing it
with _PXM().  For obscure reasons there can be references both ways
(so DSDT Device entry -> SRAT via _PXM, and SRAT -> Device via this field
of generic initiators).

For now we only implement the first one so all we need is a node to be
instantiated for the GI to sit in.

Come to think of it the fix that made PCI device entries in DSDT with _PXM
turn up in the right place was reverted (for a problem with broken firmware
on AMD threadripper systems - IIRC that I think is long solved).
Not sure if that path even works today and the one this code is about has
never been hooked up.

Thanks for the fix!

Jonathan


> ---
>  drivers/acpi/numa/srat.c | 2 +-
>  include/acpi/actbl3.h    | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 53816dfab645..de71b370a275 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -237,7 +237,7 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
>  		struct acpi_srat_generic_affinity *p =
>  			(struct acpi_srat_generic_affinity *)header;
>  
> -		if (p->device_handle_type == 0) {
> +		if (p->device_handle_type == ACPI_SRAT_PCI_DEVICE_HANDLE) {
>  			/*
>  			 * For pci devices this may be the only place they
>  			 * are assigned a proximity domain
> diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
> index 79d3aa5a4bad..c8488614429c 100644
> --- a/include/acpi/actbl3.h
> +++ b/include/acpi/actbl3.h
> @@ -284,6 +284,9 @@ struct acpi_srat_gic_its_affinity {
>   * 6: ACPI_SRAT_TYPE_GENERIC_PORT_AFFINITY
>   */
>  
> +#define ACPI_SRAT_APCI_DEVICE_HANDLE	(0)
> +#define ACPI_SRAT_PCI_DEVICE_HANDLE	(1)
> +
>  #define ACPI_SRAT_DEVICE_HANDLE_SIZE	16
>  
>  struct acpi_srat_generic_affinity {


  reply	other threads:[~2025-09-10  9:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10  9:39 [PATCH] acpi,srat: Fix incorrect device handle check for Generic Initiator Shuai Xue
2025-09-10  9:57 ` Jonathan Cameron [this message]
2025-09-11  4:28   ` Shuai Xue
2025-09-11  9:11     ` Jonathan Cameron
2025-09-13  2:35       ` Shuai Xue

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=20250910105729.000070a5@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=andrew@kernel.org \
    --cc=bfaccini@nvidia.com \
    --cc=dan.j.williams@intel.com \
    --cc=eahariha@linux.microsoft.com \
    --cc=gourry@gourry.net \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nunodasneves@linux.microsoft.com \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=thorsten.blum@linux.dev \
    --cc=wangyuquan1236@phytium.com.cn \
    --cc=xueshuai@linux.alibaba.com \
    /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