2024-01-31 02:29:35

by Haibo Xu

[permalink] [raw]
Subject: [PATCH 0/4] Add ACPI NUMA support for RISC-V

This patch series enable RISC-V ACPI NUMA support which was based on
the recently approved ACPI ECR[1].

Patch 1/4 is generated from the acpica PR[2] and should be merged through
the acpica project. Due to this dependency, other 3 patches can only be
merged after the corresponding ACPICA patch was pulled into linux.

Patch 2/4 add the common SRAT RINTC affinity structure handler.
Patch 3/4 add RISC-V specific acpi_numa.c file to parse NUMA information
from SRAT and SLIT ACPI tables.
Patch 4/4 add corresponding ACPI_NUMA config for RISC-V Kconfig.

Based-on: https://github.com/linux-riscv/linux-riscv/tree/for-next

[1] https://mantis.uefi.org/mantis/view.php?id=2433
[2] https://github.com/acpica/acpica/pull/926

Testing:
Since the ACPI AIA/PLIC support patch set is still under upstream review,
hence it is tested using the poll based HVC SBI console and RAM disk.
1) Build latest Qemu with the following patch backported
https://lore.kernel.org/all/[email protected]/
https://github.com/vlsunil/qemu/commit/42bd4eeefd5d4410a68f02d54fee406d8a1269b0

2) Build latest EDK-II
https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/README.md

3) Build Linux with the following configs enabled
CONFIG_RISCV_SBI_V01=y
CONFIG_SERIAL_EARLYCON_RISCV_SBI=y
CONFIG_HVC_RISCV_SBI=y

4) Build buildroot rootfs.cpio

5) Launch the Qemu machine
qemu-system-riscv64 -nographic \
-machine virt,pflash0=pflash0,pflash1=pflash1 -smp 4 -m 8G \
-blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
-blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
-object memory-backend-ram,size=4G,id=m0 \
-object memory-backend-ram,size=4G,id=m1 \
-numa node,memdev=m0,cpus=0-1,nodeid=0 \
-numa node,memdev=m1,cpus=2-3,nodeid=1 \
-numa dist,src=0,dst=1,val=30 \
-kernel linux/arch/riscv/boot/Image \
-initrd buildroot/output/images/rootfs.cpio \
-append "root=/dev/ram ro console=hvc0 earlycon=sbi"

[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x80000000-0x17fffffff]
[ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x180000000-0x27fffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x17fe3bc40-0x17fe3cfff]
[ 0.000000] NUMA: NODE_DATA [mem 0x27fff4c40-0x27fff5fff]
..
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> HARTID 0x0 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> HARTID 0x1 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> HARTID 0x2 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> HARTID 0x3 -> Node 1

Haibo Xu (4):
ACPICA: SRAT: Add RISC-V RINTC affinity structure
ACPI: NUMA: Add handler for SRAT RINTC affinity structure
ACPI: RISCV: Add NUMA support based on SRAT and SLIT
ACPI: RISCV: Enable ACPI based NUMA

arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/acpi.h | 15 +++-
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/acpi.c | 5 --
arch/riscv/kernel/acpi_numa.c | 133 ++++++++++++++++++++++++++++++++++
arch/riscv/kernel/setup.c | 4 +-
arch/riscv/kernel/smpboot.c | 2 -
drivers/acpi/numa/Kconfig | 2 +-
drivers/acpi/numa/srat.c | 35 ++++++++-
include/acpi/actbl3.h | 18 ++++-
include/linux/acpi.h | 7 ++
11 files changed, 209 insertions(+), 14 deletions(-)
create mode 100644 arch/riscv/kernel/acpi_numa.c

--
2.34.1



2024-01-31 02:32:35

by Haibo Xu

[permalink] [raw]
Subject: [PATCH 2/4] ACPI: NUMA: Add handler for SRAT RINTC affinity structure

Add RINTC affinity structure handler during parsing SRAT table.
The ARCH specific implementation will be added in next patch.

