Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1315557 > unrolled thread

[PATCH v3 00/12] ACPI NUMA support for ARM64

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 00/12] ACPI NUMA support for ARM64 Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
    [PATCH v3 08/12] arm64, numa: rework numa_add_memblk() Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
      Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk() Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-25 11:10 +0100
        Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk() Hanjun Guo <guohanjun@huawei.com> - 2016-01-27 07:30 +0100
    [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
      Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-25 11:30 +0100
        Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Hanjun Guo <guohanjun@huawei.com> - 2016-01-27 08:20 +0100
          Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-27 15:40 +0100
            Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Hanjun Guo <guohanjun@huawei.com> - 2016-01-28 04:20 +0100
      Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Robert Richter <robert.richter@caviumnetworks.com> - 2016-02-01 19:20 +0100
        Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Hanjun Guo <hanjun.guo@linaro.org> - 2016-02-02 12:40 +0100
          Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT  and SLIT Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-02-02 18:00 +0100
    [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init() Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
      Re: [PATCH v3 12/12] acpi, numa: reuse  acpi_numa_memory_affinity_init() Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-25 11:30 +0100
        Re: [PATCH v3 12/12] acpi, numa: reuse  acpi_numa_memory_affinity_init() Hanjun Guo <guohanjun@huawei.com> - 2016-01-27 07:20 +0100
          Re: [PATCH v3 12/12] acpi, numa: reuse  acpi_numa_memory_affinity_init() Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-27 15:20 +0100
            Re: [PATCH v3 12/12] acpi, numa: reuse  acpi_numa_memory_affinity_init() Hanjun Guo <guohanjun@huawei.com> - 2016-01-28 03:50 +0100
              Re: [PATCH v3 12/12] acpi, numa: reuse  acpi_numa_memory_affinity_init() Robert Richter <robert.richter@caviumnetworks.com> - 2016-01-28 14:40 +0100
    [PATCH v3 10/12] acpi, numa: move bad_srat() and srat_disabled() to common place Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
    [PATCH v3 02/12] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug() Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100
    [PATCH v3 07/12] acpi, numa: move acpi_numa_slit_init() to common place Hanjun Guo <guohanjun@huawei.com> - 2016-01-23 10:50 +0100

Page 1 of 2  [1] 2  Next page →

#1315557 — [PATCH v3 00/12] ACPI NUMA support for ARM64

From: Hanjun Guo <hanjun.guo@linaro.org>

Based on Ganapat's v9 dt based NUMA patch set [1] for ARM64, this
patch set introduce the ACPI based configuration to provide
NUMA information.

ACPI 5.1 already introduced NUMA support for ARM64, which can
get the NUMA domain information from SRAT and SLIT table, so
parse those two tables to get mappings from cpu/mem to numa
node configration and system locality.

v3 updates:
 - Deep investigation about the ACPI_DEBUG_PRINT() and remvoe
   that for acpi/numa.c (patch 2/12)

 - Remove the duplicate NULL check for table print (patch 3/12)

 - Introduce CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP to remove duplicate
   dummy function for acpi_numa_arch_fixup()

 - Solve the problem that the mapping from logical cpu to numa node
   is wrong which spotted out by Lorenzo

 - cleanups for x86 and move acpi_numa_slit_init() and some other
   functions to common place, then reduce the duplicate of x86
   and arm64 (patch 7-12/12).

 - rebased on top of 4.4 and Ganapat's v9 patch set.

This patch set was tested By Ganapat on Cavium Thunder-X, it works
fine.

[1]: http://lwn.net/Articles/672329/

Thanks
Hanjun

Hanjun Guo (12):
  acpi, numa: Use pr_fmt() instead of printk
  acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
  acpi, numa: remove duplicate NULL check
  acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
  arm64, acpi, numa: NUMA support based on SRAT and SLIT
  acpi, numa: Enable ACPI based NUMA on ARM64
  acpi, numa: move acpi_numa_slit_init() to common place
  arm64, numa: rework numa_add_memblk()
  x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
  acpi, numa: move bad_srat() and srat_disabled() to common place
  acpi, numa: remove unneeded acpi_numa=1
  acpi, numa: reuse acpi_numa_memory_affinity_init()

 arch/arm64/include/asm/acpi.h |   8 ++
 arch/arm64/include/asm/numa.h |   3 +
 arch/arm64/kernel/Makefile    |   1 +
 arch/arm64/kernel/acpi_numa.c | 149 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/of_numa.c   |   2 +-
 arch/arm64/kernel/smp.c       |   3 +
 arch/arm64/mm/numa.c          |  17 ++--
 arch/ia64/Kconfig             |   1 +
 arch/x86/include/asm/acpi.h   |   1 -
 arch/x86/mm/numa.c            |   2 +-
 arch/x86/mm/srat.c            | 113 +----------------------
 drivers/acpi/Kconfig          |   5 +-
 drivers/acpi/numa.c           | 202 +++++++++++++++++++++++++++++++-----------
 include/acpi/acpi_numa.h      |  12 +++
 include/linux/acpi.h          |  22 ++++-
 15 files changed, 365 insertions(+), 176 deletions(-)
 create mode 100644 arch/arm64/kernel/acpi_numa.c

-- 
1.9.1

[toc] | [next] | [standalone]

#1315558 — [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

From: Hanjun Guo <hanjun.guo@linaro.org>

Rework numa_add_memblk() to update the parameter "u64 size"
to "u64 end", this will make it consistent with x86 and
can simplify the code later.

Updates for arch/arm64/mm/numa.c should squash to core NUMA
patches from Ganapat.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi_numa.c |  2 +-
 arch/arm64/kernel/of_numa.c   |  2 +-
 arch/arm64/mm/numa.c          | 12 ++++++------
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 15fb935..3bcf058 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -184,7 +184,7 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 		node, pxm,
 		(unsigned long long) start, (unsigned long long) end - 1);
 
-	if (numa_add_memblk(node, start, (end - start)) < 0) {
+	if (numa_add_memblk(node, start, end) < 0) {
 		bad_srat();
 		return -EINVAL;
 	}
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
index 2f9e34b..aa6f3a3 100644
--- a/arch/arm64/kernel/of_numa.c
+++ b/arch/arm64/kernel/of_numa.c
@@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
 		pr_debug("NUMA-DT:  base = %llx , node = %u\n",
 				base, nid);
 
-		if (numa_add_memblk(nid, base, size) < 0)
+		if (numa_add_memblk(nid, base, base + size) < 0)
 			return -EINVAL;
 	}
 
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e974995..2b04b8a 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
  * numa_add_memblk - Set node id to memblk
  * @nid: NUMA node ID of the new memblk
  * @start: Start address of the new memblk
- * @size:  Size of the new memblk
+ * @end:  End address of the new memblk
  *
  * RETURNS:
  * 0 on success, -errno on failure.
  */
-int __init numa_add_memblk(int nid, u64 start, u64 size)
+int __init numa_add_memblk(int nid, u64 start, u64 end)
 {
 	int ret;
 
-	ret = memblock_set_node(start, size, &memblock.memory, nid);
+	ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
 	if (ret < 0) {
 		pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
-			start, (start + size - 1), nid);
+			start, (end - 1), nid);
 		return ret;
 	}
 
 	node_set(nid, numa_nodes_parsed);
 	pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
