* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming
Cc: Catalin Marinas, Leif Lindholm, Mark Rutland, Mark Salter,
Ganapatrao Kulkarni, linux-efi, linux-arm-kernel, linux-kernel,
Robert Richter
From: Robert Richter <rrichter@cavium.com>
Reposting an updated version of this patches ported to 4.5-rc1. It is
a followup to the version 3 from:
http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
The series is essential for NUMA on arm64. Early FDT handling is
required to make system topology data from firmware, esp. for cpus and
memory available to the early boot process. Ganapat's numa patches
depend on it. This series has been tested with his series v10 posted
here:
http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
A number of minor issues exist in the early UEFI/FDT handling path, such as:
- when booting via UEFI, memreserve entries are removed from the device tree but
the /reserved-memory node is not
- memory nodes are removed from the device tree in a way that is not officially
supported by the libfdt API (i.e., you cannot delete nodes while traversing
the tree)
- removal of memory nodes may discard annotations (such as NUMA topology) that
should ideally be retained, or may corrupt the tree by discarding nodes
referenced by phandles.
Patches #1 and #2 introduce an arm64 specific version of
early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
memory nodes if booting via UEFI.
Patch #3 moves some UEFI+FDT init code around before making changes to it.
Patch #4 moves the UEFI initialization to before the early FDT scanning so we
know at that point whether we are booting via UEFI or not.
Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
that they don't have to be removed by the stub anymore.
Patch #6 does the same as #5, but for memreserves and the /reserved-memory
node.
Changes since v3:
- prorted to v4.5-rc1
Changes since v2:
- instead of copying the generic implementation, turn
early_init_dt_add_memory_arch() into a weak alias so that it is still
accessible to overrides
Changes since v1:
- dropped first two patches, they have been merged into v4.2-rc1
- dropped last patch regarding FDT placement by the stub, this is not entirely
relevant to the primary issue targeted by this series
- rebased onto for-next/core (arm64) as of today
Ard Biesheuvel (6):
of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
arm64: override generic version of early_init_dt_add_memory_arch()
efi: move FDT handling to separate object file
arm64/efi: move EFI /chosen node parsing before early FDT processing
arm64/efi: ignore DT memory nodes instead of removing them
arm64/efi: ignore DT memreserve entries instead of removing them
arch/arm64/include/asm/efi.h | 2 +
arch/arm64/kernel/setup.c | 3 ++
arch/arm64/mm/init.c | 12 +++++-
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/arm-init.c | 36 ++++++++++------
drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
drivers/firmware/efi/libstub/fdt.c | 33 +--------------
drivers/of/fdt.c | 7 +++-
include/linux/efi.h | 2 +-
include/linux/of_fdt.h | 1 +
11 files changed, 121 insertions(+), 133 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
--
2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming
Cc: Mark Rutland, linux-efi, Catalin Marinas, linux-kernel,
Leif Lindholm, Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Robert Richter <rrichter@cavium.com>
Reposting an updated version of this patches ported to 4.5-rc1. It is
a followup to the version 3 from:
http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
The series is essential for NUMA on arm64. Early FDT handling is
required to make system topology data from firmware, esp. for cpus and
memory available to the early boot process. Ganapat's numa patches
depend on it. This series has been tested with his series v10 posted
here:
http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
A number of minor issues exist in the early UEFI/FDT handling path, such as:
- when booting via UEFI, memreserve entries are removed from the device tree but
the /reserved-memory node is not
- memory nodes are removed from the device tree in a way that is not officially
supported by the libfdt API (i.e., you cannot delete nodes while traversing
the tree)
- removal of memory nodes may discard annotations (such as NUMA topology) that
should ideally be retained, or may corrupt the tree by discarding nodes
referenced by phandles.
Patches #1 and #2 introduce an arm64 specific version of
early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
memory nodes if booting via UEFI.
Patch #3 moves some UEFI+FDT init code around before making changes to it.
Patch #4 moves the UEFI initialization to before the early FDT scanning so we
know at that point whether we are booting via UEFI or not.
Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
that they don't have to be removed by the stub anymore.
Patch #6 does the same as #5, but for memreserves and the /reserved-memory
node.
Changes since v3:
- prorted to v4.5-rc1
Changes since v2:
- instead of copying the generic implementation, turn
early_init_dt_add_memory_arch() into a weak alias so that it is still
accessible to overrides
Changes since v1:
- dropped first two patches, they have been merged into v4.2-rc1
- dropped last patch regarding FDT placement by the stub, this is not entirely
relevant to the primary issue targeted by this series
- rebased onto for-next/core (arm64) as of today
Ard Biesheuvel (6):
of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
arm64: override generic version of early_init_dt_add_memory_arch()
efi: move FDT handling to separate object file
arm64/efi: move EFI /chosen node parsing before early FDT processing
arm64/efi: ignore DT memory nodes instead of removing them
arm64/efi: ignore DT memreserve entries instead of removing them
arch/arm64/include/asm/efi.h | 2 +
arch/arm64/kernel/setup.c | 3 ++
arch/arm64/mm/init.c | 12 +++++-
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/arm-init.c | 36 ++++++++++------
drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
drivers/firmware/efi/libstub/fdt.c | 33 +--------------
drivers/of/fdt.c | 7 +++-
include/linux/efi.h | 2 +-
include/linux/of_fdt.h | 1 +
11 files changed, 121 insertions(+), 133 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
--
2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Robert Richter <rrichter@cavium.com>
Reposting an updated version of this patches ported to 4.5-rc1. It is
a followup to the version 3 from:
http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
The series is essential for NUMA on arm64. Early FDT handling is
required to make system topology data from firmware, esp. for cpus and
memory available to the early boot process. Ganapat's numa patches
depend on it. This series has been tested with his series v10 posted
here:
http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
A number of minor issues exist in the early UEFI/FDT handling path, such as:
- when booting via UEFI, memreserve entries are removed from the device tree but
the /reserved-memory node is not
- memory nodes are removed from the device tree in a way that is not officially
supported by the libfdt API (i.e., you cannot delete nodes while traversing
the tree)
- removal of memory nodes may discard annotations (such as NUMA topology) that
should ideally be retained, or may corrupt the tree by discarding nodes
referenced by phandles.
Patches #1 and #2 introduce an arm64 specific version of
early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
memory nodes if booting via UEFI.
Patch #3 moves some UEFI+FDT init code around before making changes to it.
Patch #4 moves the UEFI initialization to before the early FDT scanning so we
know at that point whether we are booting via UEFI or not.
Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
that they don't have to be removed by the stub anymore.
Patch #6 does the same as #5, but for memreserves and the /reserved-memory
node.
Changes since v3:
- prorted to v4.5-rc1
Changes since v2:
- instead of copying the generic implementation, turn
early_init_dt_add_memory_arch() into a weak alias so that it is still
accessible to overrides
Changes since v1:
- dropped first two patches, they have been merged into v4.2-rc1
- dropped last patch regarding FDT placement by the stub, this is not entirely
relevant to the primary issue targeted by this series
- rebased onto for-next/core (arm64) as of today
Ard Biesheuvel (6):
of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
arm64: override generic version of early_init_dt_add_memory_arch()
efi: move FDT handling to separate object file
arm64/efi: move EFI /chosen node parsing before early FDT processing
arm64/efi: ignore DT memory nodes instead of removing them
arm64/efi: ignore DT memreserve entries instead of removing them
arch/arm64/include/asm/efi.h | 2 +
arch/arm64/kernel/setup.c | 3 ++
arch/arm64/mm/init.c | 12 +++++-
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/arm-init.c | 36 ++++++++++------
drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
drivers/firmware/efi/libstub/fdt.c | 33 +--------------
drivers/of/fdt.c | 7 +++-
include/linux/efi.h | 2 +-
include/linux/of_fdt.h | 1 +
11 files changed, 121 insertions(+), 133 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
--
2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 1/6] of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Rob Herring,
Frank Rowand, Grant Likely
Cc: Catalin Marinas, Leif Lindholm, Mark Rutland, Mark Salter,
Ganapatrao Kulkarni, linux-efi, linux-arm-kernel, linux-kernel,
Robert Richter, devicetree
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The function early_init_dt_add_memory_arch() is defined as __weak
so that archs can override it. However, in this override implementation,
it may still be useful to invoke the generic implementation, so instead,
rename the generic version to early_init_dt_add_memory() and turn the
original definition into a weak alias. This way, the generic version can
still be called even in the presence of an arch specific override.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-2-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/of/fdt.c | 7 +++++--
include/linux/of_fdt.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..cba8281ab5fd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,7 +980,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
#define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
#endif
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
const u64 phys_offset = __pa(PAGE_OFFSET);
@@ -1038,7 +1038,7 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
return __va(memblock_alloc(size, align));
}
#else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
WARN_ON(1);
}
@@ -1058,6 +1058,9 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#endif
+__weak __alias(early_init_dt_add_memory)
+void early_init_dt_add_memory_arch(u64 base, u64 size);
+
bool __init early_init_dt_verify(void *params)
{
if (!params)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef3801812..463a06ba87ac 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -65,6 +65,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
int depth, void *data);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
+extern void early_init_dt_add_memory(u64 base, u64 size);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
bool no_map);
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 1/6] of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Rob Herring,
Frank Rowand, Grant Likely
Cc: Mark Rutland, devicetree, linux-efi, Catalin Marinas,
linux-kernel, Leif Lindholm, Robert Richter, Mark Salter,
Ganapatrao Kulkarni, linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The function early_init_dt_add_memory_arch() is defined as __weak
so that archs can override it. However, in this override implementation,
it may still be useful to invoke the generic implementation, so instead,
rename the generic version to early_init_dt_add_memory() and turn the
original definition into a weak alias. This way, the generic version can
still be called even in the presence of an arch specific override.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-2-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/of/fdt.c | 7 +++++--
include/linux/of_fdt.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..cba8281ab5fd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,7 +980,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
#define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
#endif
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
const u64 phys_offset = __pa(PAGE_OFFSET);
@@ -1038,7 +1038,7 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
return __va(memblock_alloc(size, align));
}
#else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
WARN_ON(1);
}
@@ -1058,6 +1058,9 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#endif
+__weak __alias(early_init_dt_add_memory)
+void early_init_dt_add_memory_arch(u64 base, u64 size);
+
bool __init early_init_dt_verify(void *params)
{
if (!params)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef3801812..463a06ba87ac 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -65,6 +65,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
int depth, void *data);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
+extern void early_init_dt_add_memory(u64 base, u64 size);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
bool no_map);
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 1/6] of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The function early_init_dt_add_memory_arch() is defined as __weak
so that archs can override it. However, in this override implementation,
it may still be useful to invoke the generic implementation, so instead,
rename the generic version to early_init_dt_add_memory() and turn the
original definition into a weak alias. This way, the generic version can
still be called even in the presence of an arch specific override.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-2-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/of/fdt.c | 7 +++++--
include/linux/of_fdt.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..cba8281ab5fd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,7 +980,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
#define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
#endif
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
const u64 phys_offset = __pa(PAGE_OFFSET);
@@ -1038,7 +1038,7 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
return __va(memblock_alloc(size, align));
}
#else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
{
WARN_ON(1);
}
@@ -1058,6 +1058,9 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#endif
+__weak __alias(early_init_dt_add_memory)
+void early_init_dt_add_memory_arch(u64 base, u64 size);
+
bool __init early_init_dt_verify(void *params)
{
if (!params)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef3801812..463a06ba87ac 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -65,6 +65,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
int depth, void *data);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
+extern void early_init_dt_add_memory(u64 base, u64 size);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
bool no_map);
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 2/6] arm64: override generic version of early_init_dt_add_memory_arch()
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Robert Richter
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Override the __weak early_init_dt_add_memory_arch() with our own
version. We need this in a subsequent patch to make the handling of
the memory nodes conditional on whether we are booting via UEFI or
not. Note that for now, all that our version does is invoke the generic
implementation.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-3-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..208c1d359018 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -380,3 +380,8 @@ static int __init keepinitrd_setup(char *__unused)
__setup("keepinitrd", keepinitrd_setup);
#endif
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ early_init_dt_add_memory(base, size);
+}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 2/6] arm64: override generic version of early_init_dt_add_memory_arch()
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Mark Rutland, linux-efi, linux-kernel, Leif Lindholm,
Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Override the __weak early_init_dt_add_memory_arch() with our own
version. We need this in a subsequent patch to make the handling of
the memory nodes conditional on whether we are booting via UEFI or
not. Note that for now, all that our version does is invoke the generic
implementation.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-3-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..208c1d359018 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -380,3 +380,8 @@ static int __init keepinitrd_setup(char *__unused)
__setup("keepinitrd", keepinitrd_setup);
#endif
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ early_init_dt_add_memory(base, size);
+}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 2/6] arm64: override generic version of early_init_dt_add_memory_arch()
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Override the __weak early_init_dt_add_memory_arch() with our own
version. We need this in a subsequent patch to make the handling of
the memory nodes conditional on whether we are booting via UEFI or
not. Note that for now, all that our version does is invoke the generic
implementation.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-3-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..208c1d359018 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -380,3 +380,8 @@ static int __init keepinitrd_setup(char *__unused)
__setup("keepinitrd", keepinitrd_setup);
#endif
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ early_init_dt_add_memory(base, size);
+}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 3/6] efi: move FDT handling to separate object file
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming
Cc: Catalin Marinas, Leif Lindholm, Mark Rutland, Mark Salter,
Ganapatrao Kulkarni, linux-efi, linux-arm-kernel, linux-kernel,
Robert Richter
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The EFI specific FDT handling is compiled conditionally, and is
logically independent of the rest of efi.o. So move it to a separate
file before making changes to it in subsequent patches.
Acked-by: Matt Fleming <matt.fleming@intel.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-4-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi-fdt.c | 91 ++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
3 files changed, 92 insertions(+), 84 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..bb7ec2fac25c 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
obj-$(CONFIG_EFI_STUB) += libstub/
obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o
+obj-$(CONFIG_EFI_PARAMS_FROM_FDT) += efi-fdt.o
arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o
obj-$(CONFIG_ARM) += $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
new file mode 100644
index 000000000000..8f3ce66e2b02
--- /dev/null
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 - 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#define UEFI_PARAM(name, prop, field) \
+ { \
+ { name }, \
+ { prop }, \
+ offsetof(struct efi_fdt_params, field), \
+ FIELD_SIZEOF(struct efi_fdt_params, field) \
+ }
+
+static __initdata struct {
+ const char name[32];
+ const char propname[32];
+ int offset;
+ int size;
+} dt_params[] = {
+ UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
+ UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
+ UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
+ UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
+ UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+};
+
+struct param_info {
+ int found;
+ void *params;
+};
+
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct param_info *info = data;
+ const void *prop;
+ void *dest;
+ u64 val;
+ int i, len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
+ if (!prop)
+ return 0;
+ dest = info->params + dt_params[i].offset;
+ info->found++;
+
+ val = of_read_number(prop, len / sizeof(u32));
+
+ if (dt_params[i].size == sizeof(u32))
+ *(u32 *)dest = val;
+ else
+ *(u64 *)dest = val;
+
+ if (efi_enabled(EFI_DBG))
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
+ }
+ return 1;
+}
+
+int __init efi_get_fdt_params(struct efi_fdt_params *params)
+{
+ struct param_info info;
+ int ret;
+
+ pr_info("Getting EFI parameters from FDT:\n");
+
+ info.found = 0;
+ info.params = params;
+
+ ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+ if (!info.found)
+ pr_info("UEFI not found.\n");
+ else if (!ret)
+ pr_err("Can't find '%s' in device tree!\n",
+ dt_params[info.found].name);
+
+ return ret;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..7c41c4284814 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -20,8 +20,6 @@
#include <linux/init.h>
#include <linux/device.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
#include <linux/io.h>
#include <linux/platform_device.h>
@@ -490,88 +488,6 @@ static int __init efi_load_efivars(void)
device_initcall(efi_load_efivars);
#endif
-#ifdef CONFIG_EFI_PARAMS_FROM_FDT
-
-#define UEFI_PARAM(name, prop, field) \
- { \
- { name }, \
- { prop }, \
- offsetof(struct efi_fdt_params, field), \
- FIELD_SIZEOF(struct efi_fdt_params, field) \
- }
-
-static __initdata struct {
- const char name[32];
- const char propname[32];
- int offset;
- int size;
-} dt_params[] = {
- UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
- UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
- UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
- UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
- UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
-};
-
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct param_info *info = data;
- const void *prop;
- void *dest;
- u64 val;
- int i, len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
-
- val = of_read_number(prop, len / sizeof(u32));
-
- if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
- else
- *(u64 *)dest = val;
-
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
- }
- return 1;
-}
-
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
- pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
-}
-#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
-
static __initdata char memory_type_name[][20] = {
"Reserved",
"Loader Code",
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 3/6] efi: move FDT handling to separate object file
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming
Cc: Mark Rutland, linux-efi, Catalin Marinas, linux-kernel,
Leif Lindholm, Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The EFI specific FDT handling is compiled conditionally, and is
logically independent of the rest of efi.o. So move it to a separate
file before making changes to it in subsequent patches.
Acked-by: Matt Fleming <matt.fleming@intel.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-4-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi-fdt.c | 91 ++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
3 files changed, 92 insertions(+), 84 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..bb7ec2fac25c 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
obj-$(CONFIG_EFI_STUB) += libstub/
obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o
+obj-$(CONFIG_EFI_PARAMS_FROM_FDT) += efi-fdt.o
arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o
obj-$(CONFIG_ARM) += $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
new file mode 100644
index 000000000000..8f3ce66e2b02
--- /dev/null
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 - 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#define UEFI_PARAM(name, prop, field) \
+ { \
+ { name }, \
+ { prop }, \
+ offsetof(struct efi_fdt_params, field), \
+ FIELD_SIZEOF(struct efi_fdt_params, field) \
+ }
+
+static __initdata struct {
+ const char name[32];
+ const char propname[32];
+ int offset;
+ int size;
+} dt_params[] = {
+ UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
+ UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
+ UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
+ UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
+ UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+};
+
+struct param_info {
+ int found;
+ void *params;
+};
+
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct param_info *info = data;
+ const void *prop;
+ void *dest;
+ u64 val;
+ int i, len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
+ if (!prop)
+ return 0;
+ dest = info->params + dt_params[i].offset;
+ info->found++;
+
+ val = of_read_number(prop, len / sizeof(u32));
+
+ if (dt_params[i].size == sizeof(u32))
+ *(u32 *)dest = val;
+ else
+ *(u64 *)dest = val;
+
+ if (efi_enabled(EFI_DBG))
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
+ }
+ return 1;
+}
+
+int __init efi_get_fdt_params(struct efi_fdt_params *params)
+{
+ struct param_info info;
+ int ret;
+
+ pr_info("Getting EFI parameters from FDT:\n");
+
+ info.found = 0;
+ info.params = params;
+
+ ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+ if (!info.found)
+ pr_info("UEFI not found.\n");
+ else if (!ret)
+ pr_err("Can't find '%s' in device tree!\n",
+ dt_params[info.found].name);
+
+ return ret;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..7c41c4284814 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -20,8 +20,6 @@
#include <linux/init.h>
#include <linux/device.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
#include <linux/io.h>
#include <linux/platform_device.h>
@@ -490,88 +488,6 @@ static int __init efi_load_efivars(void)
device_initcall(efi_load_efivars);
#endif
-#ifdef CONFIG_EFI_PARAMS_FROM_FDT
-
-#define UEFI_PARAM(name, prop, field) \
- { \
- { name }, \
- { prop }, \
- offsetof(struct efi_fdt_params, field), \
- FIELD_SIZEOF(struct efi_fdt_params, field) \
- }
-
-static __initdata struct {
- const char name[32];
- const char propname[32];
- int offset;
- int size;
-} dt_params[] = {
- UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
- UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
- UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
- UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
- UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
-};
-
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct param_info *info = data;
- const void *prop;
- void *dest;
- u64 val;
- int i, len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
-
- val = of_read_number(prop, len / sizeof(u32));
-
- if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
- else
- *(u64 *)dest = val;
-
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
- }
- return 1;
-}
-
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
- pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
-}
-#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
-
static __initdata char memory_type_name[][20] = {
"Reserved",
"Loader Code",
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 3/6] efi: move FDT handling to separate object file
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The EFI specific FDT handling is compiled conditionally, and is
logically independent of the rest of efi.o. So move it to a separate
file before making changes to it in subsequent patches.
Acked-by: Matt Fleming <matt.fleming@intel.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-4-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi-fdt.c | 91 ++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 84 --------------------------------------
3 files changed, 92 insertions(+), 84 deletions(-)
create mode 100644 drivers/firmware/efi/efi-fdt.c
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..bb7ec2fac25c 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
obj-$(CONFIG_EFI_STUB) += libstub/
obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o
+obj-$(CONFIG_EFI_PARAMS_FROM_FDT) += efi-fdt.o
arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o
obj-$(CONFIG_ARM) += $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
new file mode 100644
index 000000000000..8f3ce66e2b02
--- /dev/null
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 - 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#define UEFI_PARAM(name, prop, field) \
+ { \
+ { name }, \
+ { prop }, \
+ offsetof(struct efi_fdt_params, field), \
+ FIELD_SIZEOF(struct efi_fdt_params, field) \
+ }
+
+static __initdata struct {
+ const char name[32];
+ const char propname[32];
+ int offset;
+ int size;
+} dt_params[] = {
+ UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
+ UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
+ UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
+ UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
+ UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+};
+
+struct param_info {
+ int found;
+ void *params;
+};
+
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct param_info *info = data;
+ const void *prop;
+ void *dest;
+ u64 val;
+ int i, len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+ prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
+ if (!prop)
+ return 0;
+ dest = info->params + dt_params[i].offset;
+ info->found++;
+
+ val = of_read_number(prop, len / sizeof(u32));
+
+ if (dt_params[i].size == sizeof(u32))
+ *(u32 *)dest = val;
+ else
+ *(u64 *)dest = val;
+
+ if (efi_enabled(EFI_DBG))
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
+ }
+ return 1;
+}
+
+int __init efi_get_fdt_params(struct efi_fdt_params *params)
+{
+ struct param_info info;
+ int ret;
+
+ pr_info("Getting EFI parameters from FDT:\n");
+
+ info.found = 0;
+ info.params = params;
+
+ ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+ if (!info.found)
+ pr_info("UEFI not found.\n");
+ else if (!ret)
+ pr_err("Can't find '%s' in device tree!\n",
+ dt_params[info.found].name);
+
+ return ret;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..7c41c4284814 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -20,8 +20,6 @@
#include <linux/init.h>
#include <linux/device.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
#include <linux/io.h>
#include <linux/platform_device.h>
@@ -490,88 +488,6 @@ static int __init efi_load_efivars(void)
device_initcall(efi_load_efivars);
#endif
-#ifdef CONFIG_EFI_PARAMS_FROM_FDT
-
-#define UEFI_PARAM(name, prop, field) \
- { \
- { name }, \
- { prop }, \
- offsetof(struct efi_fdt_params, field), \
- FIELD_SIZEOF(struct efi_fdt_params, field) \
- }
-
-static __initdata struct {
- const char name[32];
- const char propname[32];
- int offset;
- int size;
-} dt_params[] = {
- UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
- UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
- UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
- UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
- UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
-};
-
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct param_info *info = data;
- const void *prop;
- void *dest;
- u64 val;
- int i, len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
-
- val = of_read_number(prop, len / sizeof(u32));
-
- if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
- else
- *(u64 *)dest = val;
-
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
- }
- return 1;
-}
-
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
- pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
-}
-#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
-
static __initdata char memory_type_name[][20] = {
"Reserved",
"Loader Code",
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 4/6] arm64/efi: move EFI /chosen node parsing before early FDT processing
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Robert Richter
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The early FDT processing is responsible for enumerating the
DT memory nodes and installing them as memblocks. This should
only be done if we are not booting via EFI, but at this point,
we don't know yet if that is the case or not.
So move part of the EFI init to before the early FDT processing. This
involves making some changes to the way EFI discovers the locations of
the EFI system table and the memory map, since those values are retrieved
from the FDT as well. Instead the of_scan infrastructure, it now uses
libfdt directly to access the /chosen node.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-5-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/include/asm/efi.h | 2 ++
arch/arm64/kernel/setup.c | 3 ++
drivers/firmware/efi/arm-init.c | 34 ++++++++++++-------
drivers/firmware/efi/efi-fdt.c | 72 ++++++++++++++++-------------------------
include/linux/efi.h | 2 +-
5 files changed, 55 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a696c9cb..acc7f65cef47 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -8,8 +8,10 @@
#ifdef CONFIG_EFI
extern void efi_init(void);
+extern void efi_parse_fdt(void *fdt);
#else
#define efi_init()
+#define efi_parse_fdt(x)
#endif
int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479147db..3f5723329173 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,6 +181,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
void *dt_virt = fixmap_remap_fdt(dt_phys);
+ if (dt_virt)
+ efi_parse_fdt(dt_virt);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..9fe04648d4d3 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -170,22 +170,35 @@ static __init void reserve_regions(void)
if (efi_enabled(EFI_DBG))
pr_cont("\n");
}
-
- set_bit(EFI_MEMMAP, &efi.flags);
}
-void __init efi_init(void)
+void __init efi_parse_fdt(void *fdt)
{
struct efi_fdt_params params;
/* Grab UEFI information placed in FDT by stub */
- if (!efi_get_fdt_params(¶ms))
+ if (!efi_get_fdt_params(fdt, ¶ms))
return;
efi_system_table = params.system_table;
memmap.phys_map = params.mmap;
- memmap.map = early_memremap(params.mmap, params.mmap_size);
+ memmap.desc_size = params.desc_size;
+ memmap.desc_version = params.desc_ver;
+ memmap.nr_map = params.mmap_size / params.desc_size;
+
+ set_bit(EFI_MEMMAP, &efi.flags);
+}
+
+void __init efi_init(void)
+{
+ int mmap_size = memmap.nr_map * memmap.desc_size;
+ u64 phys_map = memmap.phys_map;
+
+ if (!efi_enabled(EFI_MEMMAP))
+ return;
+
+ memmap.map = early_memremap(phys_map, mmap_size);
if (memmap.map == NULL) {
/*
* If we are booting via UEFI, the UEFI memory map is the only
@@ -194,16 +207,13 @@ void __init efi_init(void)
*/
panic("Unable to map EFI memory map.\n");
}
- memmap.map_end = memmap.map + params.mmap_size;
- memmap.desc_size = params.desc_size;
- memmap.desc_version = params.desc_ver;
+ memmap.map_end = memmap.map + mmap_size;
if (uefi_init() < 0)
return;
reserve_regions();
- early_memunmap(memmap.map, params.mmap_size);
- memblock_mark_nomap(params.mmap & PAGE_MASK,
- PAGE_ALIGN(params.mmap_size +
- (params.mmap & ~PAGE_MASK)));
+ early_memunmap(memmap.map, mmap_size);
+ memblock_mark_nomap(phys_map & PAGE_MASK,
+ PAGE_ALIGN(mmap_size + (phys_map & ~PAGE_MASK)));
}
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
index 8f3ce66e2b02..e6622d3182ae 100644
--- a/drivers/firmware/efi/efi-fdt.c
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -8,8 +8,7 @@
#include <linux/init.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
+#include <linux/libfdt.h>
#define UEFI_PARAM(name, prop, field) \
{ \
@@ -32,60 +31,43 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
+int __init efi_get_fdt_params(void *fdt, struct efi_fdt_params *params)
{
- struct param_info *info = data;
const void *prop;
- void *dest;
- u64 val;
- int i, len;
+ int node, i;
+
+ pr_info("Getting EFI parameters from FDT:\n");
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ node = fdt_path_offset(fdt, "/chosen");
+ if (node < 0) {
+ pr_err("/chosen node not found!\n");
+ return false;
+ }
for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
+ void *dest;
+ int len;
+ u64 val;
- val = of_read_number(prop, len / sizeof(u32));
+ prop = fdt_getprop(fdt, node, dt_params[i].propname, &len);
+ if (!prop || len != dt_params[i].size)
+ goto not_found;
+ dest = (void *)params + dt_params[i].offset;
if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
+ val = *(u32 *)dest = be32_to_cpup(prop);
else
- *(u64 *)dest = val;
+ val = *(u64 *)dest = be64_to_cpup(prop);
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
}
- return 1;
-}
+ return true;
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
+not_found:
+ if (i == 0)
pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
+ else
+ pr_err("Can't find '%s' in device tree!\n", dt_params[i].name);
+ return false;
}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a866bb1..ede2c21c651b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -915,7 +915,7 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
extern void efi_get_time(struct timespec *now);
extern void efi_reserve_boot_services(void);
-extern int efi_get_fdt_params(struct efi_fdt_params *params);
+extern int efi_get_fdt_params(void *fdt, struct efi_fdt_params *params);
extern struct efi_memory_map memmap;
extern struct kobject *efi_kobj;
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 4/6] arm64/efi: move EFI /chosen node parsing before early FDT processing
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Mark Rutland, linux-efi, linux-kernel, Leif Lindholm,
Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The early FDT processing is responsible for enumerating the
DT memory nodes and installing them as memblocks. This should
only be done if we are not booting via EFI, but at this point,
we don't know yet if that is the case or not.
So move part of the EFI init to before the early FDT processing. This
involves making some changes to the way EFI discovers the locations of
the EFI system table and the memory map, since those values are retrieved
from the FDT as well. Instead the of_scan infrastructure, it now uses
libfdt directly to access the /chosen node.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-5-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/include/asm/efi.h | 2 ++
arch/arm64/kernel/setup.c | 3 ++
drivers/firmware/efi/arm-init.c | 34 ++++++++++++-------
drivers/firmware/efi/efi-fdt.c | 72 ++++++++++++++++-------------------------
include/linux/efi.h | 2 +-
5 files changed, 55 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a696c9cb..acc7f65cef47 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -8,8 +8,10 @@
#ifdef CONFIG_EFI
extern void efi_init(void);
+extern void efi_parse_fdt(void *fdt);
#else
#define efi_init()
+#define efi_parse_fdt(x)
#endif
int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479147db..3f5723329173 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,6 +181,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
void *dt_virt = fixmap_remap_fdt(dt_phys);
+ if (dt_virt)
+ efi_parse_fdt(dt_virt);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..9fe04648d4d3 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -170,22 +170,35 @@ static __init void reserve_regions(void)
if (efi_enabled(EFI_DBG))
pr_cont("\n");
}
-
- set_bit(EFI_MEMMAP, &efi.flags);
}
-void __init efi_init(void)
+void __init efi_parse_fdt(void *fdt)
{
struct efi_fdt_params params;
/* Grab UEFI information placed in FDT by stub */
- if (!efi_get_fdt_params(¶ms))
+ if (!efi_get_fdt_params(fdt, ¶ms))
return;
efi_system_table = params.system_table;
memmap.phys_map = params.mmap;
- memmap.map = early_memremap(params.mmap, params.mmap_size);
+ memmap.desc_size = params.desc_size;
+ memmap.desc_version = params.desc_ver;
+ memmap.nr_map = params.mmap_size / params.desc_size;
+
+ set_bit(EFI_MEMMAP, &efi.flags);
+}
+
+void __init efi_init(void)
+{
+ int mmap_size = memmap.nr_map * memmap.desc_size;
+ u64 phys_map = memmap.phys_map;
+
+ if (!efi_enabled(EFI_MEMMAP))
+ return;
+
+ memmap.map = early_memremap(phys_map, mmap_size);
if (memmap.map == NULL) {
/*
* If we are booting via UEFI, the UEFI memory map is the only
@@ -194,16 +207,13 @@ void __init efi_init(void)
*/
panic("Unable to map EFI memory map.\n");
}
- memmap.map_end = memmap.map + params.mmap_size;
- memmap.desc_size = params.desc_size;
- memmap.desc_version = params.desc_ver;
+ memmap.map_end = memmap.map + mmap_size;
if (uefi_init() < 0)
return;
reserve_regions();
- early_memunmap(memmap.map, params.mmap_size);
- memblock_mark_nomap(params.mmap & PAGE_MASK,
- PAGE_ALIGN(params.mmap_size +
- (params.mmap & ~PAGE_MASK)));
+ early_memunmap(memmap.map, mmap_size);
+ memblock_mark_nomap(phys_map & PAGE_MASK,
+ PAGE_ALIGN(mmap_size + (phys_map & ~PAGE_MASK)));
}
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
index 8f3ce66e2b02..e6622d3182ae 100644
--- a/drivers/firmware/efi/efi-fdt.c
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -8,8 +8,7 @@
#include <linux/init.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
+#include <linux/libfdt.h>
#define UEFI_PARAM(name, prop, field) \
{ \
@@ -32,60 +31,43 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
+int __init efi_get_fdt_params(void *fdt, struct efi_fdt_params *params)
{
- struct param_info *info = data;
const void *prop;
- void *dest;
- u64 val;
- int i, len;
+ int node, i;
+
+ pr_info("Getting EFI parameters from FDT:\n");
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ node = fdt_path_offset(fdt, "/chosen");
+ if (node < 0) {
+ pr_err("/chosen node not found!\n");
+ return false;
+ }
for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
+ void *dest;
+ int len;
+ u64 val;
- val = of_read_number(prop, len / sizeof(u32));
+ prop = fdt_getprop(fdt, node, dt_params[i].propname, &len);
+ if (!prop || len != dt_params[i].size)
+ goto not_found;
+ dest = (void *)params + dt_params[i].offset;
if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
+ val = *(u32 *)dest = be32_to_cpup(prop);
else
- *(u64 *)dest = val;
+ val = *(u64 *)dest = be64_to_cpup(prop);
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
}
- return 1;
-}
+ return true;
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
+not_found:
+ if (i == 0)
pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
+ else
+ pr_err("Can't find '%s' in device tree!\n", dt_params[i].name);
+ return false;
}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a866bb1..ede2c21c651b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -915,7 +915,7 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
extern void efi_get_time(struct timespec *now);
extern void efi_reserve_boot_services(void);
-extern int efi_get_fdt_params(struct efi_fdt_params *params);
+extern int efi_get_fdt_params(void *fdt, struct efi_fdt_params *params);
extern struct efi_memory_map memmap;
extern struct kobject *efi_kobj;
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 4/6] arm64/efi: move EFI /chosen node parsing before early FDT processing
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The early FDT processing is responsible for enumerating the
DT memory nodes and installing them as memblocks. This should
only be done if we are not booting via EFI, but at this point,
we don't know yet if that is the case or not.
So move part of the EFI init to before the early FDT processing. This
involves making some changes to the way EFI discovers the locations of
the EFI system table and the memory map, since those values are retrieved
from the FDT as well. Instead the of_scan infrastructure, it now uses
libfdt directly to access the /chosen node.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-5-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/include/asm/efi.h | 2 ++
arch/arm64/kernel/setup.c | 3 ++
drivers/firmware/efi/arm-init.c | 34 ++++++++++++-------
drivers/firmware/efi/efi-fdt.c | 72 ++++++++++++++++-------------------------
include/linux/efi.h | 2 +-
5 files changed, 55 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a696c9cb..acc7f65cef47 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -8,8 +8,10 @@
#ifdef CONFIG_EFI
extern void efi_init(void);
+extern void efi_parse_fdt(void *fdt);
#else
#define efi_init()
+#define efi_parse_fdt(x)
#endif
int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479147db..3f5723329173 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,6 +181,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
void *dt_virt = fixmap_remap_fdt(dt_phys);
+ if (dt_virt)
+ efi_parse_fdt(dt_virt);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..9fe04648d4d3 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -170,22 +170,35 @@ static __init void reserve_regions(void)
if (efi_enabled(EFI_DBG))
pr_cont("\n");
}
-
- set_bit(EFI_MEMMAP, &efi.flags);
}
-void __init efi_init(void)
+void __init efi_parse_fdt(void *fdt)
{
struct efi_fdt_params params;
/* Grab UEFI information placed in FDT by stub */
- if (!efi_get_fdt_params(¶ms))
+ if (!efi_get_fdt_params(fdt, ¶ms))
return;
efi_system_table = params.system_table;
memmap.phys_map = params.mmap;
- memmap.map = early_memremap(params.mmap, params.mmap_size);
+ memmap.desc_size = params.desc_size;
+ memmap.desc_version = params.desc_ver;
+ memmap.nr_map = params.mmap_size / params.desc_size;
+
+ set_bit(EFI_MEMMAP, &efi.flags);
+}
+
+void __init efi_init(void)
+{
+ int mmap_size = memmap.nr_map * memmap.desc_size;
+ u64 phys_map = memmap.phys_map;
+
+ if (!efi_enabled(EFI_MEMMAP))
+ return;
+
+ memmap.map = early_memremap(phys_map, mmap_size);
if (memmap.map == NULL) {
/*
* If we are booting via UEFI, the UEFI memory map is the only
@@ -194,16 +207,13 @@ void __init efi_init(void)
*/
panic("Unable to map EFI memory map.\n");
}
- memmap.map_end = memmap.map + params.mmap_size;
- memmap.desc_size = params.desc_size;
- memmap.desc_version = params.desc_ver;
+ memmap.map_end = memmap.map + mmap_size;
if (uefi_init() < 0)
return;
reserve_regions();
- early_memunmap(memmap.map, params.mmap_size);
- memblock_mark_nomap(params.mmap & PAGE_MASK,
- PAGE_ALIGN(params.mmap_size +
- (params.mmap & ~PAGE_MASK)));
+ early_memunmap(memmap.map, mmap_size);
+ memblock_mark_nomap(phys_map & PAGE_MASK,
+ PAGE_ALIGN(mmap_size + (phys_map & ~PAGE_MASK)));
}
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
index 8f3ce66e2b02..e6622d3182ae 100644
--- a/drivers/firmware/efi/efi-fdt.c
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -8,8 +8,7 @@
#include <linux/init.h>
#include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
+#include <linux/libfdt.h>
#define UEFI_PARAM(name, prop, field) \
{ \
@@ -32,60 +31,43 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
};
-struct param_info {
- int found;
- void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
- int depth, void *data)
+int __init efi_get_fdt_params(void *fdt, struct efi_fdt_params *params)
{
- struct param_info *info = data;
const void *prop;
- void *dest;
- u64 val;
- int i, len;
+ int node, i;
+
+ pr_info("Getting EFI parameters from FDT:\n");
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
+ node = fdt_path_offset(fdt, "/chosen");
+ if (node < 0) {
+ pr_err("/chosen node not found!\n");
+ return false;
+ }
for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
- prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
- if (!prop)
- return 0;
- dest = info->params + dt_params[i].offset;
- info->found++;
+ void *dest;
+ int len;
+ u64 val;
- val = of_read_number(prop, len / sizeof(u32));
+ prop = fdt_getprop(fdt, node, dt_params[i].propname, &len);
+ if (!prop || len != dt_params[i].size)
+ goto not_found;
+ dest = (void *)params + dt_params[i].offset;
if (dt_params[i].size == sizeof(u32))
- *(u32 *)dest = val;
+ val = *(u32 *)dest = be32_to_cpup(prop);
else
- *(u64 *)dest = val;
+ val = *(u64 *)dest = be64_to_cpup(prop);
- if (efi_enabled(EFI_DBG))
- pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
- dt_params[i].size * 2, val);
+ pr_info(" %s: 0x%0*llx\n", dt_params[i].name,
+ dt_params[i].size * 2, val);
}
- return 1;
-}
+ return true;
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
- struct param_info info;
- int ret;
-
- pr_info("Getting EFI parameters from FDT:\n");
-
- info.found = 0;
- info.params = params;
-
- ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
- if (!info.found)
+not_found:
+ if (i == 0)
pr_info("UEFI not found.\n");
- else if (!ret)
- pr_err("Can't find '%s' in device tree!\n",
- dt_params[info.found].name);
-
- return ret;
+ else
+ pr_err("Can't find '%s' in device tree!\n", dt_params[i].name);
+ return false;
}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a866bb1..ede2c21c651b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -915,7 +915,7 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
extern void efi_get_time(struct timespec *now);
extern void efi_reserve_boot_services(void);
-extern int efi_get_fdt_params(struct efi_fdt_params *params);
+extern int efi_get_fdt_params(void *fdt, struct efi_fdt_params *params);
extern struct efi_memory_map memmap;
extern struct kobject *efi_kobj;
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 5/6] arm64/efi: ignore DT memory nodes instead of removing them
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Robert Richter
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
of additional properties on the nodes.
Now that the UEFI initialization has moved to an earlier stage, we can
actually just ignore any memblocks that are installed after we have
processed the UEFI memory map. This way, it is no longer necessary to
remove the nodes, so we can remove that logic from the stub as well.
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-6-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 6 +++++-
drivers/firmware/efi/arm-init.c | 2 +-
drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
3 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 208c1d359018..eda226e85c71 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -383,5 +383,9 @@ __setup("keepinitrd", keepinitrd_setup);
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
- early_init_dt_add_memory(base, size);
+ /*
+ * Ignore DT memory nodes if we are booting via UEFI.
+ */
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_dt_add_memory(base, size);
}
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9fe04648d4d3..ded895706633 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,7 +159,7 @@ static __init void reserve_regions(void)
size = npages << PAGE_SHIFT;
if (is_normal_ram(md))
- early_init_dt_add_memory_arch(paddr, size);
+ early_init_dt_add_memory(paddr, size);
if (is_reserve_region(md)) {
memblock_mark_nomap(paddr, size);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d46302a..9df1560d57bc 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, prev, num_rsv;
+ int node, num_rsv;
int status;
u32 fdt_val32;
u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
goto fdt_set_fail;
/*
- * Delete any memory nodes present. We must delete nodes which
- * early_init_dt_scan_memory may try to use.
- */
- prev = 0;
- for (;;) {
- const char *type;
- int len;
-
- node = fdt_next_node(fdt, prev, NULL);
- if (node < 0)
- break;
-
- type = fdt_getprop(fdt, node, "device_type", &len);
- if (type && strncmp(type, "memory", len) == 0) {
- fdt_del_node(fdt, node);
- continue;
- }
-
- prev = node;
- }
-
- /*
* Delete all memory reserve map entries. When booting via UEFI,
* kernel will use the UEFI memory map to find reserved regions.
*/
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 5/6] arm64/efi: ignore DT memory nodes instead of removing them
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Mark Rutland, linux-efi, linux-kernel, Leif Lindholm,
Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
of additional properties on the nodes.
Now that the UEFI initialization has moved to an earlier stage, we can
actually just ignore any memblocks that are installed after we have
processed the UEFI memory map. This way, it is no longer necessary to
remove the nodes, so we can remove that logic from the stub as well.
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-6-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 6 +++++-
drivers/firmware/efi/arm-init.c | 2 +-
drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
3 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 208c1d359018..eda226e85c71 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -383,5 +383,9 @@ __setup("keepinitrd", keepinitrd_setup);
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
- early_init_dt_add_memory(base, size);
+ /*
+ * Ignore DT memory nodes if we are booting via UEFI.
+ */
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_dt_add_memory(base, size);
}
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9fe04648d4d3..ded895706633 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,7 +159,7 @@ static __init void reserve_regions(void)
size = npages << PAGE_SHIFT;
if (is_normal_ram(md))
- early_init_dt_add_memory_arch(paddr, size);
+ early_init_dt_add_memory(paddr, size);
if (is_reserve_region(md)) {
memblock_mark_nomap(paddr, size);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d46302a..9df1560d57bc 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, prev, num_rsv;
+ int node, num_rsv;
int status;
u32 fdt_val32;
u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
goto fdt_set_fail;
/*
- * Delete any memory nodes present. We must delete nodes which
- * early_init_dt_scan_memory may try to use.
- */
- prev = 0;
- for (;;) {
- const char *type;
- int len;
-
- node = fdt_next_node(fdt, prev, NULL);
- if (node < 0)
- break;
-
- type = fdt_getprop(fdt, node, "device_type", &len);
- if (type && strncmp(type, "memory", len) == 0) {
- fdt_del_node(fdt, node);
- continue;
- }
-
- prev = node;
- }
-
- /*
* Delete all memory reserve map entries. When booting via UEFI,
* kernel will use the UEFI memory map to find reserved regions.
*/
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 5/6] arm64/efi: ignore DT memory nodes instead of removing them
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
of additional properties on the nodes.
Now that the UEFI initialization has moved to an earlier stage, we can
actually just ignore any memblocks that are installed after we have
processed the UEFI memory map. This way, it is no longer necessary to
remove the nodes, so we can remove that logic from the stub as well.
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-6-git-send-email-ard.biesheuvel@linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 6 +++++-
drivers/firmware/efi/arm-init.c | 2 +-
drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
3 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 208c1d359018..eda226e85c71 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -383,5 +383,9 @@ __setup("keepinitrd", keepinitrd_setup);
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
- early_init_dt_add_memory(base, size);
+ /*
+ * Ignore DT memory nodes if we are booting via UEFI.
+ */
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_dt_add_memory(base, size);
}
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9fe04648d4d3..ded895706633 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,7 +159,7 @@ static __init void reserve_regions(void)
size = npages << PAGE_SHIFT;
if (is_normal_ram(md))
- early_init_dt_add_memory_arch(paddr, size);
+ early_init_dt_add_memory(paddr, size);
if (is_reserve_region(md)) {
memblock_mark_nomap(paddr, size);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d46302a..9df1560d57bc 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, prev, num_rsv;
+ int node, num_rsv;
int status;
u32 fdt_val32;
u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
goto fdt_set_fail;
/*
- * Delete any memory nodes present. We must delete nodes which
- * early_init_dt_scan_memory may try to use.
- */
- prev = 0;
- for (;;) {
- const char *type;
- int len;
-
- node = fdt_next_node(fdt, prev, NULL);
- if (node < 0)
- break;
-
- type = fdt_getprop(fdt, node, "device_type", &len);
- if (type && strncmp(type, "memory", len) == 0) {
- fdt_del_node(fdt, node);
- continue;
- }
-
- prev = node;
- }
-
- /*
* Delete all memory reserve map entries. When booting via UEFI,
* kernel will use the UEFI memory map to find reserved regions.
*/
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 6/6] arm64/efi: ignore DT memreserve entries instead of removing them
2016-02-09 13:53 ` Robert Richter
(?)
@ 2016-02-09 13:53 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Robert Richter
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Now that the reservation of the FDT image itself is split off from
the processing of memory reservations described by the device tree,
we can make the DT scanning of memreserves conditional on whether
we booted via UEFI and have its memory map available. This allows
us to drop deletion of these memreserves in the stub. It also fixes
the issue where the /reserved-memory node (which offers another
way of reserving memory ranges) was not being ignored under UEFI.
Note that this reverts 0ceac9e094b0 ("efi/arm64: Fix fdt-related
memory reservation").
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-7-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 3 ++-
drivers/firmware/efi/libstub/fdt.c | 11 +----------
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eda226e85c71..ee061658866f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -171,7 +171,8 @@ void __init arm64_memblock_init(void)
memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
#endif
- early_init_fdt_scan_reserved_mem();
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_fdt_scan_reserved_mem();
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 9df1560d57bc..12cb2a30a63f 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,8 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, num_rsv;
- int status;
+ int node, status;
u32 fdt_val32;
u64 fdt_val64;
@@ -53,14 +52,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
if (status != 0)
goto fdt_set_fail;
- /*
- * Delete all memory reserve map entries. When booting via UEFI,
- * kernel will use the UEFI memory map to find reserved regions.
- */
- num_rsv = fdt_num_mem_rsv(fdt);
- while (num_rsv-- > 0)
- fdt_del_mem_rsv(fdt, num_rsv);
-
node = fdt_subnode_offset(fdt, 0, "chosen");
if (node < 0) {
node = fdt_add_subnode(fdt, 0, "chosen");
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 6/6] arm64/efi: ignore DT memreserve entries instead of removing them
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon, Matt Fleming, Catalin Marinas
Cc: Mark Rutland, linux-efi, linux-kernel, Leif Lindholm,
Robert Richter, Mark Salter, Ganapatrao Kulkarni,
linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Now that the reservation of the FDT image itself is split off from
the processing of memory reservations described by the device tree,
we can make the DT scanning of memreserves conditional on whether
we booted via UEFI and have its memory map available. This allows
us to drop deletion of these memreserves in the stub. It also fixes
the issue where the /reserved-memory node (which offers another
way of reserving memory ranges) was not being ignored under UEFI.
Note that this reverts 0ceac9e094b0 ("efi/arm64: Fix fdt-related
memory reservation").
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-7-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 3 ++-
drivers/firmware/efi/libstub/fdt.c | 11 +----------
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eda226e85c71..ee061658866f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -171,7 +171,8 @@ void __init arm64_memblock_init(void)
memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
#endif
- early_init_fdt_scan_reserved_mem();
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_fdt_scan_reserved_mem();
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 9df1560d57bc..12cb2a30a63f 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,8 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, num_rsv;
- int status;
+ int node, status;
u32 fdt_val32;
u64 fdt_val64;
@@ -53,14 +52,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
if (status != 0)
goto fdt_set_fail;
- /*
- * Delete all memory reserve map entries. When booting via UEFI,
- * kernel will use the UEFI memory map to find reserved regions.
- */
- num_rsv = fdt_num_mem_rsv(fdt);
- while (num_rsv-- > 0)
- fdt_del_mem_rsv(fdt, num_rsv);
-
node = fdt_subnode_offset(fdt, 0, "chosen");
if (node < 0) {
node = fdt_add_subnode(fdt, 0, "chosen");
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v4 6/6] arm64/efi: ignore DT memreserve entries instead of removing them
@ 2016-02-09 13:53 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-09 13:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Now that the reservation of the FDT image itself is split off from
the processing of memory reservations described by the device tree,
we can make the DT scanning of memreserves conditional on whether
we booted via UEFI and have its memory map available. This allows
us to drop deletion of these memreserves in the stub. It also fixes
the issue where the /reserved-memory node (which offers another
way of reserving memory ranges) was not being ignored under UEFI.
Note that this reverts 0ceac9e094b0 ("efi/arm64: Fix fdt-related
memory reservation").
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <1442881288-13962-7-git-send-email-ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 3 ++-
drivers/firmware/efi/libstub/fdt.c | 11 +----------
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eda226e85c71..ee061658866f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -171,7 +171,8 @@ void __init arm64_memblock_init(void)
memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
#endif
- early_init_fdt_scan_reserved_mem();
+ if (!efi_enabled(EFI_MEMMAP))
+ early_init_fdt_scan_reserved_mem();
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 9df1560d57bc..12cb2a30a63f 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,8 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
{
- int node, num_rsv;
- int status;
+ int node, status;
u32 fdt_val32;
u64 fdt_val64;
@@ -53,14 +52,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
if (status != 0)
goto fdt_set_fail;
- /*
- * Delete all memory reserve map entries. When booting via UEFI,
- * kernel will use the UEFI memory map to find reserved regions.
- */
- num_rsv = fdt_num_mem_rsv(fdt);
- while (num_rsv-- > 0)
- fdt_del_mem_rsv(fdt, num_rsv);
-
node = fdt_subnode_offset(fdt, 0, "chosen");
if (node < 0) {
node = fdt_add_subnode(fdt, 0, "chosen");
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 14:35 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-09 14:35 UTC (permalink / raw)
To: Robert Richter, Grant Likely
Cc: Will Deacon, Matt Fleming, Catalin Marinas, Leif Lindholm,
Mark Rutland, Mark Salter, Ganapatrao Kulkarni, linux-efi,
linux-arm-kernel, linux-kernel, Robert Richter
(+ Grant)
On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
> From: Robert Richter <rrichter@cavium.com>
>
> Reposting an updated version of this patches ported to 4.5-rc1. It is
> a followup to the version 3 from:
>
> http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>
> The series is essential for NUMA on arm64. Early FDT handling is
> required to make system topology data from firmware, esp. for cpus and
> memory available to the early boot process. Ganapat's numa patches
> depend on it. This series has been tested with his series v10 posted
> here:
>
> http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>
Hello Robert,
This series does not reflect anymore what we think is the best way to
deal with memory nodes and memreserves on UEFI systems.
Please refer to this thread:
http://thread.gmane.org/gmane.linux.kernel.efi/6464
As far as the memory nodes are concerned, if it is the best place to
store these NUMA annotations, then we should indeed preserve them, but
I think the discussion stalled without any conclusion having been
reached. As far as the /reserved-memory node is concerned, that one we
should really keep, so at least patch 6/6 of this series should be
replaced with something based on the series above.
Thanks,
Ard.
> A number of minor issues exist in the early UEFI/FDT handling path, such as:
> - when booting via UEFI, memreserve entries are removed from the device tree but
> the /reserved-memory node is not
> - memory nodes are removed from the device tree in a way that is not officially
> supported by the libfdt API (i.e., you cannot delete nodes while traversing
> the tree)
> - removal of memory nodes may discard annotations (such as NUMA topology) that
> should ideally be retained, or may corrupt the tree by discarding nodes
> referenced by phandles.
>
> Patches #1 and #2 introduce an arm64 specific version of
> early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> memory nodes if booting via UEFI.
>
> Patch #3 moves some UEFI+FDT init code around before making changes to it.
>
> Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> know at that point whether we are booting via UEFI or not.
>
> Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> that they don't have to be removed by the stub anymore.
>
> Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> node.
>
> Changes since v3:
> - prorted to v4.5-rc1
>
> Changes since v2:
> - instead of copying the generic implementation, turn
> early_init_dt_add_memory_arch() into a weak alias so that it is still
> accessible to overrides
>
> Changes since v1:
> - dropped first two patches, they have been merged into v4.2-rc1
> - dropped last patch regarding FDT placement by the stub, this is not entirely
> relevant to the primary issue targeted by this series
> - rebased onto for-next/core (arm64) as of today
>
> Ard Biesheuvel (6):
> of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> arm64: override generic version of early_init_dt_add_memory_arch()
> efi: move FDT handling to separate object file
> arm64/efi: move EFI /chosen node parsing before early FDT processing
> arm64/efi: ignore DT memory nodes instead of removing them
> arm64/efi: ignore DT memreserve entries instead of removing them
>
> arch/arm64/include/asm/efi.h | 2 +
> arch/arm64/kernel/setup.c | 3 ++
> arch/arm64/mm/init.c | 12 +++++-
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> drivers/firmware/efi/efi.c | 84 --------------------------------------
> drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> drivers/of/fdt.c | 7 +++-
> include/linux/efi.h | 2 +-
> include/linux/of_fdt.h | 1 +
> 11 files changed, 121 insertions(+), 133 deletions(-)
> create mode 100644 drivers/firmware/efi/efi-fdt.c
>
> --
> 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 14:35 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-09 14:35 UTC (permalink / raw)
To: Robert Richter, Grant Likely
Cc: Will Deacon, Matt Fleming, Catalin Marinas, Leif Lindholm,
Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Robert Richter
(+ Grant)
On 9 February 2016 at 14:53, Robert Richter <rrichter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> From: Robert Richter <rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>
> Reposting an updated version of this patches ported to 4.5-rc1. It is
> a followup to the version 3 from:
>
> http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
>
> The series is essential for NUMA on arm64. Early FDT handling is
> required to make system topology data from firmware, esp. for cpus and
> memory available to the early boot process. Ganapat's numa patches
> depend on it. This series has been tested with his series v10 posted
> here:
>
> http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
>
Hello Robert,
This series does not reflect anymore what we think is the best way to
deal with memory nodes and memreserves on UEFI systems.
Please refer to this thread:
http://thread.gmane.org/gmane.linux.kernel.efi/6464
As far as the memory nodes are concerned, if it is the best place to
store these NUMA annotations, then we should indeed preserve them, but
I think the discussion stalled without any conclusion having been
reached. As far as the /reserved-memory node is concerned, that one we
should really keep, so at least patch 6/6 of this series should be
replaced with something based on the series above.
Thanks,
Ard.
> A number of minor issues exist in the early UEFI/FDT handling path, such as:
> - when booting via UEFI, memreserve entries are removed from the device tree but
> the /reserved-memory node is not
> - memory nodes are removed from the device tree in a way that is not officially
> supported by the libfdt API (i.e., you cannot delete nodes while traversing
> the tree)
> - removal of memory nodes may discard annotations (such as NUMA topology) that
> should ideally be retained, or may corrupt the tree by discarding nodes
> referenced by phandles.
>
> Patches #1 and #2 introduce an arm64 specific version of
> early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> memory nodes if booting via UEFI.
>
> Patch #3 moves some UEFI+FDT init code around before making changes to it.
>
> Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> know at that point whether we are booting via UEFI or not.
>
> Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> that they don't have to be removed by the stub anymore.
>
> Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> node.
>
> Changes since v3:
> - prorted to v4.5-rc1
>
> Changes since v2:
> - instead of copying the generic implementation, turn
> early_init_dt_add_memory_arch() into a weak alias so that it is still
> accessible to overrides
>
> Changes since v1:
> - dropped first two patches, they have been merged into v4.2-rc1
> - dropped last patch regarding FDT placement by the stub, this is not entirely
> relevant to the primary issue targeted by this series
> - rebased onto for-next/core (arm64) as of today
>
> Ard Biesheuvel (6):
> of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> arm64: override generic version of early_init_dt_add_memory_arch()
> efi: move FDT handling to separate object file
> arm64/efi: move EFI /chosen node parsing before early FDT processing
> arm64/efi: ignore DT memory nodes instead of removing them
> arm64/efi: ignore DT memreserve entries instead of removing them
>
> arch/arm64/include/asm/efi.h | 2 +
> arch/arm64/kernel/setup.c | 3 ++
> arch/arm64/mm/init.c | 12 +++++-
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> drivers/firmware/efi/efi.c | 84 --------------------------------------
> drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> drivers/of/fdt.c | 7 +++-
> include/linux/efi.h | 2 +-
> include/linux/of_fdt.h | 1 +
> 11 files changed, 121 insertions(+), 133 deletions(-)
> create mode 100644 drivers/firmware/efi/efi-fdt.c
>
> --
> 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-09 14:35 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-09 14:35 UTC (permalink / raw)
To: linux-arm-kernel
(+ Grant)
On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
> From: Robert Richter <rrichter@cavium.com>
>
> Reposting an updated version of this patches ported to 4.5-rc1. It is
> a followup to the version 3 from:
>
> http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>
> The series is essential for NUMA on arm64. Early FDT handling is
> required to make system topology data from firmware, esp. for cpus and
> memory available to the early boot process. Ganapat's numa patches
> depend on it. This series has been tested with his series v10 posted
> here:
>
> http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>
Hello Robert,
This series does not reflect anymore what we think is the best way to
deal with memory nodes and memreserves on UEFI systems.
Please refer to this thread:
http://thread.gmane.org/gmane.linux.kernel.efi/6464
As far as the memory nodes are concerned, if it is the best place to
store these NUMA annotations, then we should indeed preserve them, but
I think the discussion stalled without any conclusion having been
reached. As far as the /reserved-memory node is concerned, that one we
should really keep, so at least patch 6/6 of this series should be
replaced with something based on the series above.
Thanks,
Ard.
> A number of minor issues exist in the early UEFI/FDT handling path, such as:
> - when booting via UEFI, memreserve entries are removed from the device tree but
> the /reserved-memory node is not
> - memory nodes are removed from the device tree in a way that is not officially
> supported by the libfdt API (i.e., you cannot delete nodes while traversing
> the tree)
> - removal of memory nodes may discard annotations (such as NUMA topology) that
> should ideally be retained, or may corrupt the tree by discarding nodes
> referenced by phandles.
>
> Patches #1 and #2 introduce an arm64 specific version of
> early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> memory nodes if booting via UEFI.
>
> Patch #3 moves some UEFI+FDT init code around before making changes to it.
>
> Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> know at that point whether we are booting via UEFI or not.
>
> Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> that they don't have to be removed by the stub anymore.
>
> Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> node.
>
> Changes since v3:
> - prorted to v4.5-rc1
>
> Changes since v2:
> - instead of copying the generic implementation, turn
> early_init_dt_add_memory_arch() into a weak alias so that it is still
> accessible to overrides
>
> Changes since v1:
> - dropped first two patches, they have been merged into v4.2-rc1
> - dropped last patch regarding FDT placement by the stub, this is not entirely
> relevant to the primary issue targeted by this series
> - rebased onto for-next/core (arm64) as of today
>
> Ard Biesheuvel (6):
> of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> arm64: override generic version of early_init_dt_add_memory_arch()
> efi: move FDT handling to separate object file
> arm64/efi: move EFI /chosen node parsing before early FDT processing
> arm64/efi: ignore DT memory nodes instead of removing them
> arm64/efi: ignore DT memreserve entries instead of removing them
>
> arch/arm64/include/asm/efi.h | 2 +
> arch/arm64/kernel/setup.c | 3 ++
> arch/arm64/mm/init.c | 12 +++++-
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> drivers/firmware/efi/efi.c | 84 --------------------------------------
> drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> drivers/of/fdt.c | 7 +++-
> include/linux/efi.h | 2 +-
> include/linux/of_fdt.h | 1 +
> 11 files changed, 121 insertions(+), 133 deletions(-)
> create mode 100644 drivers/firmware/efi/efi-fdt.c
>
> --
> 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
2016-02-09 14:35 ` Ard Biesheuvel
(?)
@ 2016-02-11 11:42 ` Robert Richter
-1 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-11 11:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Grant Likely, Will Deacon, Matt Fleming, Catalin Marinas,
Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Rob Herring
(+RobH and MarkR)
On 09.02.16 15:35:42, Ard Biesheuvel wrote:
> (+ Grant)
>
> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
> > From: Robert Richter <rrichter@cavium.com>
> >
> > Reposting an updated version of this patches ported to 4.5-rc1. It is
> > a followup to the version 3 from:
> >
> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
> >
> > The series is essential for NUMA on arm64. Early FDT handling is
> > required to make system topology data from firmware, esp. for cpus and
> > memory available to the early boot process. Ganapat's numa patches
> > depend on it. This series has been tested with his series v10 posted
> > here:
> >
> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
> >
>
> Hello Robert,
>
> This series does not reflect anymore what we think is the best way to
> deal with memory nodes and memreserves on UEFI systems.
> Please refer to this thread:
> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>
> As far as the memory nodes are concerned, if it is the best place to
> store these NUMA annotations, then we should indeed preserve them, but
> I think the discussion stalled without any conclusion having been
> reached. As far as the /reserved-memory node is concerned, that one we
> should really keep, so at least patch 6/6 of this series should be
> replaced with something based on the series above.
Ard,
Mark R and Rob have agreed for numa dt binding for mem nodes. So do
you think we can at least reuse parts of this series to solve the NUMA
issue and try to find a solution for patch #6 which aligns with your
alternative approach?
Thanks,
-Robert
>
> Thanks,
> Ard.
>
>
> > A number of minor issues exist in the early UEFI/FDT handling path, such as:
> > - when booting via UEFI, memreserve entries are removed from the device tree but
> > the /reserved-memory node is not
> > - memory nodes are removed from the device tree in a way that is not officially
> > supported by the libfdt API (i.e., you cannot delete nodes while traversing
> > the tree)
> > - removal of memory nodes may discard annotations (such as NUMA topology) that
> > should ideally be retained, or may corrupt the tree by discarding nodes
> > referenced by phandles.
> >
> > Patches #1 and #2 introduce an arm64 specific version of
> > early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> > memory nodes if booting via UEFI.
> >
> > Patch #3 moves some UEFI+FDT init code around before making changes to it.
> >
> > Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> > know at that point whether we are booting via UEFI or not.
> >
> > Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> > that they don't have to be removed by the stub anymore.
> >
> > Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> > node.
> >
> > Changes since v3:
> > - prorted to v4.5-rc1
> >
> > Changes since v2:
> > - instead of copying the generic implementation, turn
> > early_init_dt_add_memory_arch() into a weak alias so that it is still
> > accessible to overrides
> >
> > Changes since v1:
> > - dropped first two patches, they have been merged into v4.2-rc1
> > - dropped last patch regarding FDT placement by the stub, this is not entirely
> > relevant to the primary issue targeted by this series
> > - rebased onto for-next/core (arm64) as of today
> >
> > Ard Biesheuvel (6):
> > of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> > arm64: override generic version of early_init_dt_add_memory_arch()
> > efi: move FDT handling to separate object file
> > arm64/efi: move EFI /chosen node parsing before early FDT processing
> > arm64/efi: ignore DT memory nodes instead of removing them
> > arm64/efi: ignore DT memreserve entries instead of removing them
> >
> > arch/arm64/include/asm/efi.h | 2 +
> > arch/arm64/kernel/setup.c | 3 ++
> > arch/arm64/mm/init.c | 12 +++++-
> > drivers/firmware/efi/Makefile | 1 +
> > drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> > drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> > drivers/firmware/efi/efi.c | 84 --------------------------------------
> > drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> > drivers/of/fdt.c | 7 +++-
> > include/linux/efi.h | 2 +-
> > include/linux/of_fdt.h | 1 +
> > 11 files changed, 121 insertions(+), 133 deletions(-)
> > create mode 100644 drivers/firmware/efi/efi-fdt.c
> >
> > --
> > 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 11:42 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-11 11:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Grant Likely, Will Deacon, Matt Fleming, Catalin Marinas,
Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Rob Herring
(+RobH and MarkR)
On 09.02.16 15:35:42, Ard Biesheuvel wrote:
> (+ Grant)
>
> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
> > From: Robert Richter <rrichter@cavium.com>
> >
> > Reposting an updated version of this patches ported to 4.5-rc1. It is
> > a followup to the version 3 from:
> >
> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
> >
> > The series is essential for NUMA on arm64. Early FDT handling is
> > required to make system topology data from firmware, esp. for cpus and
> > memory available to the early boot process. Ganapat's numa patches
> > depend on it. This series has been tested with his series v10 posted
> > here:
> >
> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
> >
>
> Hello Robert,
>
> This series does not reflect anymore what we think is the best way to
> deal with memory nodes and memreserves on UEFI systems.
> Please refer to this thread:
> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>
> As far as the memory nodes are concerned, if it is the best place to
> store these NUMA annotations, then we should indeed preserve them, but
> I think the discussion stalled without any conclusion having been
> reached. As far as the /reserved-memory node is concerned, that one we
> should really keep, so at least patch 6/6 of this series should be
> replaced with something based on the series above.
Ard,
Mark R and Rob have agreed for numa dt binding for mem nodes. So do
you think we can at least reuse parts of this series to solve the NUMA
issue and try to find a solution for patch #6 which aligns with your
alternative approach?
Thanks,
-Robert
>
> Thanks,
> Ard.
>
>
> > A number of minor issues exist in the early UEFI/FDT handling path, such as:
> > - when booting via UEFI, memreserve entries are removed from the device tree but
> > the /reserved-memory node is not
> > - memory nodes are removed from the device tree in a way that is not officially
> > supported by the libfdt API (i.e., you cannot delete nodes while traversing
> > the tree)
> > - removal of memory nodes may discard annotations (such as NUMA topology) that
> > should ideally be retained, or may corrupt the tree by discarding nodes
> > referenced by phandles.
> >
> > Patches #1 and #2 introduce an arm64 specific version of
> > early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> > memory nodes if booting via UEFI.
> >
> > Patch #3 moves some UEFI+FDT init code around before making changes to it.
> >
> > Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> > know at that point whether we are booting via UEFI or not.
> >
> > Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> > that they don't have to be removed by the stub anymore.
> >
> > Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> > node.
> >
> > Changes since v3:
> > - prorted to v4.5-rc1
> >
> > Changes since v2:
> > - instead of copying the generic implementation, turn
> > early_init_dt_add_memory_arch() into a weak alias so that it is still
> > accessible to overrides
> >
> > Changes since v1:
> > - dropped first two patches, they have been merged into v4.2-rc1
> > - dropped last patch regarding FDT placement by the stub, this is not entirely
> > relevant to the primary issue targeted by this series
> > - rebased onto for-next/core (arm64) as of today
> >
> > Ard Biesheuvel (6):
> > of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> > arm64: override generic version of early_init_dt_add_memory_arch()
> > efi: move FDT handling to separate object file
> > arm64/efi: move EFI /chosen node parsing before early FDT processing
> > arm64/efi: ignore DT memory nodes instead of removing them
> > arm64/efi: ignore DT memreserve entries instead of removing them
> >
> > arch/arm64/include/asm/efi.h | 2 +
> > arch/arm64/kernel/setup.c | 3 ++
> > arch/arm64/mm/init.c | 12 +++++-
> > drivers/firmware/efi/Makefile | 1 +
> > drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> > drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> > drivers/firmware/efi/efi.c | 84 --------------------------------------
> > drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> > drivers/of/fdt.c | 7 +++-
> > include/linux/efi.h | 2 +-
> > include/linux/of_fdt.h | 1 +
> > 11 files changed, 121 insertions(+), 133 deletions(-)
> > create mode 100644 drivers/firmware/efi/efi-fdt.c
> >
> > --
> > 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 11:42 ` Robert Richter
0 siblings, 0 replies; 36+ messages in thread
From: Robert Richter @ 2016-02-11 11:42 UTC (permalink / raw)
To: linux-arm-kernel
(+RobH and MarkR)
On 09.02.16 15:35:42, Ard Biesheuvel wrote:
> (+ Grant)
>
> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
> > From: Robert Richter <rrichter@cavium.com>
> >
> > Reposting an updated version of this patches ported to 4.5-rc1. It is
> > a followup to the version 3 from:
> >
> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
> >
> > The series is essential for NUMA on arm64. Early FDT handling is
> > required to make system topology data from firmware, esp. for cpus and
> > memory available to the early boot process. Ganapat's numa patches
> > depend on it. This series has been tested with his series v10 posted
> > here:
> >
> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
> >
>
> Hello Robert,
>
> This series does not reflect anymore what we think is the best way to
> deal with memory nodes and memreserves on UEFI systems.
> Please refer to this thread:
> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>
> As far as the memory nodes are concerned, if it is the best place to
> store these NUMA annotations, then we should indeed preserve them, but
> I think the discussion stalled without any conclusion having been
> reached. As far as the /reserved-memory node is concerned, that one we
> should really keep, so at least patch 6/6 of this series should be
> replaced with something based on the series above.
Ard,
Mark R and Rob have agreed for numa dt binding for mem nodes. So do
you think we can at least reuse parts of this series to solve the NUMA
issue and try to find a solution for patch #6 which aligns with your
alternative approach?
Thanks,
-Robert
>
> Thanks,
> Ard.
>
>
> > A number of minor issues exist in the early UEFI/FDT handling path, such as:
> > - when booting via UEFI, memreserve entries are removed from the device tree but
> > the /reserved-memory node is not
> > - memory nodes are removed from the device tree in a way that is not officially
> > supported by the libfdt API (i.e., you cannot delete nodes while traversing
> > the tree)
> > - removal of memory nodes may discard annotations (such as NUMA topology) that
> > should ideally be retained, or may corrupt the tree by discarding nodes
> > referenced by phandles.
> >
> > Patches #1 and #2 introduce an arm64 specific version of
> > early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> > memory nodes if booting via UEFI.
> >
> > Patch #3 moves some UEFI+FDT init code around before making changes to it.
> >
> > Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> > know at that point whether we are booting via UEFI or not.
> >
> > Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> > that they don't have to be removed by the stub anymore.
> >
> > Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> > node.
> >
> > Changes since v3:
> > - prorted to v4.5-rc1
> >
> > Changes since v2:
> > - instead of copying the generic implementation, turn
> > early_init_dt_add_memory_arch() into a weak alias so that it is still
> > accessible to overrides
> >
> > Changes since v1:
> > - dropped first two patches, they have been merged into v4.2-rc1
> > - dropped last patch regarding FDT placement by the stub, this is not entirely
> > relevant to the primary issue targeted by this series
> > - rebased onto for-next/core (arm64) as of today
> >
> > Ard Biesheuvel (6):
> > of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> > arm64: override generic version of early_init_dt_add_memory_arch()
> > efi: move FDT handling to separate object file
> > arm64/efi: move EFI /chosen node parsing before early FDT processing
> > arm64/efi: ignore DT memory nodes instead of removing them
> > arm64/efi: ignore DT memreserve entries instead of removing them
> >
> > arch/arm64/include/asm/efi.h | 2 +
> > arch/arm64/kernel/setup.c | 3 ++
> > arch/arm64/mm/init.c | 12 +++++-
> > drivers/firmware/efi/Makefile | 1 +
> > drivers/firmware/efi/arm-init.c | 36 ++++++++++------
> > drivers/firmware/efi/efi-fdt.c | 73 +++++++++++++++++++++++++++++++++
> > drivers/firmware/efi/efi.c | 84 --------------------------------------
> > drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> > drivers/of/fdt.c | 7 +++-
> > include/linux/efi.h | 2 +-
> > include/linux/of_fdt.h | 1 +
> > 11 files changed, 121 insertions(+), 133 deletions(-)
> > create mode 100644 drivers/firmware/efi/efi-fdt.c
> >
> > --
> > 2.7.0.rc3
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
2016-02-11 11:42 ` Robert Richter
(?)
@ 2016-02-11 12:14 ` Ard Biesheuvel
-1 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-11 12:14 UTC (permalink / raw)
To: Robert Richter
Cc: Grant Likely, Will Deacon, Matt Fleming, Catalin Marinas,
Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Rob Herring
On 11 February 2016 at 12:42, Robert Richter
<robert.richter@caviumnetworks.com> wrote:
> (+RobH and MarkR)
>
> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>> (+ Grant)
>>
>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>> > From: Robert Richter <rrichter@cavium.com>
>> >
>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>> > a followup to the version 3 from:
>> >
>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>> >
>> > The series is essential for NUMA on arm64. Early FDT handling is
>> > required to make system topology data from firmware, esp. for cpus and
>> > memory available to the early boot process. Ganapat's numa patches
>> > depend on it. This series has been tested with his series v10 posted
>> > here:
>> >
>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>> >
>>
>> Hello Robert,
>>
>> This series does not reflect anymore what we think is the best way to
>> deal with memory nodes and memreserves on UEFI systems.
>> Please refer to this thread:
>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>
>> As far as the memory nodes are concerned, if it is the best place to
>> store these NUMA annotations, then we should indeed preserve them, but
>> I think the discussion stalled without any conclusion having been
>> reached. As far as the /reserved-memory node is concerned, that one we
>> should really keep, so at least patch 6/6 of this series should be
>> replaced with something based on the series above.
>
> Ard,
>
> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
> you think we can at least reuse parts of this series to solve the NUMA
> issue and try to find a solution for patch #6 which aligns with your
> alternative approach?
>
OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.
However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.
I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.
--
Ard.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 12:14 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-11 12:14 UTC (permalink / raw)
To: Robert Richter
Cc: Grant Likely, Will Deacon, Matt Fleming, Catalin Marinas,
Leif Lindholm, Mark Rutland, Mark Salter, Ganapatrao Kulkarni,
linux-efi, linux-arm-kernel, linux-kernel, Rob Herring
On 11 February 2016 at 12:42, Robert Richter
<robert.richter@caviumnetworks.com> wrote:
> (+RobH and MarkR)
>
> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>> (+ Grant)
>>
>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>> > From: Robert Richter <rrichter@cavium.com>
>> >
>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>> > a followup to the version 3 from:
>> >
>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>> >
>> > The series is essential for NUMA on arm64. Early FDT handling is
>> > required to make system topology data from firmware, esp. for cpus and
>> > memory available to the early boot process. Ganapat's numa patches
>> > depend on it. This series has been tested with his series v10 posted
>> > here:
>> >
>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>> >
>>
>> Hello Robert,
>>
>> This series does not reflect anymore what we think is the best way to
>> deal with memory nodes and memreserves on UEFI systems.
>> Please refer to this thread:
>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>
>> As far as the memory nodes are concerned, if it is the best place to
>> store these NUMA annotations, then we should indeed preserve them, but
>> I think the discussion stalled without any conclusion having been
>> reached. As far as the /reserved-memory node is concerned, that one we
>> should really keep, so at least patch 6/6 of this series should be
>> replaced with something based on the series above.
>
> Ard,
>
> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
> you think we can at least reuse parts of this series to solve the NUMA
> issue and try to find a solution for patch #6 which aligns with your
> alternative approach?
>
OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.
However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.
I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.
--
Ard.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 12:14 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2016-02-11 12:14 UTC (permalink / raw)
To: linux-arm-kernel
On 11 February 2016 at 12:42, Robert Richter
<robert.richter@caviumnetworks.com> wrote:
> (+RobH and MarkR)
>
> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>> (+ Grant)
>>
>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>> > From: Robert Richter <rrichter@cavium.com>
>> >
>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>> > a followup to the version 3 from:
>> >
>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>> >
>> > The series is essential for NUMA on arm64. Early FDT handling is
>> > required to make system topology data from firmware, esp. for cpus and
>> > memory available to the early boot process. Ganapat's numa patches
>> > depend on it. This series has been tested with his series v10 posted
>> > here:
>> >
>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>> >
>>
>> Hello Robert,
>>
>> This series does not reflect anymore what we think is the best way to
>> deal with memory nodes and memreserves on UEFI systems.
>> Please refer to this thread:
>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>
>> As far as the memory nodes are concerned, if it is the best place to
>> store these NUMA annotations, then we should indeed preserve them, but
>> I think the discussion stalled without any conclusion having been
>> reached. As far as the /reserved-memory node is concerned, that one we
>> should really keep, so at least patch 6/6 of this series should be
>> replaced with something based on the series above.
>
> Ard,
>
> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
> you think we can at least reuse parts of this series to solve the NUMA
> issue and try to find a solution for patch #6 which aligns with your
> alternative approach?
>
OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.
However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.
I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.
--
Ard.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 13:03 ` Ganapatrao Kulkarni
0 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 13:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Robert Richter, Mark Rutland, linux-efi, Matt Fleming,
Catalin Marinas, Will Deacon, linux-kernel, Leif Lindholm,
Mark Salter, Grant Likely, Ganapatrao Kulkarni, linux-arm-kernel,
David Daney
Hi Ard,
On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 11 February 2016 at 12:42, Robert Richter
> <robert.richter@caviumnetworks.com> wrote:
>> (+RobH and MarkR)
>>
>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>> (+ Grant)
>>>
>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>>> > From: Robert Richter <rrichter@cavium.com>
>>> >
>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>> > a followup to the version 3 from:
>>> >
>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>>> >
>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>> > required to make system topology data from firmware, esp. for cpus and
>>> > memory available to the early boot process. Ganapat's numa patches
>>> > depend on it. This series has been tested with his series v10 posted
>>> > here:
>>> >
>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>>> >
>>>
>>> Hello Robert,
>>>
>>> This series does not reflect anymore what we think is the best way to
>>> deal with memory nodes and memreserves on UEFI systems.
>>> Please refer to this thread:
>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>
>>> As far as the memory nodes are concerned, if it is the best place to
>>> store these NUMA annotations, then we should indeed preserve them, but
>>> I think the discussion stalled without any conclusion having been
>>> reached. As far as the /reserved-memory node is concerned, that one we
>>> should really keep, so at least patch 6/6 of this series should be
>>> replaced with something based on the series above.
>>
>> Ard,
>>
>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>> you think we can at least reuse parts of this series to solve the NUMA
>> issue and try to find a solution for patch #6 which aligns with your
>> alternative approach?
>>
>
> OK, if we are all in agreement that NUMA annotations belong in memory
> nodes, which are otherwise ignored completely on UEFI systems, I am
> fine with this as well.
>
> However, we have to think about what it means if the memory nodes are
> out of sync with the UEFI memory map, both on NUMA and ordinary
> systems. I know very little about NUMA, but I could imagine that on
> any UEFI system, the UEFI memory map remains authoritative, and memory
> nodes are only used to annotate regions that are already known to
> exist. Alternatively, some sanity check could be appropriate (such as
> the one I proposed for the /reserved-memory node in the link above),
> but we need to consider carefully how the firmware is supposed to
> produce memory nodes and a UEFI memory map that are mutually
> consistent.
Yes memory nodes are updated at runtime from the firmware/uefi with
actual size and
is aligned to efi memory table.
in NUMA patches it is taken care to fail, if memory table and memory
nodes(also ACPI SRAT table) are not aligned.
On thunderx, in uefi, we do update memory nodes based on actual
memory present on each
nodes, which is not fixed on every board and varies based on number of
DIMMs etc present on board.
Same is done for ACPI SRAT table which is updated at runtime from uefi
with actual memory size of each node.
it is reasonable expectation from firmware to create/update dt or acpi
tables at runtime for a server platform.
for non-NUMA systems, dummy single node(node 0) numa system is created
using all available memory on system.
if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>
> I think we can replace 6/6 with the series above, i.e., honour the
> allocations after establishing that the fixed allocations are either
> still available, or entirely disjoint from what the UEFI memory map
> describes.
>
> --
> Ard.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
thanks
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 13:03 ` Ganapatrao Kulkarni
0 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 13:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Robert Richter, Mark Rutland, linux-efi-u79uwXL29TY76Z2rM5mHXA,
Matt Fleming, Catalin Marinas, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leif Lindholm, Mark Salter,
Grant Likely, Ganapatrao Kulkarni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Daney
Hi Ard,
On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 11 February 2016 at 12:42, Robert Richter
> <robert.richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
>> (+RobH and MarkR)
>>
>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>> (+ Grant)
>>>
>>> On 9 February 2016 at 14:53, Robert Richter <rrichter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
>>> > From: Robert Richter <rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> >
>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>> > a followup to the version 3 from:
>>> >
>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
>>> >
>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>> > required to make system topology data from firmware, esp. for cpus and
>>> > memory available to the early boot process. Ganapat's numa patches
>>> > depend on it. This series has been tested with his series v10 posted
>>> > here:
>>> >
>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
>>> >
>>>
>>> Hello Robert,
>>>
>>> This series does not reflect anymore what we think is the best way to
>>> deal with memory nodes and memreserves on UEFI systems.
>>> Please refer to this thread:
>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>
>>> As far as the memory nodes are concerned, if it is the best place to
>>> store these NUMA annotations, then we should indeed preserve them, but
>>> I think the discussion stalled without any conclusion having been
>>> reached. As far as the /reserved-memory node is concerned, that one we
>>> should really keep, so at least patch 6/6 of this series should be
>>> replaced with something based on the series above.
>>
>> Ard,
>>
>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>> you think we can at least reuse parts of this series to solve the NUMA
>> issue and try to find a solution for patch #6 which aligns with your
>> alternative approach?
>>
>
> OK, if we are all in agreement that NUMA annotations belong in memory
> nodes, which are otherwise ignored completely on UEFI systems, I am
> fine with this as well.
>
> However, we have to think about what it means if the memory nodes are
> out of sync with the UEFI memory map, both on NUMA and ordinary
> systems. I know very little about NUMA, but I could imagine that on
> any UEFI system, the UEFI memory map remains authoritative, and memory
> nodes are only used to annotate regions that are already known to
> exist. Alternatively, some sanity check could be appropriate (such as
> the one I proposed for the /reserved-memory node in the link above),
> but we need to consider carefully how the firmware is supposed to
> produce memory nodes and a UEFI memory map that are mutually
> consistent.
Yes memory nodes are updated at runtime from the firmware/uefi with
actual size and
is aligned to efi memory table.
in NUMA patches it is taken care to fail, if memory table and memory
nodes(also ACPI SRAT table) are not aligned.
On thunderx, in uefi, we do update memory nodes based on actual
memory present on each
nodes, which is not fixed on every board and varies based on number of
DIMMs etc present on board.
Same is done for ACPI SRAT table which is updated at runtime from uefi
with actual memory size of each node.
it is reasonable expectation from firmware to create/update dt or acpi
tables at runtime for a server platform.
for non-NUMA systems, dummy single node(node 0) numa system is created
using all available memory on system.
if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>
> I think we can replace 6/6 with the series above, i.e., honour the
> allocations after establishing that the fixed allocations are either
> still available, or entirely disjoint from what the UEFI memory map
> describes.
>
> --
> Ard.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
thanks
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 13:03 ` Ganapatrao Kulkarni
0 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 13:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ard,
On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 11 February 2016 at 12:42, Robert Richter
> <robert.richter@caviumnetworks.com> wrote:
>> (+RobH and MarkR)
>>
>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>> (+ Grant)
>>>
>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>>> > From: Robert Richter <rrichter@cavium.com>
>>> >
>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>> > a followup to the version 3 from:
>>> >
>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>>> >
>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>> > required to make system topology data from firmware, esp. for cpus and
>>> > memory available to the early boot process. Ganapat's numa patches
>>> > depend on it. This series has been tested with his series v10 posted
>>> > here:
>>> >
>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>>> >
>>>
>>> Hello Robert,
>>>
>>> This series does not reflect anymore what we think is the best way to
>>> deal with memory nodes and memreserves on UEFI systems.
>>> Please refer to this thread:
>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>
>>> As far as the memory nodes are concerned, if it is the best place to
>>> store these NUMA annotations, then we should indeed preserve them, but
>>> I think the discussion stalled without any conclusion having been
>>> reached. As far as the /reserved-memory node is concerned, that one we
>>> should really keep, so at least patch 6/6 of this series should be
>>> replaced with something based on the series above.
>>
>> Ard,
>>
>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>> you think we can at least reuse parts of this series to solve the NUMA
>> issue and try to find a solution for patch #6 which aligns with your
>> alternative approach?
>>
>
> OK, if we are all in agreement that NUMA annotations belong in memory
> nodes, which are otherwise ignored completely on UEFI systems, I am
> fine with this as well.
>
> However, we have to think about what it means if the memory nodes are
> out of sync with the UEFI memory map, both on NUMA and ordinary
> systems. I know very little about NUMA, but I could imagine that on
> any UEFI system, the UEFI memory map remains authoritative, and memory
> nodes are only used to annotate regions that are already known to
> exist. Alternatively, some sanity check could be appropriate (such as
> the one I proposed for the /reserved-memory node in the link above),
> but we need to consider carefully how the firmware is supposed to
> produce memory nodes and a UEFI memory map that are mutually
> consistent.
Yes memory nodes are updated at runtime from the firmware/uefi with
actual size and
is aligned to efi memory table.
in NUMA patches it is taken care to fail, if memory table and memory
nodes(also ACPI SRAT table) are not aligned.
On thunderx, in uefi, we do update memory nodes based on actual
memory present on each
nodes, which is not fixed on every board and varies based on number of
DIMMs etc present on board.
Same is done for ACPI SRAT table which is updated at runtime from uefi
with actual memory size of each node.
it is reasonable expectation from firmware to create/update dt or acpi
tables at runtime for a server platform.
for non-NUMA systems, dummy single node(node 0) numa system is created
using all available memory on system.
if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>
> I think we can replace 6/6 with the series above, i.e., honour the
> allocations after establishing that the fixed allocations are either
> still available, or entirely disjoint from what the UEFI memory map
> describes.
>
> --
> Ard.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
thanks
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
2016-02-11 13:03 ` Ganapatrao Kulkarni
(?)
@ 2016-02-11 14:26 ` Ganapatrao Kulkarni
-1 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 14:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Robert Richter, Mark Rutland, linux-efi, Matt Fleming,
Catalin Marinas, Will Deacon, linux-kernel, Leif Lindholm,
Mark Salter, Grant Likely, Ganapatrao Kulkarni, linux-arm-kernel,
David Daney, Rob Herring
adding RobH
(sorry, accidentally dropped Rob id in previous email)
On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
<gpkulkarni@gmail.com> wrote:
> Hi Ard,
>
> On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 11 February 2016 at 12:42, Robert Richter
>> <robert.richter@caviumnetworks.com> wrote:
>>> (+RobH and MarkR)
>>>
>>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>>> (+ Grant)
>>>>
>>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>>>> > From: Robert Richter <rrichter@cavium.com>
>>>> >
>>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>>> > a followup to the version 3 from:
>>>> >
>>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>>>> >
>>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>>> > required to make system topology data from firmware, esp. for cpus and
>>>> > memory available to the early boot process. Ganapat's numa patches
>>>> > depend on it. This series has been tested with his series v10 posted
>>>> > here:
>>>> >
>>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>>>> >
>>>>
>>>> Hello Robert,
>>>>
>>>> This series does not reflect anymore what we think is the best way to
>>>> deal with memory nodes and memreserves on UEFI systems.
>>>> Please refer to this thread:
>>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>>
>>>> As far as the memory nodes are concerned, if it is the best place to
>>>> store these NUMA annotations, then we should indeed preserve them, but
>>>> I think the discussion stalled without any conclusion having been
>>>> reached. As far as the /reserved-memory node is concerned, that one we
>>>> should really keep, so at least patch 6/6 of this series should be
>>>> replaced with something based on the series above.
>>>
>>> Ard,
>>>
>>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>>> you think we can at least reuse parts of this series to solve the NUMA
>>> issue and try to find a solution for patch #6 which aligns with your
>>> alternative approach?
>>>
>>
>> OK, if we are all in agreement that NUMA annotations belong in memory
>> nodes, which are otherwise ignored completely on UEFI systems, I am
>> fine with this as well.
>>
>> However, we have to think about what it means if the memory nodes are
>> out of sync with the UEFI memory map, both on NUMA and ordinary
>> systems. I know very little about NUMA, but I could imagine that on
>> any UEFI system, the UEFI memory map remains authoritative, and memory
>> nodes are only used to annotate regions that are already known to
>> exist. Alternatively, some sanity check could be appropriate (such as
>> the one I proposed for the /reserved-memory node in the link above),
>> but we need to consider carefully how the firmware is supposed to
>> produce memory nodes and a UEFI memory map that are mutually
>> consistent.
>
> Yes memory nodes are updated at runtime from the firmware/uefi with
> actual size and
> is aligned to efi memory table.
> in NUMA patches it is taken care to fail, if memory table and memory
> nodes(also ACPI SRAT table) are not aligned.
>
> On thunderx, in uefi, we do update memory nodes based on actual
> memory present on each
> nodes, which is not fixed on every board and varies based on number of
> DIMMs etc present on board.
>
> Same is done for ACPI SRAT table which is updated at runtime from uefi
> with actual memory size of each node.
>
> it is reasonable expectation from firmware to create/update dt or acpi
> tables at runtime for a server platform.
>
> for non-NUMA systems, dummy single node(node 0) numa system is created
> using all available memory on system.
> if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>>
>> I think we can replace 6/6 with the series above, i.e., honour the
>> allocations after establishing that the fixed allocations are either
>> still available, or entirely disjoint from what the UEFI memory map
>> describes.
>>
>> --
>> Ard.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> thanks
> Ganapat
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 14:26 ` Ganapatrao Kulkarni
0 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 14:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Robert Richter, Mark Rutland, linux-efi, Matt Fleming,
Catalin Marinas, Will Deacon, linux-kernel, Leif Lindholm,
Mark Salter, Grant Likely, Ganapatrao Kulkarni, linux-arm-kernel,
David Daney, Rob Herring
adding RobH
(sorry, accidentally dropped Rob id in previous email)
On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
<gpkulkarni@gmail.com> wrote:
> Hi Ard,
>
> On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 11 February 2016 at 12:42, Robert Richter
>> <robert.richter@caviumnetworks.com> wrote:
>>> (+RobH and MarkR)
>>>
>>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>>> (+ Grant)
>>>>
>>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>>>> > From: Robert Richter <rrichter@cavium.com>
>>>> >
>>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>>> > a followup to the version 3 from:
>>>> >
>>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel@linaro.org
>>>> >
>>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>>> > required to make system topology data from firmware, esp. for cpus and
>>>> > memory available to the early boot process. Ganapat's numa patches
>>>> > depend on it. This series has been tested with his series v10 posted
>>>> > here:
>>>> >
>>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com
>>>> >
>>>>
>>>> Hello Robert,
>>>>
>>>> This series does not reflect anymore what we think is the best way to
>>>> deal with memory nodes and memreserves on UEFI systems.
>>>> Please refer to this thread:
>>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>>
>>>> As far as the memory nodes are concerned, if it is the best place to
>>>> store these NUMA annotations, then we should indeed preserve them, but
>>>> I think the discussion stalled without any conclusion having been
>>>> reached. As far as the /reserved-memory node is concerned, that one we
>>>> should really keep, so at least patch 6/6 of this series should be
>>>> replaced with something based on the series above.
>>>
>>> Ard,
>>>
>>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>>> you think we can at least reuse parts of this series to solve the NUMA
>>> issue and try to find a solution for patch #6 which aligns with your
>>> alternative approach?
>>>
>>
>> OK, if we are all in agreement that NUMA annotations belong in memory
>> nodes, which are otherwise ignored completely on UEFI systems, I am
>> fine with this as well.
>>
>> However, we have to think about what it means if the memory nodes are
>> out of sync with the UEFI memory map, both on NUMA and ordinary
>> systems. I know very little about NUMA, but I could imagine that on
>> any UEFI system, the UEFI memory map remains authoritative, and memory
>> nodes are only used to annotate regions that are already known to
>> exist. Alternatively, some sanity check could be appropriate (such as
>> the one I proposed for the /reserved-memory node in the link above),
>> but we need to consider carefully how the firmware is supposed to
>> produce memory nodes and a UEFI memory map that are mutually
>> consistent.
>
> Yes memory nodes are updated at runtime from the firmware/uefi with
> actual size and
> is aligned to efi memory table.
> in NUMA patches it is taken care to fail, if memory table and memory
> nodes(also ACPI SRAT table) are not aligned.
>
> On thunderx, in uefi, we do update memory nodes based on actual
> memory present on each
> nodes, which is not fixed on every board and varies based on number of
> DIMMs etc present on board.
>
> Same is done for ACPI SRAT table which is updated at runtime from uefi
> with actual memory size of each node.
>
> it is reasonable expectation from firmware to create/update dt or acpi
> tables at runtime for a server platform.
>
> for non-NUMA systems, dummy single node(node 0) numa system is created
> using all available memory on system.
> if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>>
>> I think we can replace 6/6 with the series above, i.e., honour the
>> allocations after establishing that the fixed allocations are either
>> still available, or entirely disjoint from what the UEFI memory map
>> describes.
>>
>> --
>> Ard.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> thanks
> Ganapat
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 0/6] arm64 UEFI early FDT handling
@ 2016-02-11 14:26 ` Ganapatrao Kulkarni
0 siblings, 0 replies; 36+ messages in thread
From: Ganapatrao Kulkarni @ 2016-02-11 14:26 UTC (permalink / raw)
To: linux-arm-kernel
adding RobH
(sorry, accidentally dropped Rob id in previous email)
On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
<gpkulkarni@gmail.com> wrote:
> Hi Ard,
>
> On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 11 February 2016 at 12:42, Robert Richter
>> <robert.richter@caviumnetworks.com> wrote:
>>> (+RobH and MarkR)
>>>
>>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>>> (+ Grant)
>>>>
>>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@caviumnetworks.com> wrote:
>>>> > From: Robert Richter <rrichter@cavium.com>
>>>> >
>>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>>> > a followup to the version 3 from:
>>>> >
>>>> > http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>>>> >
>>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>>> > required to make system topology data from firmware, esp. for cpus and
>>>> > memory available to the early boot process. Ganapat's numa patches
>>>> > depend on it. This series has been tested with his series v10 posted
>>>> > here:
>>>> >
>>>> > http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>>>> >
>>>>
>>>> Hello Robert,
>>>>
>>>> This series does not reflect anymore what we think is the best way to
>>>> deal with memory nodes and memreserves on UEFI systems.
>>>> Please refer to this thread:
>>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>>
>>>> As far as the memory nodes are concerned, if it is the best place to
>>>> store these NUMA annotations, then we should indeed preserve them, but
>>>> I think the discussion stalled without any conclusion having been
>>>> reached. As far as the /reserved-memory node is concerned, that one we
>>>> should really keep, so at least patch 6/6 of this series should be
>>>> replaced with something based on the series above.
>>>
>>> Ard,
>>>
>>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>>> you think we can at least reuse parts of this series to solve the NUMA
>>> issue and try to find a solution for patch #6 which aligns with your
>>> alternative approach?
>>>
>>
>> OK, if we are all in agreement that NUMA annotations belong in memory
>> nodes, which are otherwise ignored completely on UEFI systems, I am
>> fine with this as well.
>>
>> However, we have to think about what it means if the memory nodes are
>> out of sync with the UEFI memory map, both on NUMA and ordinary
>> systems. I know very little about NUMA, but I could imagine that on
>> any UEFI system, the UEFI memory map remains authoritative, and memory
>> nodes are only used to annotate regions that are already known to
>> exist. Alternatively, some sanity check could be appropriate (such as
>> the one I proposed for the /reserved-memory node in the link above),
>> but we need to consider carefully how the firmware is supposed to
>> produce memory nodes and a UEFI memory map that are mutually
>> consistent.
>
> Yes memory nodes are updated at runtime from the firmware/uefi with
> actual size and
> is aligned to efi memory table.
> in NUMA patches it is taken care to fail, if memory table and memory
> nodes(also ACPI SRAT table) are not aligned.
>
> On thunderx, in uefi, we do update memory nodes based on actual
> memory present on each
> nodes, which is not fixed on every board and varies based on number of
> DIMMs etc present on board.
>
> Same is done for ACPI SRAT table which is updated at runtime from uefi
> with actual memory size of each node.
>
> it is reasonable expectation from firmware to create/update dt or acpi
> tables at runtime for a server platform.
>
> for non-NUMA systems, dummy single node(node 0) numa system is created
> using all available memory on system.
> if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>>
>> I think we can replace 6/6 with the series above, i.e., honour the
>> allocations after establishing that the fixed allocations are either
>> still available, or entirely disjoint from what the UEFI memory map
>> describes.
>>
>> --
>> Ard.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> thanks
> Ganapat
Ganapat
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2016-02-11 14:26 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-09 13:53 [PATCH v4 0/6] arm64 UEFI early FDT handling Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 1/6] of/fdt: make generic early_init_dt_add_memory_arch() a weak alias Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 2/6] arm64: override generic version of early_init_dt_add_memory_arch() Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 3/6] efi: move FDT handling to separate object file Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 4/6] arm64/efi: move EFI /chosen node parsing before early FDT processing Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 5/6] arm64/efi: ignore DT memory nodes instead of removing them Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` [PATCH v4 6/6] arm64/efi: ignore DT memreserve entries " Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 13:53 ` Robert Richter
2016-02-09 14:35 ` [PATCH v4 0/6] arm64 UEFI early FDT handling Ard Biesheuvel
2016-02-09 14:35 ` Ard Biesheuvel
2016-02-09 14:35 ` Ard Biesheuvel
2016-02-11 11:42 ` Robert Richter
2016-02-11 11:42 ` Robert Richter
2016-02-11 11:42 ` Robert Richter
2016-02-11 12:14 ` Ard Biesheuvel
2016-02-11 12:14 ` Ard Biesheuvel
2016-02-11 12:14 ` Ard Biesheuvel
2016-02-11 13:03 ` Ganapatrao Kulkarni
2016-02-11 13:03 ` Ganapatrao Kulkarni
2016-02-11 13:03 ` Ganapatrao Kulkarni
2016-02-11 14:26 ` Ganapatrao Kulkarni
2016-02-11 14:26 ` Ganapatrao Kulkarni
2016-02-11 14:26 ` Ganapatrao Kulkarni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.