Signed-off-by: Haibo Xu <[email protected]>
---
drivers/acpi/numa/srat.c | 32 +++++++++++++++++++++++++++++++-
include/linux/acpi.h | 3 +++
2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 0214518fc582..503abcf6125d 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -165,6 +165,19 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
}
}
break;
+
+ case ACPI_SRAT_TYPE_RINTC_AFFINITY:
+ {
+ struct acpi_srat_rintc_affinity *p =
+ (struct acpi_srat_rintc_affinity *)header;
+ pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_RINTC_ENABLED) ?
+ "enabled" : "disabled");
+ }
+ break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
@@ -448,6 +461,21 @@ acpi_parse_gi_affinity(union acpi_subtable_headers *header,
}
#endif /* defined(CONFIG_X86) || defined (CONFIG_ARM64) */

+static int __init
+acpi_parse_rintc_affinity(union acpi_subtable_headers *header,
+ const unsigned long end)
+{
+ struct acpi_srat_rintc_affinity *rintc_affinity;
+
+ rintc_affinity = (struct acpi_srat_rintc_affinity *)header;
+ acpi_table_print_srat_entry(&header->common);
+
+ /* let architecture-dependent part to do it */
+ acpi_numa_rintc_affinity_init(rintc_affinity);
+
+ return 0;
+}
+
static int __initdata parsed_numa_memblks;

static int __init
@@ -501,7 +529,7 @@ int __init acpi_numa_init(void)

/* SRAT: System Resource Affinity Table */
if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
- struct acpi_subtable_proc srat_proc[4];
+ struct acpi_subtable_proc srat_proc[5];

memset(srat_proc, 0, sizeof(srat_proc));
srat_proc[0].id = ACPI_SRAT_TYPE_CPU_AFFINITY;
@@ -512,6 +540,8 @@ int __init acpi_numa_init(void)
srat_proc[2].handler = acpi_parse_gicc_affinity;
srat_proc[3].id = ACPI_SRAT_TYPE_GENERIC_AFFINITY;
srat_proc[3].handler = acpi_parse_gi_affinity;
+ srat_proc[4].id = ACPI_SRAT_TYPE_RINTC_AFFINITY;
+ srat_proc[4].handler = acpi_parse_rintc_affinity;

acpi_table_parse_entries_array(ACPI_SIG_SRAT,
sizeof(struct acpi_table_srat),
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b7165e52b3c6..a65273db55c6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -269,6 +269,9 @@ acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }

int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);

+static inline void
+acpi_numa_rintc_affinity_init(struct acpi_srat_rintc_affinity *pa) { }
+
#ifndef PHYS_CPUID_INVALID
typedef u32 phys_cpuid_t;
#define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
--
2.34.1


2024-03-05 02:41:44

by Haibo Xu

[permalink] [raw]
Subject: Re: [PATCH 0/4] Add ACPI NUMA support for RISC-V

Hi Sunil,

Could you help review this patch set?

Thanks,
Haibo