-			start, (start + size - 1), nid);
+			start, (end - 1), nid);
 	return ret;
 }
 EXPORT_SYMBOL(numa_add_memblk);
@@ -366,7 +366,7 @@ static int __init dummy_numa_init(void)
 	       0LLU, PFN_PHYS(max_pfn) - 1);
 
 	for_each_memblock(memory, mblk) {
-		ret = numa_add_memblk(0, mblk->base, mblk->size);
+		ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
 		if (unlikely(ret < 0))
 			return ret;
 	}
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1316411 — Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

On 23.01.16 17:39:23, Hanjun Guo wrote:
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.

> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>  		pr_debug("NUMA-DT:  base = %llx , node = %u\n",
>  				base, nid);
>  
> -		if (numa_add_memblk(nid, base, size) < 0)
> +		if (numa_add_memblk(nid, base, base + size) < 0)

The overall function usage looks more like as it should use size
instead of end. Even in the x86 implementation end is calculated from
base + size. So better change x86 code to use size instead.

Though this might involve to change the interface for
numa_add_memblk_to() for unifcation too.

-Robert

[toc] | [prev] | [next] | [standalone]

#1318700 — Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

On 2016/1/25 17:34, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>>  		pr_debug("NUMA-DT:  base = %llx , node = %u\n",
>>  				base, nid);
>>  
>> -		if (numa_add_memblk(nid, base, size) < 0)
>> +		if (numa_add_memblk(nid, base, base + size) < 0)
> The overall function usage looks more like as it should use size
> instead of end. Even in the x86 implementation end is calculated from
> base + size. So better change x86 code to use size instead.
>
> Though this might involve to change the interface for
> numa_add_memblk_to() for unifcation too.
>

This should be a minor one, I'm fine with both directions, I will
stay for a few days to get more review comments, if no objections,
I will update.

Thanks
Hanjun

[toc] | [prev] | [next] | [standalone]

#1315559 — [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

From: Hanjun Guo <hanjun.guo@linaro.org>

Introduce a new file to hold ACPI based NUMA information
parsing from SRAT and SLIT.

SRAT includes the CPU ACPI ID to Proximity Domain mappings
and memory ranges to Proximity Domain mapping.
SLIT has the information of inter node
distances(relative number for access latency).

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
 arch/arm64/include/asm/acpi.h |   8 ++
 arch/arm64/include/asm/numa.h |   3 +
 arch/arm64/kernel/Makefile    |   1 +
 arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/smp.c       |   3 +
 arch/arm64/mm/numa.c          |   5 +-
 6 files changed, 252 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/kernel/acpi_numa.c

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..6db9c6f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
 pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
 #endif
 
+#ifdef CONFIG_ACPI_NUMA
+int arm64_acpi_numa_init(void);
+void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
+#else
+static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
+static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
+#endif /* CONFIG_ACPI_NUMA */
+
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 54deb38..1beb194 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -6,6 +6,8 @@
 
 #ifdef CONFIG_NUMA
 
+#define NR_NODE_MEMBLKS		(MAX_NUMNODES * 2)
+
 /* currently, arm64 implements flat NUMA topology */
 #define parent_node(node)	(node)
 
@@ -43,6 +45,7 @@ struct device_node;
 int __init arm64_of_numa_init(void);
 void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
 #else
+static inline int arm64_of_numa_init(void) { return -ENODEV; }
 static inline void of_numa_set_node_info(unsigned int cpu,
 		struct device_node *dn) { }
 #endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7987763..555c4a5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 arm64-obj-$(CONFIG_OF_NUMA)		+= of_numa.o
