| Message ID | a1e20de53156f50385c7609507982f08866e859b.1706603678.git.haibo1.xu@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add ACPI NUMA support for RISC-V | expand |
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 <haibo1.xu@intel.com> > --- > 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 >
On Tue, Mar 5, 2024 at 12:42 PM Sunil V L <sunilvl@ventanamicro.com> 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 <haibo1.xu@intel.com> > > --- > > 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 > >
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)
Add RINTC affinity structure handler during parsing SRAT table. The ARCH specific implementation will be added in next patch. Signed-off-by: Haibo Xu <haibo1.xu@intel.com> --- drivers/acpi/numa/srat.c | 32 +++++++++++++++++++++++++++++++- include/linux/acpi.h | 3 +++ 2 files changed, 34 insertions(+), 1 deletion(-)