On Wed, Jan 31, 2024 at 10:18 AM Haibo Xu <[email protected]> wrote:
>
> This patch series enable RISC-V ACPI NUMA support which was based on
> the recently approved ACPI ECR[1].
>
> Patch 1/4 is generated from the acpica PR[2] and should be merged through
> the acpica project. Due to this dependency, other 3 patches can only be
> merged after the corresponding ACPICA patch was pulled into linux.
>
> Patch 2/4 add the common SRAT RINTC affinity structure handler.
> Patch 3/4 add RISC-V specific acpi_numa.c file to parse NUMA information
> from SRAT and SLIT ACPI tables.
> Patch 4/4 add corresponding ACPI_NUMA config for RISC-V Kconfig.
>
> Based-on: https://github.com/linux-riscv/linux-riscv/tree/for-next
>
> [1] https://mantis.uefi.org/mantis/view.php?id=2433
> [2] https://github.com/acpica/acpica/pull/926
>
> Testing:
> Since the ACPI AIA/PLIC support patch set is still under upstream review,
> hence it is tested using the poll based HVC SBI console and RAM disk.
> 1) Build latest Qemu with the following patch backported
> https://lore.kernel.org/all/[email protected]/
> https://github.com/vlsunil/qemu/commit/42bd4eeefd5d4410a68f02d54fee406d8a1269b0
>
> 2) Build latest EDK-II
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/READMEmd
>
> 3) Build Linux with the following configs enabled
> CONFIG_RISCV_SBI_V01=y
> CONFIG_SERIAL_EARLYCON_RISCV_SBI=y
> CONFIG_HVC_RISCV_SBI=y
>
> 4) Build buildroot rootfs.cpio
>
> 5) Launch the Qemu machine
> qemu-system-riscv64 -nographic \
> -machine virt,pflash0=pflash0,pflash1=pflash1 -smp 4 -m 8G \
> -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
> -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARSfd \
> -object memory-backend-ram,size=4G,id=m0 \
> -object memory-backend-ram,size=4G,id=m1 \
> -numa node,memdev=m0,cpus=0-1,nodeid=0 \
> -numa node,memdev=m1,cpus=2-3,nodeid=1 \
> -numa dist,src=0,dst=1,val=30 \
> -kernel linux/arch/riscv/boot/Image \
> -initrd buildroot/output/images/rootfs.cpio \
> -append "root=/dev/ram ro console=hvc0 earlycon=sbi"
>
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x80000000-0x17fffffff]
> [ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x180000000-0x27fffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fe3bc40-0x17fe3cfff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x27fff4c40-0x27fff5fff]
> ...
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> HARTID 0x0 -> Node 0
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> HARTID 0x1 -> Node 0
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> HARTID 0x2 -> Node 1
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> HARTID 0x3 -> Node 1
>
> Haibo Xu (4):
> ACPICA: SRAT: Add RISC-V RINTC affinity structure
> ACPI: NUMA: Add handler for SRAT RINTC affinity structure
> ACPI: RISCV: Add NUMA support based on SRAT and SLIT
> ACPI: RISCV: Enable ACPI based NUMA
>
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/acpi.h | 15 +++-
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/acpi.c | 5 --
> arch/riscv/kernel/acpi_numa.c | 133 ++++++++++++++++++++++++++++++++++
> arch/riscv/kernel/setup.c | 4 +-
> arch/riscv/kernel/smpboot.c | 2 -
> drivers/acpi/numa/Kconfig | 2 +-
> drivers/acpi/numa/srat.c | 35 ++++++++-
> include/acpi/actbl3.h | 18 ++++-
> include/linux/acpi.h | 7 ++
> 11 files changed, 209 insertions(+), 14 deletions(-)
> create mode 100644 arch/riscv/kernel/acpi_numa.c
>
> --
> 2.34.1
>

2024-03-05 04:42:21

by Sunil V L

[permalink] [raw]
Subject: Re: [PATCH 2/4] ACPI: NUMA: Add handler for SRAT RINTC affinity structure

Hi Haibo,

On Wed, Jan 31, 2024 at 10:31:59AM +0800, Haibo Xu wrote:
> Add RINTC affinity structure handler during parsing SRAT table.
> The ARCH specific implementation will be added in next patch.
>
> Signed-off-by: Haibo Xu <[email protected]>
> ---
> drivers/acpi/numa/srat.c | 32 +++++++++++++++++++++++++++++++-
> include/linux/acpi.h | 3 +++
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0214518fc582..503abcf6125d 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -165,6 +165,19 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
> }
> }
> break;
> +
> + case ACPI_SRAT_TYPE_RINTC_AFFINITY:
> + {
> + struct acpi_srat_rintc_affinity *p =
> + (struct acpi_srat_rintc_affinity *)header;
> + pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
> + p->acpi_processor_uid,
> + p->proximity_domain,
> + (p->flags & ACPI_SRAT_RINTC_ENABLED) ?
> + "enabled" : "disabled");
> + }
> + break;
> +
> default:
> pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
> header->type);
> @@ -448,6 +461,21 @@ acpi_parse_gi_affinity(union acpi_subtable_headers *header,
> }
> #endif /* defined(CONFIG_X86) || defined (CONFIG_ARM64) */
>
> +static int __init
> +acpi_parse_rintc_affinity(union acpi_subtable_headers *header,
> + const unsigned long end)
Alignment doesn't look right. Could you please run checkpatch on all
the patches?