+arm64-obj-$(CONFIG_ACPI_NUMA)		+= acpi_numa.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
new file mode 100644
index 0000000..f7f7533
--- /dev/null
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -0,0 +1,235 @@
+/*
+ * ACPI 5.1 based NUMA setup for ARM64
+ * Lots of code was borrowed from arch/x86/mm/srat.c
+ *
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ * Copyright (C) 2013-2016, Linaro Ltd.
+ *		Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#define pr_fmt(fmt) "ACPI: NUMA: " fmt
+
+#include <linux/acpi.h>
+#include <linux/bitmap.h>
+#include <linux/bootmem.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/memblock.h>
+#include <linux/mmzone.h>
+#include <linux/module.h>
+#include <linux/topology.h>
+
+#include <acpi/processor.h>
+#include <asm/numa.h>
+
+int acpi_numa __initdata;
+static int cpus_in_srat;
+
+struct __node_cpu_hwid {
+	u32 node_id;    /* logical node containing this CPU */
+	u64 cpu_hwid;   /* MPIDR for this CPU */
+};
+
+static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
+[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
+
+static __init void bad_srat(void)
+{
+	pr_err("SRAT not used.\n");
+	acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+	return acpi_numa < 0;
+}
+
+void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
+{
+	int nid = 0, i;
+
+	for (i = 0; i < cpus_in_srat; i++) {
+		if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
+			nid = early_node_cpu_hwid[i].node_id;
+			break;
+		}
+	}
+
+	cpu_to_node_map[cpu] = nid;
+}
+
+/*
+ * Callback for SLIT parsing.
+ * It will get the distance information presented by SLIT
+ * and init the distance matrix of numa nodes
+ */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+	int i, j;
+
+	for (i = 0; i < slit->locality_count; i++) {
+		const int from_node = pxm_to_node(i);
+
+		if (from_node == NUMA_NO_NODE)
+			continue;
+
+		for (j = 0; j < slit->locality_count; j++) {
+			const int to_node = pxm_to_node(j);
+
+			if (to_node == NUMA_NO_NODE)
+				continue;
+
+			pr_debug("SLIT: Distance[%d][%d] = %d\n",
+					from_node, to_node,
+					slit->entry[
+					slit->locality_count * i + j]);
+			numa_set_distance(from_node, to_node,
+				slit->entry[slit->locality_count * i + j]);
+		}
+	}
+}
+
+static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
+{
+	unsigned long madt_end, entry;
+	struct acpi_table_madt *madt;
+	acpi_size tbl_size;
+
+	if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
+			(struct acpi_table_header **)&madt, &tbl_size)))
+		return -ENODEV;
+
+	entry = (unsigned long)madt;
+	madt_end = entry + madt->header.length;
+
+	/* Parse all entries looking for a match. */
+	entry += sizeof(struct acpi_table_madt);
+	while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+		struct acpi_subtable_header *header =
+			(struct acpi_subtable_header *)entry;
+
+		if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+			struct acpi_madt_generic_interrupt *gicc =
+				container_of(header,
+				struct acpi_madt_generic_interrupt, header);
+
+			if ((gicc->flags & ACPI_MADT_ENABLED) &&
+			    (gicc->uid == acpi_id)) {
+				*mpidr = gicc->arm_mpidr;
+				early_acpi_os_unmap_memory(madt, tbl_size);
+				return 0;
+			}
+		}
+		entry += header->length;
+	}
+
+	early_acpi_os_unmap_memory(madt, tbl_size);
+	return -ENODEV;
+}
+
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
+{
+	int pxm, node;
+	u64 mpidr;
+
+	if (srat_disabled())
+		return;
+
+	if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+		bad_srat();
+		return;
+	}
+
+	if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+		return;
+
+	if (cpus_in_srat >= NR_CPUS) {
+		pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
+			     NR_CPUS);
+		return;
+	}
+
+	pxm = pa->proximity_domain;
+	node = acpi_map_pxm_to_node(pxm);
+
+	if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+		pr_err("SRAT: Too many proximity domains %d\n", pxm);
+		bad_srat();
+		return;
+	}
+
+	if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
+		pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+			pxm, pa->acpi_processor_uid);
+		bad_srat();
+		return;
+	}
+
+	early_node_cpu_hwid[cpus_in_srat].node_id = node;
+	early_node_cpu_hwid[cpus_in_srat].cpu_hwid =  mpidr;
+	node_set(node, numa_nodes_parsed);
+	acpi_numa = 1;
+	cpus_in_srat++;
+	pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+		pxm, mpidr, node, cpus_in_srat);
+}
+
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+	u64 start, end;
+	int node, pxm;
+
+	if (srat_disabled())
+		return -EINVAL;
+
+	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+		bad_srat();
+		return -EINVAL;
+	}
+
+	/* Ignore disabled entries */
+	if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
+		return -EINVAL;
+
+	start = ma->base_address;
+	end = start + ma->length;
+	pxm = ma->proximity_domain;
+
+	node = acpi_map_pxm_to_node(pxm);
+
+	if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+		pr_err("SRAT: Too many proximity domains.\n");
+		bad_srat();
+		return -EINVAL;
+	}
+
+	pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+		node, pxm,
+		(unsigned long long) start, (unsigned long long) end - 1);
+
+	if (numa_add_memblk(node, start, (end - start)) < 0) {
+		bad_srat();
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+int __init arm64_acpi_numa_init(void)
+{
+	int ret;
+
+	ret = acpi_numa_init();
+	if (ret)
+		return ret;
+
+	return srat_disabled() ? -EINVAL : 0;
+}
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a2a8c2d..112a892 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
 	/* map the logical cpu id to cpu MPIDR */
 	cpu_logical_map(cpu_count) = hwid;
 
+	/* map logical cpu to node */
+	acpi_numa_set_node_info(cpu_count, hwid);
+
 	cpu_count++;
 }
 
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9e8704b..e974995 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi.h>
 #include <linux/bootmem.h>
 #include <linux/ctype.h>
 #include <linux/init.h>
@@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
 {
 	int ret = -ENODEV;
 
-#ifdef CONFIG_OF_NUMA
 	if (!numa_off)
-		ret = numa_init(arm64_of_numa_init);
-#endif
+		ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
 
 	if (ret)
 		numa_init(dummy_numa_init);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1316442 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 23.01.16 17:39:20, Hanjun Guo wrote:
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c

> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> +	u64 start, end;
> +	int node, pxm;
> +
> +	if (srat_disabled())
> +		return -EINVAL;
> +
> +	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {

Must be:

	ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {

Allow extensions to struct acpi_srat_mem_affinity in newer versions.

> +		bad_srat();
> +		return -EINVAL;

We need a pr_err() here to avoid that numa setup fails silently due to
bad fw. This applies to all error paths.

See my delta patch below. You can merge it with your patch.

-Robert

> +	}


From 78945c73e4ec03756a135a75133ed29694a7a0f2 Mon Sep 17 00:00:00 2001
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Nov 2015 09:53:39 +0100
Subject: [PATCH] arm64, acpi, numa: Add error messages for bad SRAT tables

Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 arch/arm64/kernel/acpi_numa.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533761cd..936ad6c43740 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -143,6 +143,8 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
 		return;
 
 	if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+		pr_err("SRAT: Invalid SRAT header length: %d\n",
+			pa->header.length);
 		bad_srat();
 		return;
 	}
@@ -166,7 +168,7 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
 	}
 
 	if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
-		pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+		pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
 			pxm, pa->acpi_processor_uid);
 		bad_srat();
 		return;
