* [PATCH v4 0/4] acpi: do some changes for numa info
@ 2013-02-15 2:23 liguang
2013-02-15 2:23 ` [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c liguang
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: liguang @ 2013-02-15 2:23 UTC (permalink / raw)
To: linux-kernel, linux-acpi, x86; +Cc: rientjes, isimatu.yasuaki, liguang
just do some trivial changes to make acpi's numa info
operation more cleaner.
ChangeLog
v3->v4
1.fix srat_disabled function
spotted by Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
v2->v3
1. rebase on linux-next
2. bring back lost Makefile changes
spotted by David Rientjes <rientjes@google.com>
spotted by Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
v1->v2
1. fix-up several coding issues
2. finish srat.c change
spotted by David Rientjes <rientjes@google.com>
Li Guang(4)
numa: avoid export acpi_numa variable
acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
acpi: add clock_domain field to acpi_srat_cpu_affinity
remove include asm/acpi.h in process_driver.c
arch/x86/include/asm/acpi.h | 2 +-
arch/x86/kernel/acpi/Makefile | 1 +
arch/x86/kernel/acpi/srat.c | 216 +++++++++++++++++++++++++++++++++++++++++++---
arch/x86/mm/Makefile | 1 -
arch/x86/mm/srat.c | 198 -------------------------------------------
arch/x86/mm/numa.c | 2 +-
arch/x86/xen/enlighten.c | 2 +-
include/acpi/actbl1.h | 2 +-
drivers/acpi/processor_driver.c | 1 -
9 files changed, 214 insertions(+), 210 deletions(-)
create mode 100644 arch/x86/kernel/acpi/srat.c
delete mode 100644 arch/x86/mm/srat.c
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-15 2:23 [PATCH v4 0/4] acpi: do some changes for numa info liguang
@ 2013-02-15 2:23 ` liguang
2013-02-19 21:21 ` David Rientjes
2013-02-15 2:23 ` [PATCH v4 2/4] numa: avoid export acpi_numa variable liguang
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: liguang @ 2013-02-15 2:23 UTC (permalink / raw)
To: linux-kernel, linux-acpi, x86; +Cc: rientjes, isimatu.yasuaki, liguang
srat table should present only on acpi domain,
seems mm/ is not the right place for it.
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
arch/x86/kernel/acpi/Makefile | 1 +
arch/x86/kernel/acpi/srat.c | 198 +++++++++++++++++++++++++++++++++++++++++
arch/x86/mm/Makefile | 1 -
arch/x86/mm/srat.c | 198 -----------------------------------------
4 files changed, 199 insertions(+), 199 deletions(-)
create mode 100644 arch/x86/kernel/acpi/srat.c
delete mode 100644 arch/x86/mm/srat.c
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 163b225..98cea92 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_ACPI) += boot.o
obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup_$(BITS).o
+obj-$(CONFIG_ACPI_NUMA) += srat.o
ifneq ($(CONFIG_ACPI_PROCESSOR),)
obj-y += cstate.o
diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
new file mode 100644
index 0000000..cdd0da9
--- /dev/null
+++ b/arch/x86/kernel/acpi/srat.c
@@ -0,0 +1,198 @@
+/*
+ * ACPI 3.0 based NUMA setup
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/acpi.h>
+#include <linux/mmzone.h>
+#include <linux/bitmap.h>
+#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>
+#include <asm/e820.h>
+#include <asm/apic.h>
+#include <asm/uv/uv.h>
+
+int acpi_numa __initdata;
+
+static __init int setup_node(int pxm)
+{
+ return acpi_map_pxm_to_node(pxm);
+}
+
+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 SLIT parsing */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++)
+ for (j = 0; j < slit->locality_count; j++)
+ numa_set_distance(pxm_to_node(i), pxm_to_node(j),
+ slit->entry[slit->locality_count * i + j]);
+}
+
+/* Callback for Proximity Domain -> x2APIC mapping */
+void __init
+acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
+{
+ int pxm, node;
+ int apic_id;
+
+ if (srat_disabled())
+ return;
+ if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
+ bad_srat();
+ return;
+ }
+ if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+ return;
+ pxm = pa->proximity_domain;
+ apic_id = pa->apic_id;
+ if (!apic->apic_id_valid(apic_id)) {
+ printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
+ pxm, apic_id);
+ return;
+ }
+ node = setup_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
+ set_apicid_to_node(apic_id, node);
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
+ pxm, apic_id, node);
+}
+
+/* Callback for Proximity Domain -> LAPIC mapping */
+void __init
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
+{
+ int pxm, node;
+ int apic_id;
+
+ if (srat_disabled())
+ return;
+ if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
+ bad_srat();
+ return;
+ }
+ if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+ return;
+ pxm = pa->proximity_domain_lo;
+ if (acpi_srat_revision >= 2)
+ pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
+ node = setup_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (get_uv_system_type() >= UV_X2APIC)
+ apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
+ else
+ apic_id = pa->apic_id;
+
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
+
+ set_apicid_to_node(apic_id, node);
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
+ pxm, apic_id, node);
+}
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+static inline int save_add_info(void) {return 1;}
+#else
+static inline int save_add_info(void) {return 0;}
+#endif
+
+/* 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())
+ 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;
+ if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
+ goto out_err;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+ if (acpi_srat_revision <= 1)
+ pxm &= 0xff;
+
+ node = setup_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);
+
+ printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
+ return 0;
+out_err_bad_srat:
+ bad_srat();
+out_err:
+ return -1;
+}
+
+void __init acpi_numa_arch_fixup(void) {}
+
+int __init x86_acpi_numa_init(void)
+{
+ int ret;
+
+ ret = acpi_numa_init();
+ if (ret < 0)
+ return ret;
+ return srat_disabled() ? -EINVAL : 0;
+}
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 23d8e5f..d6f3692 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_MMIOTRACE_TEST) += testmmiotrace.o
obj-$(CONFIG_NUMA) += numa.o numa_$(BITS).o
obj-$(CONFIG_AMD_NUMA) += amdtopology.o
-obj-$(CONFIG_ACPI_NUMA) += srat.o
obj-$(CONFIG_NUMA_EMU) += numa_emulation.o
obj-$(CONFIG_MEMTEST) += memtest.o
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
deleted file mode 100644
index cdd0da9..0000000
--- a/arch/x86/mm/srat.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- * ACPI 3.0 based NUMA setup
- * Copyright 2004 Andi Kleen, SuSE Labs.
- *
- * 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.
- */
-
-#include <linux/kernel.h>
-#include <linux/acpi.h>
-#include <linux/mmzone.h>
-#include <linux/bitmap.h>
-#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>
-#include <asm/e820.h>
-#include <asm/apic.h>
-#include <asm/uv/uv.h>
-
-int acpi_numa __initdata;
-
-static __init int setup_node(int pxm)
-{
- return acpi_map_pxm_to_node(pxm);
-}
-
-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 SLIT parsing */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++)
- for (j = 0; j < slit->locality_count; j++)
- numa_set_distance(pxm_to_node(i), pxm_to_node(j),
- slit->entry[slit->locality_count * i + j]);
-}
-
-/* Callback for Proximity Domain -> x2APIC mapping */
-void __init
-acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
-{
- int pxm, node;
- int apic_id;
-
- if (srat_disabled())
- return;
- if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
- bad_srat();
- return;
- }
- if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
- return;
- pxm = pa->proximity_domain;
- apic_id = pa->apic_id;
- if (!apic->apic_id_valid(apic_id)) {
- printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
- pxm, apic_id);
- return;
- }
- node = setup_node(pxm);
- if (node < 0) {
- printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
- bad_srat();
- return;
- }
-
- if (apic_id >= MAX_LOCAL_APIC) {
- printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
- return;
- }
- set_apicid_to_node(apic_id, node);
- node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
- printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
- pxm, apic_id, node);
-}
-
-/* Callback for Proximity Domain -> LAPIC mapping */
-void __init
-acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
-{
- int pxm, node;
- int apic_id;
-
- if (srat_disabled())
- return;
- if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
- bad_srat();
- return;
- }
- if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
- return;
- pxm = pa->proximity_domain_lo;
- if (acpi_srat_revision >= 2)
- pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
- node = setup_node(pxm);
- if (node < 0) {
- printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
- bad_srat();
- return;
- }
-
- if (get_uv_system_type() >= UV_X2APIC)
- apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
- else
- apic_id = pa->apic_id;
-
- if (apic_id >= MAX_LOCAL_APIC) {
- printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
- return;
- }
-
- set_apicid_to_node(apic_id, node);
- node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
- printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
- pxm, apic_id, node);
-}
-
-#ifdef CONFIG_MEMORY_HOTPLUG
-static inline int save_add_info(void) {return 1;}
-#else
-static inline int save_add_info(void) {return 0;}
-#endif
-
-/* 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())
- 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;
- if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
- goto out_err;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
- if (acpi_srat_revision <= 1)
- pxm &= 0xff;
-
- node = setup_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);
-
- printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1);
-
- return 0;
-out_err_bad_srat:
- bad_srat();
-out_err:
- return -1;
-}
-
-void __init acpi_numa_arch_fixup(void) {}
-
-int __init x86_acpi_numa_init(void)
-{
- int ret;
-
- ret = acpi_numa_init();
- if (ret < 0)
- return ret;
- return srat_disabled() ? -EINVAL : 0;
-}
--
1.7.2.5
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 2/4] numa: avoid export acpi_numa variable
2013-02-15 2:23 [PATCH v4 0/4] acpi: do some changes for numa info liguang
2013-02-15 2:23 ` [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c liguang
@ 2013-02-15 2:23 ` liguang
2013-02-19 21:25 ` David Rientjes
2013-02-15 2:23 ` [PATCH v4 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity liguang
2013-02-15 2:23 ` [PATCH v4 4/4] remove include asm/acpi.h in process_driver.c liguang
3 siblings, 1 reply; 16+ messages in thread
From: liguang @ 2013-02-15 2:23 UTC (permalink / raw)
To: linux-kernel, linux-acpi, x86; +Cc: rientjes, isimatu.yasuaki, liguang
acpi_numa is used to prevent srat table
being parsed, seems a little miss-named,
if 'noacpi' was specified by cmdline and
CONFIG_ACPI_NUMA was enabled, acpi_numa
will be operated directly from everywhere
it needed to disable/enable numa in acpi
mode which was a bad thing, so, try to
export a fuction to get srat table
enable/disable info.
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
arch/x86/include/asm/acpi.h | 2 +-
arch/x86/kernel/acpi/srat.c | 21 +++++++++++++--------
arch/x86/mm/numa.c | 2 +-
arch/x86/xen/enlighten.c | 2 +-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index b31bf97..449e12a 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -177,7 +177,7 @@ static inline void disable_acpi(void) { }
#define ARCH_HAS_POWER_INIT 1
#ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
+extern void disable_acpi_numa(void);
extern int x86_acpi_numa_init(void);
#endif /* CONFIG_ACPI_NUMA */
diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
index cdd0da9..1b5b461 100644
--- a/arch/x86/kernel/acpi/srat.c
+++ b/arch/x86/kernel/acpi/srat.c
@@ -24,22 +24,27 @@
#include <asm/apic.h>
#include <asm/uv/uv.h>
-int acpi_numa __initdata;
+static bool acpi_numa __initdata;
static __init int setup_node(int pxm)
{
return acpi_map_pxm_to_node(pxm);
}
-static __init void bad_srat(void)
+void __init disable_acpi_numa(void)
{
- printk(KERN_ERR "SRAT: SRAT not used.\n");
- acpi_numa = -1;
+ acpi_numa = false;
}
-static __init inline int srat_disabled(void)
+static void __init bad_srat(void)
{
- return acpi_numa < 0;
+ disable_acpi_numa();
+ printk(KERN_ERR "SRAT: SRAT will not be used.\n");
+}
+
+static bool __init srat_disabled(void)
+{
+ return acpi_numa == false;
}
/* Callback for SLIT parsing */
@@ -88,7 +93,7 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
}
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
+ acpi_numa = true;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
pxm, apic_id, node);
}
@@ -130,7 +135,7 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
+ acpi_numa = true;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
pxm, apic_id, node);
}
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 245a4ba..1ebc907 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
#endif
#ifdef CONFIG_ACPI_NUMA
if (!strncmp(opt, "noacpi", 6))
- acpi_numa = -1;
+ disable_acpi_numa();
#endif
return 0;
}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 657eca9..3636bc6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1447,7 +1447,7 @@ asmlinkage void __init xen_start_kernel(void)
* any NUMA information the kernel tries to get from ACPI will
* be meaningless. Prevent it from trying.
*/
- acpi_numa = -1;
+ disable_acpi_numa();
#endif
/* Don't do the full vcpu_info placement stuff until we have a
--
1.7.2.5
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity
2013-02-15 2:23 [PATCH v4 0/4] acpi: do some changes for numa info liguang
2013-02-15 2:23 ` [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c liguang
2013-02-15 2:23 ` [PATCH v4 2/4] numa: avoid export acpi_numa variable liguang
@ 2013-02-15 2:23 ` liguang
2013-02-15 2:23 ` [PATCH v4 4/4] remove include asm/acpi.h in process_driver.c liguang
3 siblings, 0 replies; 16+ messages in thread
From: liguang @ 2013-02-15 2:23 UTC (permalink / raw)
To: linux-kernel, linux-acpi, x86; +Cc: rientjes, isimatu.yasuaki, liguang
according to ACPI SPEC v5.0, page 152,
5.2.16.1 Processor Local APIC/SAPIC Affinity Structure,
the last member of it is clock_domain.
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
include/acpi/actbl1.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 0bd750e..e21d22b 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -922,7 +922,7 @@ struct acpi_srat_cpu_affinity {
u32 flags;
u8 local_sapic_eid;
u8 proximity_domain_hi[3];
- u32 reserved; /* Reserved, must be zero */
+ u32 clock_domain;
};
/* Flags */
--
1.7.2.5
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v4 4/4] remove include asm/acpi.h in process_driver.c
2013-02-15 2:23 [PATCH v4 0/4] acpi: do some changes for numa info liguang
` (2 preceding siblings ...)
2013-02-15 2:23 ` [PATCH v4 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity liguang
@ 2013-02-15 2:23 ` liguang
3 siblings, 0 replies; 16+ messages in thread
From: liguang @ 2013-02-15 2:23 UTC (permalink / raw)
To: linux-kernel, linux-acpi, x86; +Cc: rientjes, isimatu.yasuaki, liguang
process_driver.c include linux/acpi.h which already
include asm/acpi.h, so remove it.
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
drivers/acpi/processor_driver.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d57e32c..2f3bc09 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -53,7 +53,6 @@
#include <asm/uaccess.h>
#include <asm/processor.h>
#include <asm/smp.h>
-#include <asm/acpi.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
--
1.7.2.5
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-15 2:23 ` [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c liguang
@ 2013-02-19 21:21 ` David Rientjes
2013-02-20 1:39 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: David Rientjes @ 2013-02-19 21:21 UTC (permalink / raw)
To: liguang; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
On Fri, 15 Feb 2013, liguang wrote:
> srat table should present only on acpi domain,
> seems mm/ is not the right place for it.
>
> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
This doesn't apply to Linus' tree nor does it apply to linux-next. Which
tree are you basing this on?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 2/4] numa: avoid export acpi_numa variable
2013-02-15 2:23 ` [PATCH v4 2/4] numa: avoid export acpi_numa variable liguang
@ 2013-02-19 21:25 ` David Rientjes
0 siblings, 0 replies; 16+ messages in thread
From: David Rientjes @ 2013-02-19 21:25 UTC (permalink / raw)
To: liguang; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
On Fri, 15 Feb 2013, liguang wrote:
> acpi_numa is used to prevent srat table
> being parsed, seems a little miss-named,
> if 'noacpi' was specified by cmdline and
> CONFIG_ACPI_NUMA was enabled, acpi_numa
> will be operated directly from everywhere
> it needed to disable/enable numa in acpi
> mode which was a bad thing, so, try to
> export a fuction to get srat table
> enable/disable info.
>
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-19 21:21 ` David Rientjes
@ 2013-02-20 1:39 ` li guang
2013-02-20 1:51 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: li guang @ 2013-02-20 1:39 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-19二的 13:21 -0800，David Rientjes写道：
> On Fri, 15 Feb 2013, liguang wrote:
>
> > srat table should present only on acpi domain,
> > seems mm/ is not the right place for it.
> >
> > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
>
> This doesn't apply to Linus' tree nor does it apply to linux-next. Which
> tree are you basing this on?
I did based on linux-next,
but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760
which you may want to see.
let me see why it missed.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 1:39 ` li guang
@ 2013-02-20 1:51 ` li guang
2013-02-20 2:08 ` David Rientjes
0 siblings, 1 reply; 16+ messages in thread
From: li guang @ 2013-02-20 1:51 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-20三的 09:39 +0800，li guang写道：
> 在 2013-02-19二的 13:21 -0800，David Rientjes写道：
> > On Fri, 15 Feb 2013, liguang wrote:
> >
> > > srat table should present only on acpi domain,
> > > seems mm/ is not the right place for it.
> > >
> > > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> > > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> >
> > This doesn't apply to Linus' tree nor does it apply to linux-next. Which
> > tree are you basing this on?
>
> I did based on linux-next,
> but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760
> which you may want to see.
> let me see why it missed.
I pulled latest for linux-next
and can apply my patches smoothly.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 1:51 ` li guang
@ 2013-02-20 2:08 ` David Rientjes
2013-02-20 2:21 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: David Rientjes @ 2013-02-20 2:08 UTC (permalink / raw)
To: li guang; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
On Wed, 20 Feb 2013, li guang wrote:
> > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which
> > > tree are you basing this on?
> >
> > I did based on linux-next,
> > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760
> > which you may want to see.
> > let me see why it missed.
>
> I pulled latest for linux-next
> and can apply my patches smoothly.
>
No, it doesn't. From next-20130219, you're missing at least two patches:
3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node")
9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT")
I'm trying to be patient in reviewing your patches, but please double
check your work.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 2:08 ` David Rientjes
@ 2013-02-20 2:21 ` li guang
2013-02-20 2:26 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: li guang @ 2013-02-20 2:21 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-19二的 18:08 -0800，David Rientjes写道：
> On Wed, 20 Feb 2013, li guang wrote:
>
> > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which
> > > > tree are you basing this on?
> > >
> > > I did based on linux-next,
> > > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760
> > > which you may want to see.
> > > let me see why it missed.
> >
> > I pulled latest for linux-next
> > and can apply my patches smoothly.
> >
>
> No, it doesn't. From next-20130219, you're missing at least two patches:
>
> 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node")
> 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT")
>
> I'm trying to be patient in reviewing your patches, but please double
> check your work.
I have to say my latest pull has these commit, and can apply
successfully.
really don't know why you can't apply.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 2:21 ` li guang
@ 2013-02-20 2:26 ` li guang
2013-02-20 3:04 ` David Rientjes
0 siblings, 1 reply; 16+ messages in thread
From: li guang @ 2013-02-20 2:26 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-20三的 10:21 +0800，li guang写道：
> 在 2013-02-19二的 18:08 -0800，David Rientjes写道：
> > On Wed, 20 Feb 2013, li guang wrote:
> >
> > > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which
> > > > > tree are you basing this on?
> > > >
> > > > I did based on linux-next,
> > > > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760
> > > > which you may want to see.
> > > > let me see why it missed.
> > >
> > > I pulled latest for linux-next
> > > and can apply my patches smoothly.
> > >
> >
> > No, it doesn't. From next-20130219, you're missing at least two patches:
> >
> > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node")
> > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT")
> >
> > I'm trying to be patient in reviewing your patches, but please double
> > check your work.
>
> I have to say my latest pull has these commit, and can apply
> successfully.
> really don't know why you can't apply.
>
I mean although my patches did not based on latest linux-next(miss
several commits), but as I can see, they can be applied to latest
linux-next (tag next-20130218) successfully.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 2:26 ` li guang
@ 2013-02-20 3:04 ` David Rientjes
2013-02-20 3:16 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: David Rientjes @ 2013-02-20 3:04 UTC (permalink / raw)
To: li guang; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
On Wed, 20 Feb 2013, li guang wrote:
> > > No, it doesn't. From next-20130219, you're missing at least two patches:
> > >
> > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node")
> > > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT")
> > >
> > > I'm trying to be patient in reviewing your patches, but please double
> > > check your work.
> >
> > I have to say my latest pull has these commit, and can apply
> > successfully.
> > really don't know why you can't apply.
You should not be pulling linux-next, you should be fetching.
>
> I mean although my patches did not based on latest linux-next(miss
> several commits), but as I can see, they can be applied to latest
> linux-next (tag next-20130218) successfully.
>
next-20130218 is not the latest linux-next as I've already said. Do this:
go to
http://git.kernel.org/?p=linux/kernel/git/next/linux-next-history.git;a=blob_plain;f=arch/x86/mm/srat.c;hb=HEAD
and search for handle_movablemem(). That's one of the functions added in
one of the commits I mentioned and was from February. Now search your
patch for handle_movablemem(). See a problem?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 3:04 ` David Rientjes
@ 2013-02-20 3:16 ` li guang
2013-02-20 7:00 ` David Rientjes
0 siblings, 1 reply; 16+ messages in thread
From: li guang @ 2013-02-20 3:16 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-19二的 19:04 -0800，David Rientjes写道：
> On Wed, 20 Feb 2013, li guang wrote:
>
> > > > No, it doesn't. From next-20130219, you're missing at least two patches:
> > > >
> > > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node")
> > > > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT")
> > > >
> > > > I'm trying to be patient in reviewing your patches, but please double
> > > > check your work.
> > >
> > > I have to say my latest pull has these commit, and can apply
> > > successfully.
> > > really don't know why you can't apply.
>
> You should not be pulling linux-next, you should be fetching.
> >
> > I mean although my patches did not based on latest linux-next(miss
> > several commits), but as I can see, they can be applied to latest
> > linux-next (tag next-20130218) successfully.
> >
>
> next-20130218 is not the latest linux-next as I've already said. Do this:
> go to
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next-history.git;a=blob_plain;f=arch/x86/mm/srat.c;hb=HEAD
> and search for handle_movablemem(). That's one of the functions added in
> one of the commits I mentioned and was from February. Now search your
> patch for handle_movablemem(). See a problem?
Yes, I know there's no new changes in my patch as I said before(not
based on lasted), but as I try to apply my patch(1/4), it will do
the right work to move current srat.c from arch/x86/mm/ to
arch/x86/kernel/acpi/ regardless of what I based is not latest.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 3:16 ` li guang
@ 2013-02-20 7:00 ` David Rientjes
2013-02-20 7:05 ` li guang
0 siblings, 1 reply; 16+ messages in thread
From: David Rientjes @ 2013-02-20 7:00 UTC (permalink / raw)
To: li guang; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
On Wed, 20 Feb 2013, li guang wrote:
> Yes, I know there's no new changes in my patch as I said before(not
> based on lasted), but as I try to apply my patch(1/4), it will do
> the right work to move current srat.c from arch/x86/mm/ to
> arch/x86/kernel/acpi/ regardless of what I based is not latest.
>
Sorry, but that makes no sense. Your patch cannot be used cleanly if
there have been subsequent changes to a hunk prior to applying it -- in
this case the hunk would be the entire file since you're removing it.
These patches would also be pushed by the x86 maintainers, who are not
cc'd on this patch, and I think it would be unfair to ask them to make up
for your inability to generate a bleeding edge patch with linux-next. The
changes already cited in this thread have been in linux-next for almost
two weeks, yet you refuse to rebase on top of them.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
2013-02-20 7:00 ` David Rientjes
@ 2013-02-20 7:05 ` li guang
0 siblings, 0 replies; 16+ messages in thread
From: li guang @ 2013-02-20 7:05 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, linux-acpi, x86, isimatu.yasuaki
在 2013-02-19二的 23:00 -0800，David Rientjes写道：
> On Wed, 20 Feb 2013, li guang wrote:
>
> > Yes, I know there's no new changes in my patch as I said before(not
> > based on lasted), but as I try to apply my patch(1/4), it will do
> > the right work to move current srat.c from arch/x86/mm/ to
> > arch/x86/kernel/acpi/ regardless of what I based is not latest.
> >
>
> Sorry, but that makes no sense. Your patch cannot be used cleanly if
> there have been subsequent changes to a hunk prior to applying it -- in
> this case the hunk would be the entire file since you're removing it.
>
> These patches would also be pushed by the x86 maintainers, who are not
> cc'd on this patch, and I think it would be unfair to ask them to make up
> for your inability to generate a bleeding edge patch with linux-next. The
> changes already cited in this thread have been in linux-next for almost
> two weeks, yet you refuse to rebase on top of them.
OK, I'd like to rebase,
Thanks!
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-02-20 7:05 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-15 2:23 [PATCH v4 0/4] acpi: do some changes for numa info liguang
2013-02-15 2:23 ` [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c liguang
2013-02-19 21:21 ` David Rientjes
2013-02-20 1:39 ` li guang
2013-02-20 1:51 ` li guang
2013-02-20 2:08 ` David Rientjes
2013-02-20 2:21 ` li guang
2013-02-20 2:26 ` li guang
2013-02-20 3:04 ` David Rientjes
2013-02-20 3:16 ` li guang
2013-02-20 7:00 ` David Rientjes
2013-02-20 7:05 ` li guang
2013-02-15 2:23 ` [PATCH v4 2/4] numa: avoid export acpi_numa variable liguang
2013-02-19 21:25 ` David Rientjes
2013-02-15 2:23 ` [PATCH v4 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity liguang
2013-02-15 2:23 ` [PATCH v4 4/4] remove include asm/acpi.h in process_driver.c liguang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®