> +{
> + struct acpi_srat_rintc_affinity *rintc_affinity;
> +
> + rintc_affinity = (struct acpi_srat_rintc_affinity *)header;
> + acpi_table_print_srat_entry(&header->common);
> +
> + /* let architecture-dependent part to do it */
> + acpi_numa_rintc_affinity_init(rintc_affinity);
> +
Is it required to have this commit first prior to architecture
functionality? I am wondering whether it is logically better to
implement the function first and then consume in next commit?

> + return 0;
> +}
> +
> static int __initdata parsed_numa_memblks;
>
> static int __init
> @@ -501,7 +529,7 @@ int __init acpi_numa_init(void)
>
> /* SRAT: System Resource Affinity Table */
> if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
> - struct acpi_subtable_proc srat_proc[4];
> + struct acpi_subtable_proc srat_proc[5];
>
> memset(srat_proc, 0, sizeof(srat_proc));
> srat_proc[0].id = ACPI_SRAT_TYPE_CPU_AFFINITY;
> @@ -512,6 +540,8 @@ int __init acpi_numa_init(void)
> srat_proc[2].handler = acpi_parse_gicc_affinity;
> srat_proc[3].id = ACPI_SRAT_TYPE_GENERIC_AFFINITY;
> srat_proc[3].handler = acpi_parse_gi_affinity;
> + srat_proc[4].id = ACPI_SRAT_TYPE_RINTC_AFFINITY;
> + srat_proc[4].handler = acpi_parse_rintc_affinity;
>
> acpi_table_parse_entries_array(ACPI_SIG_SRAT,
> sizeof(struct acpi_table_srat),
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index b7165e52b3c6..a65273db55c6 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -269,6 +269,9 @@ acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
>
> int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
>
> +static inline void
> +acpi_numa_rintc_affinity_init(struct acpi_srat_rintc_affinity *pa) { }
> +
I think this can be fit in single like as we can have upto 100
characters.

> #ifndef PHYS_CPUID_INVALID
> typedef u32 phys_cpuid_t;
> #define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
> --
> 2.34.1
>

2024-03-05 04:44:36

by Sunil V L

[permalink] [raw]
Subject: Re: [PATCH 0/4] Add ACPI NUMA support for RISC-V

Hi Haibo,
On Wed, Jan 31, 2024 at 10:31:57AM +0800, Haibo Xu wrote:
> This patch series enable RISC-V ACPI NUMA support which was based on
> the recently approved ACPI ECR[1].
>
> Patch 1/4 is generated from the acpica PR[2] and should be merged through
> the acpica project. Due to this dependency, other 3 patches can only be
> merged after the corresponding ACPICA patch was pulled into linux.
>
> Patch 2/4 add the common SRAT RINTC affinity structure handler.
> Patch 3/4 add RISC-V specific acpi_numa.c file to parse NUMA information
> from SRAT and SLIT ACPI tables.
> Patch 4/4 add corresponding ACPI_NUMA config for RISC-V Kconfig.
>
> Based-on: https://github.com/linux-riscv/linux-riscv/tree/for-next
>
> [1] https://mantis.uefi.org/mantis/view.php?id=2433

Please avoid providing mantis link. It is not useful for people who are
not UEFI members. Better to provide the link to the PDF version of the
ECR approved.

Thanks,
Sunil

2024-03-05 07:42:56

by Haibo Xu

[permalink] [raw]
Subject: Re: [PATCH 0/4] Add ACPI NUMA support for RISC-V

On Tue, Mar 5, 2024 at 12:44 PM Sunil V L <[email protected]> wrote:
>
> Hi Haibo,
> On Wed, Jan 31, 2024 at 10:31:57AM +0800, Haibo Xu wrote:
> > This patch series enable RISC-V ACPI NUMA support which was based on
> > the recently approved ACPI ECR[1].
> >
> > Patch 1/4 is generated from the acpica PR[2] and should be merged through
> > the acpica project. Due to this dependency, other 3 patches can only be
> > merged after the corresponding ACPICA patch was pulled into linux.
> >
> > Patch 2/4 add the common SRAT RINTC affinity structure handler.
> > Patch 3/4 add RISC-V specific acpi_numa.c file to parse NUMA information
> > from SRAT and SLIT ACPI tables.
> > Patch 4/4 add corresponding ACPI_NUMA config for RISC-V Kconfig.
> >
> > Based-on: https://github.com/linux-riscv/linux-riscv/tree/for-next
> >
> > [1] https://mantis.uefi.org/mantis/view.php?id=2433
>
> Please avoid providing mantis link. It is not useful for people who are
> not UEFI members. Better to provide the link to the PDF version of the
> ECR approved.
>

Sure. Will update with a PDF link in v2.

Thanks,
Haibo

> Thanks,
> Sunil

2024-03-05 08:43:01

by Haibo Xu

[permalink] [raw]
Subject: Re: [PATCH 2/4] ACPI: NUMA: Add handler for SRAT RINTC affinity structure

On Tue, Mar 5, 2024 at 12:42 PM Sunil V L <[email protected]> wrote:
>
> Hi Haibo,
>
> On Wed, Jan 31, 2024 at 10:31:59AM +0800, Haibo Xu wrote:
> > Add RINTC affinity structure handler during parsing SRAT table.
> > The ARCH specific implementation will be added in next patch.
> >
> > Signed-off-by: Haibo Xu <[email protected]>
> > ---
> > drivers/acpi/numa/srat.c | 32 +++++++++++++++++++++++++++++++-
> > include/linux/acpi.h | 3 +++
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > index 0214518fc582..503abcf6125d 100644
> > --- a/drivers/acpi/numa/srat.c
> > +++ b/drivers/acpi/numa/srat.c
> > @@ -165,6 +165,19 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
> > }
> > }
> > break;
> > +
> > + case ACPI_SRAT_TYPE_RINTC_AFFINITY:
> > + {
> > + struct acpi_srat_rintc_affinity *p =
> > + (struct acpi_srat_rintc_affinity *)header;
> > + pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
> > + p->acpi_processor_uid,
> > + p->proximity_domain,
> > + (p->flags & ACPI_SRAT_RINTC_ENABLED) ?
> > + "enabled" : "disabled");
> > + }
> > + break;
> > +
> > default:
> > pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
> > header->type);
> > @@ -448,6 +461,21 @@ acpi_parse_gi_affinity(union acpi_subtable_headers *header,
> > }
> > #endif /* defined(CONFIG_X86) || defined (CONFIG_ARM64) */
> >
> > +static int __init
> > +acpi_parse_rintc_affinity(union acpi_subtable_headers *header,
> > + const unsigned long end)
> Alignment doesn't look right. Could you please run checkpatch on all
> the patches?
>