@@ -190,7 +192,9 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 	if (srat_disabled())
 		return -EINVAL;
 
-	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+	if (ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
+		pr_err("SRAT: Unexpected header length: %d\n",
+			ma->header.length);
 		bad_srat();
 		return -EINVAL;
 	}
@@ -216,10 +220,17 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 		(unsigned long long) start, (unsigned long long) end - 1);
 
 	if (numa_add_memblk(node, start, (end - start)) < 0) {
+		pr_err("SRAT: Failed to add memblk to node %u [mem %#010Lx-%#010Lx]\n",
+			node, (unsigned long long) start,
+			(unsigned long long) end - 1);
 		bad_srat();
 		return -EINVAL;
 	}
 
+	pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+		node, pxm,
+		(unsigned long long) start, (unsigned long long) end - 1);
+
 	return 0;
 }
 
-- 
2.7.0.rc3

[toc] | [prev] | [next] | [standalone]

#1318710 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 2016/1/25 18:21, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>> new file mode 100644
>> index 0000000..f7f7533
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi_numa.c
>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>> +{
>> +	u64 start, end;
>> +	int node, pxm;
>> +
>> +	if (srat_disabled())
>> +		return -EINVAL;
>> +
>> +	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> Must be:
>
> 	ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>
> Allow extensions to struct acpi_srat_mem_affinity in newer versions.

Hmm, I think we need to remove the check here now.

There are three cases:

 - firmware ACPI version is consistent with the ACPICA one, then
   ma->header.length == sizeof(struct acpi_srat_mem_affinity )

 - firmware ACPI version is not consistent with the ACPICA one,
   for example, struct acpi_srat_mem_affinity is extended in
   new ACI version, but the formware is using the older one,
  then it's ok to use
  ma->header.length < sizeof(struct acpi_srat_mem_affinity )

 - but if we use the older kernel + updated new firmware,
   then
   ma->header.length > sizeof(struct acpi_srat_mem_affinity )
  will be the case, right?

>
>> +		bad_srat();
>> +		return -EINVAL;
> We need a pr_err() here to avoid that numa setup fails silently due to
> bad fw. This applies to all error paths.
>
> See my delta patch below. You can merge it with your patch.

Thanks! I wil merge it into next version.

Hanjun

[toc] | [prev] | [next] | [standalone]

#1319026 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 27.01.16 15:12:15, Hanjun Guo wrote:
> On 2016/1/25 18:21, Robert Richter wrote:
> > On 23.01.16 17:39:20, Hanjun Guo wrote:
> >> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> >> new file mode 100644
> >> index 0000000..f7f7533
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/acpi_numa.c
> >> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> >> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> >> +{
> >> +	u64 start, end;
> >> +	int node, pxm;
> >> +
> >> +	if (srat_disabled())
> >> +		return -EINVAL;
> >> +
> >> +	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> > Must be:
> >
> > 	ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
> >
> > Allow extensions to struct acpi_srat_mem_affinity in newer versions.
> 
> Hmm, I think we need to remove the check here now.

No, we might have an out-of-bound access then.

> 
> There are three cases:
> 
>  - firmware ACPI version is consistent with the ACPICA one, then
>    ma->header.length == sizeof(struct acpi_srat_mem_affinity )
> 
>  - firmware ACPI version is not consistent with the ACPICA one,
>    for example, struct acpi_srat_mem_affinity is extended in
>    new ACI version, but the formware is using the older one,
>   then it's ok to use
>   ma->header.length < sizeof(struct acpi_srat_mem_affinity )

The check above is ok as we need at least struct
acpi_srat_mem_affinity as it is now.

If we later change the kernel to support multiple versions of struct
acpi_srat_mem_affinity, i.e. use data from an extended section, we
will need to add code to handle that. This will include support of
data with length < acpi_srat_mem_affinity, in this case we may not use
extended data.

> 
>  - but if we use the older kernel + updated new firmware,
>    then
>    ma->header.length > sizeof(struct acpi_srat_mem_affinity )
>   will be the case, right?

Right, and this is a valid case not resulting in an error with my
suggestion above.

> 
> >
> >> +		bad_srat();
> >> +		return -EINVAL;
> > We need a pr_err() here to avoid that numa setup fails silently due to
> > bad fw. This applies to all error paths.
> >
> > See my delta patch below. You can merge it with your patch.
> 
> Thanks! I wil merge it into next version.

Thanks,

-Robert

[toc] | [prev] | [next] | [standalone]

#1320252 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 2016/1/27 22:01, Robert Richter wrote:
> On 27.01.16 15:12:15, Hanjun Guo wrote:
>> On 2016/1/25 18:21, Robert Richter wrote:
>>> On 23.01.16 17:39:20, Hanjun Guo wrote:
>>>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>>>> new file mode 100644
>>>> index 0000000..f7f7533
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/acpi_numa.c
>>>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>>>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>>> +{
>>>> +	u64 start, end;
>>>> +	int node, pxm;
>>>> +
>>>> +	if (srat_disabled())
>>>> +		return -EINVAL;
>>>> +
>>>> +	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
>>> Must be:
>>>
>>> 	ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>>>
>>> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>> Hmm, I think we need to remove the check here now.
> No, we might have an out-of-bound access then.
>
>> There are three cases:
>>
>>  - firmware ACPI version is consistent with the ACPICA one, then
>>    ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>>
>>  - firmware ACPI version is not consistent with the ACPICA one,
>>    for example, struct acpi_srat_mem_affinity is extended in
>>    new ACI version, but the formware is using the older one,
>>   then it's ok to use
>>   ma->header.length < sizeof(struct acpi_srat_mem_affinity )
> The check above is ok as we need at least struct
> acpi_srat_mem_affinity as it is now.
>
> If we later change the kernel to support multiple versions of struct
> acpi_srat_mem_affinity, i.e. use data from an extended section, we
> will need to add code to handle that. This will include support of
> data with length < acpi_srat_mem_affinity, in this case we may not use
> extended data.

I checked the ACPI spec about memory affinity structure, it still have 10 bytes
reserved for future use, so I think it's safe as you suggested for next few years.

>
>>  - but if we use the older kernel + updated new firmware,
>>    then
>>    ma->header.length > sizeof(struct acpi_srat_mem_affinity )
>>   will be the case, right?
> Right, and this is a valid case not resulting in an error with my
> suggestion above.

Yes, I just mixed up those two cases.

I will sync with Ganapat to prepare a new version and test it on x86 and
IA64 to make sure this patch set don't break anything.

Thanks
Hanjun

[toc] | [prev] | [next] | [standalone]

#1323397 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 23.01.16 17:39:20, Hanjun Guo wrote:

> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>  {
>  	int ret = -ENODEV;
>  
> -#ifdef CONFIG_OF_NUMA
>  	if (!numa_off)
> -		ret = numa_init(arm64_of_numa_init);
> -#endif
> +		ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>  
>  	if (ret)
>  		numa_init(dummy_numa_init);

Ok, this style is mostly flavor, some people want #ifdefs (my
preference), some not. In any case it must build with or without the
config option set. But first some words why I like #ifdefs:

 * Code is easier to understand as you don't need to look at any other
   location whether it is enabled or not.

 * You can't break the build if the options are not set. Thus, you
   also don't need to check if the function is implemented for the
   unset case (valid for the coder and also the reviewer). This makes
   things a lot easier.

 * Total number of lines of code that needs to be implement is
   smaller.

However, if we don't ifdef the code, we need empty functions stubs in
the header file for them.

Also, the conditional assignment does not reduce the complexity of the
paths. It just concentrates everything in a single line.

How about the following (similar to x86)?

----
	if (!numa_off) {
#ifdef CONFIG_ACPI_NUMA
		if (!numa_init(acpi_numa_init))
			return 0;
#endif
#ifdef CONFIG_OF_NUMA
		if (!numa_init(of_numa_init))
			return 0;
#endif
	}

	return numa_init(dummy_numa_init);
----

Pretty straight and nice.

Note: The !acpi_disabled check needs to be moved to the beginning of
acpi_numa_init(). Variable ret can be removed.

-Robert

[toc] | [prev] | [next] | [standalone]

#1323996 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On 2016/2/2 2:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>>   {
>>   	int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>>   	if (!numa_off)
>> -		ret = numa_init(arm64_of_numa_init);
>> -#endif
>> +		ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>>   	if (ret)
>>   		numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
>   * Code is easier to understand as you don't need to look at any other
>     location whether it is enabled or not.
>
>   * You can't break the build if the options are not set. Thus, you
>     also don't need to check if the function is implemented for the
>     unset case (valid for the coder and also the reviewer). This makes
>     things a lot easier.
>
>   * Total number of lines of code that needs to be implement is
>     smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> 	if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> 		if (!numa_init(acpi_numa_init))
> 			return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> 		if (!numa_init(of_numa_init))
> 			return 0;
> #endif
> 	}
>
> 	return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
> Note: The !acpi_disabled check needs to be moved to the beginning of
> acpi_numa_init(). Variable ret can be removed.

Lorenzo suggested to remove it, Lorenzo, what's your opinion here?

Thanks
Hanjun

[toc] | [prev] | [next] | [standalone]

#1324281 — Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

On Tue, Feb 02, 2016 at 07:30:12PM +0800, Hanjun Guo wrote:

[...]

> >How about the following (similar to x86)?
> >
> >----
> >	if (!numa_off) {
> >#ifdef CONFIG_ACPI_NUMA
> >		if (!numa_init(acpi_numa_init))
> >			return 0;
> >#endif
> >#ifdef CONFIG_OF_NUMA
> >		if (!numa_init(of_numa_init))
> >			return 0;
> >#endif
> >	}
> >
> >	return numa_init(dummy_numa_init);
> >----
> >
> >Pretty straight and nice.
> >
> >Note: The !acpi_disabled check needs to be moved to the beginning of
> >acpi_numa_init(). Variable ret can be removed.
> 
> Lorenzo suggested to remove it, Lorenzo, what's your opinion here?

I do not think it is a big deal. OF is not a fall-back for ACPI,
which is what the code above may make us think, either you parse
ACPI or you parse DT.

I will have a look at the complete code to check if we can rewrite
it differently but I would not be too worried about it.

Lorenzo

[toc] | [prev] | [next] | [standalone]

#1315560 — [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

From: Hanjun Guo <hanjun.guo@linaro.org>

After the cleanup for acpi_numa_memory_affinity_init(),
it can be used for architetures both x86 and arm64, since
CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
worry about that.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
 arch/x86/mm/srat.c            | 54 ----------------------------------------
 drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 96 deletions(-)

diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 03ac1b9..5c01b06 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -137,48 +137,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
 		pxm, mpidr, node, cpus_in_srat);
 }
 
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
-	u64 start, end;
-	int node, pxm;
-
-	if (srat_disabled())
-		return -EINVAL;
-
-	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
-		bad_srat();
-		return -EINVAL;
-	}
-
-	/* Ignore disabled entries */
-	if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
-		return -EINVAL;
-
-	start = ma->base_address;
-	end = start + ma->length;
-	pxm = ma->proximity_domain;
-
-	node = acpi_map_pxm_to_node(pxm);
-
-	if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
-		pr_err("SRAT: Too many proximity domains.\n");
-		bad_srat();
-		return -EINVAL;
-	}
-
-	pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
-		node, pxm,
-		(unsigned long long) start, (unsigned long long) end - 1);
-
-	if (numa_add_memblk(node, start, end) < 0) {
-		bad_srat();
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
 int __init arm64_acpi_numa_init(void)
 {
 	int ret;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index af1dc14..cbd792f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -16,7 +16,6 @@
 #include <linux/module.h>
 #include <linux/topology.h>
 #include <linux/bootmem.h>
-#include <linux/memblock.h>
 #include <linux/mm.h>
 #include <asm/proto.h>
 #include <asm/numa.h>
@@ -104,59 +103,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
 	       pxm, apic_id, node);
 }
 
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init
-acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
-	u64 start, end;
-	u32 hotpluggable;
-	int node, pxm;
-
-	if (srat_disabled())
-		goto out_err;
-	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
-		goto out_err_bad_srat;
-	if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
-		goto out_err;
-	hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
-	if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
-		goto out_err;
-
-	start = ma->base_address;
-	end = start + ma->length;
-	pxm = ma->proximity_domain;
-	if (acpi_srat_revision <= 1)
-		pxm &= 0xff;
-
-	node = acpi_map_pxm_to_node(pxm);
-	if (node < 0) {
-		printk(KERN_ERR "SRAT: Too many proximity domains.\n");
-		goto out_err_bad_srat;
-	}
-
-	if (numa_add_memblk(node, start, end) < 0)
-		goto out_err_bad_srat;
-
-	node_set(node, numa_nodes_parsed);
-
-	pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
-		node, pxm,
-		(unsigned long long) start, (unsigned long long) end - 1,
-		hotpluggable ? " hotplug" : "",
-		ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
-
-	/* Mark hotplug range in memblock. */
-	if (hotpluggable && memblock_mark_hotplug(start, ma->length))
-		pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
-			(unsigned long long)start, (unsigned long long)end - 1);
-
-	return 0;
-out_err_bad_srat:
-	bad_srat();
-out_err:
-	return -EINVAL;
-}
-
 int __init x86_acpi_numa_init(void)
 {
 	int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 05e3795..eb73fda 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -27,6 +27,7 @@
 #include <linux/types.h>
 #include <linux/errno.h>
 #include <linux/acpi.h>
+#include <linux/memblock.h>
 #include <linux/numa.h>
 #include <linux/nodemask.h>
 #include <linux/topology.h>
@@ -240,6 +241,62 @@ void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
 	}
 }
 
+/*
+ * Default callback for parsing of the Proximity Domain <-> Memory
+ * Area mappings
+ */
+int __init __weak
+acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+	u64 start, end;
+	u32 hotpluggable;
+	int node, pxm;
+
+	if (srat_disabled())
+		goto out_err;
+	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
+		goto out_err_bad_srat;
+	if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
+		goto out_err;
+	hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+	if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+		goto out_err;
+
+	start = ma->base_address;
+	end = start + ma->length;
+	pxm = ma->proximity_domain;
+	if (acpi_srat_revision <= 1)
+		pxm &= 0xff;
+
+	node = acpi_map_pxm_to_node(pxm);
+	if (node < 0) {
+		printk(KERN_ERR "SRAT: Too many proximity domains.\n");
+		goto out_err_bad_srat;
+	}
+
+	if (numa_add_memblk(node, start, end) < 0)
+		goto out_err_bad_srat;
+
+	node_set(node, numa_nodes_parsed);
+
+	pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
+		node, pxm,
+		(unsigned long long) start, (unsigned long long) end - 1,
+		hotpluggable ? " hotplug" : "",
+		ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
+
+	/* Mark hotplug range in memblock. */
+	if (hotpluggable && memblock_mark_hotplug(start, ma->length))
+		pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
+			(unsigned long long)start, (unsigned long long)end - 1);
+
+	return 0;
+out_err_bad_srat:
+	bad_srat();
+out_err:
+	return -EINVAL;
+}
+
 static int __init acpi_parse_slit(struct acpi_table_header *table)
 {
 	struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1316440 — Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

On 23.01.16 17:39:27, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
> 
> After the cleanup for acpi_numa_memory_affinity_init(),
> it can be used for architetures both x86 and arm64, since
> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> worry about that.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>  arch/x86/mm/srat.c            | 54 ----------------------------------------
>  drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 57 insertions(+), 96 deletions(-)

This one reverts acpi_numa_memory_affinity_init() to the x86 version.
I rather would prefer the arm64 version for the generic code. We could
keep the x86 implementation until x86 maintainers agree to remove them
and use the generic one (implemented in a separate patch).

Doing so we can move acpi_numa_memory_affinity_init() from the
beginning to generic code (used for arm64) and have this last patch to
remove the x86 version.

-Robert

[toc] | [prev] | [next] | [standalone]

#1318692 — Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

Hi Robert,

On 2016/1/25 18:26, Robert Richter wrote:
> On 23.01.16 17:39:27, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> After the cleanup for acpi_numa_memory_affinity_init(),
>> it can be used for architetures both x86 and arm64, since
>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>> worry about that.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>>  arch/x86/mm/srat.c            | 54 ----------------------------------------
>>  drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 57 insertions(+), 96 deletions(-)
> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> I rather would prefer the arm64 version for the generic code. We could
> keep the x86 implementation until x86 maintainers agree to remove them
> and use the generic one (implemented in a separate patch).
>
> Doing so we can move acpi_numa_memory_affinity_init() from the
> beginning to generic code (used for arm64) and have this last patch to
> remove the x86 version.

I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
For ARM64, firmware should be careful and represent the true platform configuration to
OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
it will be not worries for the kernel.

Thanks
Hanjun

[toc] | [prev] | [next] | [standalone]

#1319009 — Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

On 27.01.16 14:15:06, Hanjun Guo wrote:
> Hi Robert,
> 
> On 2016/1/25 18:26, Robert Richter wrote:
> > On 23.01.16 17:39:27, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> After the cleanup for acpi_numa_memory_affinity_init(),
> >> it can be used for architetures both x86 and arm64, since
> >> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >> worry about that.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> ---
> >>  arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >>  arch/x86/mm/srat.c            | 54 ----------------------------------------
> >>  drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
> >>  3 files changed, 57 insertions(+), 96 deletions(-)
> > This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> > I rather would prefer the arm64 version for the generic code. We could
> > keep the x86 implementation until x86 maintainers agree to remove them
> > and use the generic one (implemented in a separate patch).
> >
> > Doing so we can move acpi_numa_memory_affinity_init() from the
> > beginning to generic code (used for arm64) and have this last patch to
> > remove the x86 version.
> 
> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> For ARM64, firmware should be careful and represent the true platform configuration to
> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> it will be not worries for the kernel.

But you are removing all arm64 from your first patches. Why do you
introduce acpi_numa_memory_affinity_init() in the beginning to remove
it in the end again? I esp. like the arm64 version because of its
direct returns. So I still would like to see generic code for arm64
from the beginning. Maybe have a copy of x86 initially and make
modifications for arm64 to it, or move missing code (hotplug, etc.)
from x86 to generic and remove x86 arch code with the last patch.

-Robert

[toc] | [prev] | [next] | [standalone]

#1320241 — Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

On 2016/1/27 22:18, Robert Richter wrote:
> On 27.01.16 14:15:06, Hanjun Guo wrote:
>> Hi Robert,
>>
>> On 2016/1/25 18:26, Robert Richter wrote:
>>> On 23.01.16 17:39:27, Hanjun Guo wrote:
>>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>>
>>>> After the cleanup for acpi_numa_memory_affinity_init(),
>>>> it can be used for architetures both x86 and arm64, since
>>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>>>> worry about that.
>>>>
>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>> ---
>>>>  arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>>>>  arch/x86/mm/srat.c            | 54 ----------------------------------------
>>>>  drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 57 insertions(+), 96 deletions(-)
>>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
>>> I rather would prefer the arm64 version for the generic code. We could
>>> keep the x86 implementation until x86 maintainers agree to remove them
>>> and use the generic one (implemented in a separate patch).
>>>
>>> Doing so we can move acpi_numa_memory_affinity_init() from the
>>> beginning to generic code (used for arm64) and have this last patch to
>>> remove the x86 version.
>> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
>> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
>> For ARM64, firmware should be careful and represent the true platform configuration to
>> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
>> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
>> it will be not worries for the kernel.
> But you are removing all arm64 from your first patches. Why do you
> introduce acpi_numa_memory_affinity_init() in the beginning to remove
> it in the end again? I esp. like the arm64 version because of its
> direct returns. So I still would like to see generic code for arm64
> from the beginning. Maybe have a copy of x86 initially and make
> modifications for arm64 to it, or move missing code (hotplug, etc.)
> from x86 to generic and remove x86 arch code with the last patch.

OK, so that's the logic and ordering of formatting the patch set, it's easy
to fix :)