Seems something is wrong with my vim configuration.
Will fix it in v2.

> > +{
> > + struct acpi_srat_rintc_affinity *rintc_affinity;
> > +
> > + rintc_affinity = (struct acpi_srat_rintc_affinity *)header;
> > + acpi_table_print_srat_entry(&header->common);
> > +
> > + /* let architecture-dependent part to do it */
> > + acpi_numa_rintc_affinity_init(rintc_affinity);
> > +
> Is it required to have this commit first prior to architecture
> functionality? I am wondering whether it is logically better to
> implement the function first and then consume in next commit?
>

No dependency between this commit and the next commit.
Will change the order in v2.

> > + return 0;
> > +}
> > +
> > static int __initdata parsed_numa_memblks;
> >
> > static int __init
> > @@ -501,7 +529,7 @@ int __init acpi_numa_init(void)
> >
> > /* SRAT: System Resource Affinity Table */
> > if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
> > - struct acpi_subtable_proc srat_proc[4];
> > + struct acpi_subtable_proc srat_proc[5];
> >
> > memset(srat_proc, 0, sizeof(srat_proc));
> > srat_proc[0].id = ACPI_SRAT_TYPE_CPU_AFFINITY;
> > @@ -512,6 +540,8 @@ int __init acpi_numa_init(void)
> > srat_proc[2].handler = acpi_parse_gicc_affinity;
> > srat_proc[3].id = ACPI_SRAT_TYPE_GENERIC_AFFINITY;
> > srat_proc[3].handler = acpi_parse_gi_affinity;
> > + srat_proc[4].id = ACPI_SRAT_TYPE_RINTC_AFFINITY;
> > + srat_proc[4].handler = acpi_parse_rintc_affinity;
> >
> > acpi_table_parse_entries_array(ACPI_SIG_SRAT,
> > sizeof(struct acpi_table_srat),
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index b7165e52b3c6..a65273db55c6 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -269,6 +269,9 @@ acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
> >
> > int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
> >
> > +static inline void
> > +acpi_numa_rintc_affinity_init(struct acpi_srat_rintc_affinity *pa) { }
> > +
> I think this can be fit in single like as we can have upto 100
> characters.
>

Sure. will fix it in v2.

Thanks,
Haibo

> > #ifndef PHYS_CPUID_INVALID
> > typedef u32 phys_cpuid_t;
> > #define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
> > --
> > 2.34.1
> >