I will introduce the generic code for acpi_numa_memory_affinity_init()
in drivers/acpi/numa.c and mark it as __weak from the beginning, and
move missing code from x86 to generic, then remove x86 one as you
suggested, is that OK?

Thanks
Hanjun

[toc] | [prev] | [next] | [standalone]

#1320676 — Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()

On 28.01.16 10:48:37, Hanjun Guo wrote:
> On 2016/1/27 22:18, Robert Richter wrote:
> > On 27.01.16 14:15:06, Hanjun Guo wrote:
> >> Hi Robert,
> >>
> >> On 2016/1/25 18:26, Robert Richter wrote:
> >>> On 23.01.16 17:39:27, Hanjun Guo wrote:
> >>>> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>>>
> >>>> After the cleanup for acpi_numa_memory_affinity_init(),
> >>>> it can be used for architetures both x86 and arm64, since
> >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >>>> worry about that.
> >>>>
> >>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>>> ---
> >>>>  arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >>>>  arch/x86/mm/srat.c            | 54 ----------------------------------------
> >>>>  drivers/acpi/numa.c           | 57 +++++++++++++++++++++++++++++++++++++++++++
> >>>>  3 files changed, 57 insertions(+), 96 deletions(-)
> >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> >>> I rather would prefer the arm64 version for the generic code. We could
> >>> keep the x86 implementation until x86 maintainers agree to remove them
> >>> and use the generic one (implemented in a separate patch).
> >>>
> >>> Doing so we can move acpi_numa_memory_affinity_init() from the
> >>> beginning to generic code (used for arm64) and have this last patch to
> >>> remove the x86 version.
> >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> >> For ARM64, firmware should be careful and represent the true platform configuration to
> >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> >> it will be not worries for the kernel.
> > But you are removing all arm64 from your first patches. Why do you
> > introduce acpi_numa_memory_affinity_init() in the beginning to remove
> > it in the end again? I esp. like the arm64 version because of its
> > direct returns. So I still would like to see generic code for arm64
> > from the beginning. Maybe have a copy of x86 initially and make
> > modifications for arm64 to it, or move missing code (hotplug, etc.)
> > from x86 to generic and remove x86 arch code with the last patch.
> 
> OK, so that's the logic and ordering of formatting the patch set, it's easy
> to fix :)
> 
> I will introduce the generic code for acpi_numa_memory_affinity_init()
> in drivers/acpi/numa.c and mark it as __weak from the beginning, and
> move missing code from x86 to generic, then remove x86 one as you
> suggested, is that OK?

Sounds good to me. Awaiting your updated version. :)

Btw, I tested the whole series, so:

Tested-by: Robert Richter <rrichter@cavium.com>

-Robert

[toc] | [prev] | [next] | [standalone]

#1315561 — [PATCH v3 10/12] acpi, numa: move bad_srat() and srat_disabled() to common place

From: Hanjun Guo <hanjun.guo@linaro.org>

bad_srat() and srat_disabled() are shared by arm64 and x86,
move it to common place to reduce duplication.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi_numa.c | 12 ------------
 arch/x86/include/asm/acpi.h   |  1 -
 arch/x86/mm/numa.c            |  2 +-
 arch/x86/mm/srat.c            | 13 -------------
 drivers/acpi/numa.c           |  1 +
 include/acpi/acpi_numa.h      | 12 ++++++++++++
 6 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 3bcf058..fb1556f 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -28,7 +28,6 @@
 #include <acpi/processor.h>
 #include <asm/numa.h>
 
-int acpi_numa __initdata;
 static int cpus_in_srat;
 
 struct __node_cpu_hwid {
@@ -39,17 +38,6 @@ struct __node_cpu_hwid {
 static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
 [0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
 
-static __init void bad_srat(void)
-{
-	pr_err("SRAT not used.\n");
-	acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
-	return acpi_numa < 0;
-}
-
 void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
 {
 	int nid = 0, i;
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 94c18eb..65f1e95 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -145,7 +145,6 @@ static inline void disable_acpi(void) { }
 #define ARCH_HAS_POWER_INIT	1
 
 #ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
 extern int x86_acpi_numa_init(void);
 #endif /* CONFIG_ACPI_NUMA */
 
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..fd59371 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -1,4 +1,5 @@
 /* Common code for 32 and 64-bit NUMA */
+#include <linux/acpi.h>
 #include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/string.h>
@@ -15,7 +16,6 @@
 #include <asm/e820.h>
 #include <asm/proto.h>
 #include <asm/dma.h>
-#include <asm/acpi.h>
 #include <asm/amd_nb.h>
 
 #include "numa_internal.h"
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 304cdf2..7078b3f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -24,19 +24,6 @@
 #include <asm/apic.h>
 #include <asm/uv/uv.h>
 
-int acpi_numa __initdata;
-
-static __init void bad_srat(void)
-{
-	printk(KERN_ERR "SRAT: SRAT not used.\n");
-	acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
-	return acpi_numa < 0;
-}
-
 /* Callback for Proximity Domain -> x2APIC mapping */
 void __init
 acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index b33915e..05e3795 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -40,6 +40,7 @@ static int node_to_pxm_map[MAX_NUMNODES]
 			= { [0 ... MAX_NUMNODES - 1] = PXM_INVAL };
 
 unsigned char acpi_srat_revision __initdata;
+int acpi_numa __initdata;
 
 int pxm_to_node(int pxm)
 {
diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
index 94a37cd..28f06a6 100644
--- a/include/acpi/acpi_numa.h
+++ b/include/acpi/acpi_numa.h
@@ -15,6 +15,18 @@ extern int pxm_to_node(int);
 extern int node_to_pxm(int);
 extern int acpi_map_pxm_to_node(int);
 extern unsigned char acpi_srat_revision;
+extern int acpi_numa __initdata;
+
+static inline void bad_srat(void)
+{
+	pr_err("SRAT: SRAT not used.\n");
+	acpi_numa = -1;
+}
+
+static  inline int srat_disabled(void)
+{
+	return acpi_numa < 0;
+}
 
 #endif				/* CONFIG_ACPI_NUMA */
 #endif				/* __ACP_NUMA_H */
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1315562 — [PATCH v3 02/12] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()

From: Hanjun Guo <hanjun.guo@linaro.org>

ACPI_DEBUG_PRINT is a bit fragile in acpi/numa.c, the first thing
is that component ACPI_NUMA(0x80000000) is not described in the
Documentation/acpi/debug.txt, and even not defined in the struct
acpi_dlayer acpi_debug_layers which we can not dynamically enable/disable
it with /sys/modules/acpi/parameters/debug_layer. another thing
is that ACPI_DEBUG_OUTPUT is controlled by ACPICA which not coordinate
well with ACPI drivers.

Replace ACPI_DEBUG_PRINT() with pr_debug() in this patch as pr_debug
will do the same thing for debug purpose and it can make the code much
cleaner, also remove the related code which not needed anymore if
ACPI_DEBUG_PRINT() is gone.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 drivers/acpi/numa.c | 59 +++++++++++++++++++----------------------------------
 1 file changed, 21 insertions(+), 38 deletions(-)

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4e427fc..e34b5d0 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -31,10 +31,6 @@
 #include <linux/nodemask.h>
 #include <linux/topology.h>
 
-#define ACPI_NUMA	0x80000000
-#define _COMPONENT	ACPI_NUMA
-ACPI_MODULE_NAME("numa");
-
 static nodemask_t nodes_found_map = NODE_MASK_NONE;
 
 /* maps to convert between proximity domain and logical node ID */
@@ -129,64 +125,51 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
 static void __init
 acpi_table_print_srat_entry(struct acpi_subtable_header *header)
 {
-
-	ACPI_FUNCTION_NAME("acpi_table_print_srat_entry");
-
 	if (!header)
 		return;
 
 	switch (header->type) {
-
 	case ACPI_SRAT_TYPE_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_cpu_affinity *p =
 			    (struct acpi_srat_cpu_affinity *)header;
-			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
-					  p->apic_id, p->local_sapic_eid,
-					  p->proximity_domain_lo,
-					  (p->flags & ACPI_SRAT_CPU_ENABLED)?
-					  "enabled" : "disabled"));
+			pr_debug("SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
+				 p->apic_id, p->local_sapic_eid,
+				 p->proximity_domain_lo,
+				 (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+				 "enabled" : "disabled");
 		}
-#endif				/* ACPI_DEBUG_OUTPUT */
 		break;
 
 	case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_mem_affinity *p =
 			    (struct acpi_srat_mem_affinity *)header;
-			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
-					  (unsigned long)p->base_address,
-					  (unsigned long)p->length,
-					  p->proximity_domain,
-					  (p->flags & ACPI_SRAT_MEM_ENABLED)?
-					  "enabled" : "disabled",
-					  (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)?
-					  " hot-pluggable" : "",
-					  (p->flags & ACPI_SRAT_MEM_NON_VOLATILE)?
-					  " non-volatile" : ""));
+			pr_debug("SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
+				 (unsigned long)p->base_address,
+				 (unsigned long)p->length,
+				 p->proximity_domain,
+				 (p->flags & ACPI_SRAT_MEM_ENABLED) ?
+				 "enabled" : "disabled",
+				 (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) ?
+				 " hot-pluggable" : "",
+				 (p->flags & ACPI_SRAT_MEM_NON_VOLATILE) ?
+				 " non-volatile" : "");
 		}
-#endif				/* ACPI_DEBUG_OUTPUT */
 		break;
 
 	case ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_x2apic_cpu_affinity *p =
 			    (struct acpi_srat_x2apic_cpu_affinity *)header;
-			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Processor (x2apicid[0x%08x]) in"
-					  " proximity domain %d %s\n",
-					  p->apic_id,
-					  p->proximity_domain,
-					  (p->flags & ACPI_SRAT_CPU_ENABLED) ?
-					  "enabled" : "disabled"));
+			pr_debug("SRAT Processor (x2apicid[0x%08x]) in proximity domain %d %s\n",
+				 p->apic_id,
+				 p->proximity_domain,
+				 (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+				 "enabled" : "disabled");
 		}
-#endif				/* ACPI_DEBUG_OUTPUT */
 		break;
+
 	default:
 		pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
 			header->type);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web