* [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Hi all,
This patch series adds generic support for parsing DT properties related
to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
the "/chosen" node), makes use of it on arm32, and performs a few
cleanups. It is an evolution of the combination of [1] and [2].
The series consists of 6 parts:
1. Patch 1 prepares architecture-specific code (needed for MIPS only)
to avoid duplicating elf core header reservation later.
2. Patch 2 prepares the visibility of variables used to hold
information retrieved from the DT properties.
3. Patches 3-5 add support to the FDT core for handling the
properties.
This can co-exist safely with architecture-specific handling, until
the latter has been removed.
4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
riscv.
5. Patches 7-8 convert arm64 to use the generic handling instead of
its own implementation.
6. Patch 9 adds support for kdump properties to arm32.
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
DT properties to crash dump kernel's DTB"[3], which is still valid.
Changes compared to v4[4]:
- New patch "[PATCH v5 1/9] MIPS: Avoid future duplicate elf core
header reservation",
- Drop "memblock: Add variables for usable memory limitation", as this
is now handled in FDT core code,
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
- Handle the actual elf core header reservation and memory capping in
FDT core code,
- Add Reviewed-by, Acked-by,
- Remove all architecture-specific handling on arm64,
- Drop "arm64: kdump: Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of
#ifdef", as the affected code is gone,
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c.
Changes compared to older versions:
- Make elfcorehdr_{addr,size} always visible,
- Add variables for usable memory limitation,
- Use IS_ENABLED() instead of #ifdef (incl. initrd and arm64),
- Clarify what architecture-specific code is still responsible for,
- Add generic support for parsing linux,usable-memory-range,
- Remove custom linux,usable-memory-range parsing on arm64,
- Use generic handling on ARM.
This has been tested with kexec/kdump on arm32 and arm64, and
boot-tested on riscv64 and DT-less MIPS.
Thanks!
[1] "[PATCH v3] ARM: Parse kdump DT properties"
https://lore.kernel.org/r/20210317113130.2554368-1-geert+renesas@glider.be/
[2] "[PATCH 0/3] Add generic-support for linux,elfcorehdr and fix riscv"
https://lore.kernel.org/r/cover.1623780059.git.geert+renesas@glider.be/
[3] "[PATCH] arm: kdump: Add DT properties to crash dump kernel's DTB"
https://lore.kernel.org/r/20200902154129.6358-1-geert+renesas@glider.be/
[4] "[PATCH v4 00/10] Add generic support for kdump DT properties"
https://lore.kernel.org/r/cover.1626266516.git.geert+renesas@glider.be
Geert Uytterhoeven (9):
MIPS: Avoid future duplicate elf core header reservation
crash_dump: Make elfcorehdr address/size symbols always visible
of: fdt: Add generic support for handling elf core headers property
of: fdt: Add generic support for handling usable memory range property
of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
riscv: Remove non-standard linux,elfcorehdr handling
arm64: kdump: Remove custom linux,elfcorehdr handling
arm64: kdump: Remove custom linux,usable-memory-range handling
ARM: uncompress: Parse "linux,usable-memory-range" DT property
Documentation/devicetree/bindings/chosen.txt | 12 +--
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++--
arch/arm64/mm/init.c | 88 -----------------
arch/mips/kernel/setup.c | 3 +-
arch/riscv/mm/init.c | 20 ----
drivers/of/fdt.c | 94 +++++++++++++++++--
include/linux/crash_dump.h | 3 +-
7 files changed, 139 insertions(+), 129 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Hi all,
This patch series adds generic support for parsing DT properties related
to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
the "/chosen" node), makes use of it on arm32, and performs a few
cleanups. It is an evolution of the combination of [1] and [2].
The series consists of 6 parts:
1. Patch 1 prepares architecture-specific code (needed for MIPS only)
to avoid duplicating elf core header reservation later.
2. Patch 2 prepares the visibility of variables used to hold
information retrieved from the DT properties.
3. Patches 3-5 add support to the FDT core for handling the
properties.
This can co-exist safely with architecture-specific handling, until
the latter has been removed.
4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
riscv.
5. Patches 7-8 convert arm64 to use the generic handling instead of
its own implementation.
6. Patch 9 adds support for kdump properties to arm32.
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
DT properties to crash dump kernel's DTB"[3], which is still valid.
Changes compared to v4[4]:
- New patch "[PATCH v5 1/9] MIPS: Avoid future duplicate elf core
header reservation",
- Drop "memblock: Add variables for usable memory limitation", as this
is now handled in FDT core code,
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
- Handle the actual elf core header reservation and memory capping in
FDT core code,
- Add Reviewed-by, Acked-by,
- Remove all architecture-specific handling on arm64,
- Drop "arm64: kdump: Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of
#ifdef", as the affected code is gone,
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c.
Changes compared to older versions:
- Make elfcorehdr_{addr,size} always visible,
- Add variables for usable memory limitation,
- Use IS_ENABLED() instead of #ifdef (incl. initrd and arm64),
- Clarify what architecture-specific code is still responsible for,
- Add generic support for parsing linux,usable-memory-range,
- Remove custom linux,usable-memory-range parsing on arm64,
- Use generic handling on ARM.
This has been tested with kexec/kdump on arm32 and arm64, and
boot-tested on riscv64 and DT-less MIPS.
Thanks!
[1] "[PATCH v3] ARM: Parse kdump DT properties"
https://lore.kernel.org/r/20210317113130.2554368-1-geert+renesas@glider.be/
[2] "[PATCH 0/3] Add generic-support for linux,elfcorehdr and fix riscv"
https://lore.kernel.org/r/cover.1623780059.git.geert+renesas@glider.be/
[3] "[PATCH] arm: kdump: Add DT properties to crash dump kernel's DTB"
https://lore.kernel.org/r/20200902154129.6358-1-geert+renesas@glider.be/
[4] "[PATCH v4 00/10] Add generic support for kdump DT properties"
https://lore.kernel.org/r/cover.1626266516.git.geert+renesas@glider.be
Geert Uytterhoeven (9):
MIPS: Avoid future duplicate elf core header reservation
crash_dump: Make elfcorehdr address/size symbols always visible
of: fdt: Add generic support for handling elf core headers property
of: fdt: Add generic support for handling usable memory range property
of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
riscv: Remove non-standard linux,elfcorehdr handling
arm64: kdump: Remove custom linux,elfcorehdr handling
arm64: kdump: Remove custom linux,usable-memory-range handling
ARM: uncompress: Parse "linux,usable-memory-range" DT property
Documentation/devicetree/bindings/chosen.txt | 12 +--
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++--
arch/arm64/mm/init.c | 88 -----------------
arch/mips/kernel/setup.c | 3 +-
arch/riscv/mm/init.c | 20 ----
drivers/of/fdt.c | 94 +++++++++++++++++--
include/linux/crash_dump.h | 3 +-
7 files changed, 139 insertions(+), 129 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Hi all,
This patch series adds generic support for parsing DT properties related
to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
the "/chosen" node), makes use of it on arm32, and performs a few
cleanups. It is an evolution of the combination of [1] and [2].
The series consists of 6 parts:
1. Patch 1 prepares architecture-specific code (needed for MIPS only)
to avoid duplicating elf core header reservation later.
2. Patch 2 prepares the visibility of variables used to hold
information retrieved from the DT properties.
3. Patches 3-5 add support to the FDT core for handling the
properties.
This can co-exist safely with architecture-specific handling, until
the latter has been removed.
4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
riscv.
5. Patches 7-8 convert arm64 to use the generic handling instead of
its own implementation.
6. Patch 9 adds support for kdump properties to arm32.
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
DT properties to crash dump kernel's DTB"[3], which is still valid.
Changes compared to v4[4]:
- New patch "[PATCH v5 1/9] MIPS: Avoid future duplicate elf core
header reservation",
- Drop "memblock: Add variables for usable memory limitation", as this
is now handled in FDT core code,
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
- Handle the actual elf core header reservation and memory capping in
FDT core code,
- Add Reviewed-by, Acked-by,
- Remove all architecture-specific handling on arm64,
- Drop "arm64: kdump: Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of
#ifdef", as the affected code is gone,
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c.
Changes compared to older versions:
- Make elfcorehdr_{addr,size} always visible,
- Add variables for usable memory limitation,
- Use IS_ENABLED() instead of #ifdef (incl. initrd and arm64),
- Clarify what architecture-specific code is still responsible for,
- Add generic support for parsing linux,usable-memory-range,
- Remove custom linux,usable-memory-range parsing on arm64,
- Use generic handling on ARM.
This has been tested with kexec/kdump on arm32 and arm64, and
boot-tested on riscv64 and DT-less MIPS.
Thanks!
[1] "[PATCH v3] ARM: Parse kdump DT properties"
https://lore.kernel.org/r/20210317113130.2554368-1-geert+renesas@glider.be/
[2] "[PATCH 0/3] Add generic-support for linux,elfcorehdr and fix riscv"
https://lore.kernel.org/r/cover.1623780059.git.geert+renesas@glider.be/
[3] "[PATCH] arm: kdump: Add DT properties to crash dump kernel's DTB"
https://lore.kernel.org/r/20200902154129.6358-1-geert+renesas@glider.be/
[4] "[PATCH v4 00/10] Add generic support for kdump DT properties"
https://lore.kernel.org/r/cover.1626266516.git.geert+renesas@glider.be
Geert Uytterhoeven (9):
MIPS: Avoid future duplicate elf core header reservation
crash_dump: Make elfcorehdr address/size symbols always visible
of: fdt: Add generic support for handling elf core headers property
of: fdt: Add generic support for handling usable memory range property
of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
riscv: Remove non-standard linux,elfcorehdr handling
arm64: kdump: Remove custom linux,elfcorehdr handling
arm64: kdump: Remove custom linux,usable-memory-range handling
ARM: uncompress: Parse "linux,usable-memory-range" DT property
Documentation/devicetree/bindings/chosen.txt | 12 +--
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++--
arch/arm64/mm/init.c | 88 -----------------
arch/mips/kernel/setup.c | 3 +-
arch/riscv/mm/init.c | 20 ----
drivers/of/fdt.c | 94 +++++++++++++++++--
include/linux/crash_dump.h | 3 +-
7 files changed, 139 insertions(+), 129 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:50 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
occupied by an elf core header described in the device tree.
As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
mips_reserve_vmcore(), the latter needs to check if the memory has
already been reserved before.
Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
systems use DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- New.
---
arch/mips/kernel/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 23a140327a0bac1b..4693add05743d78b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
(unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+ if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
#endif
}
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
occupied by an elf core header described in the device tree.
As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
mips_reserve_vmcore(), the latter needs to check if the memory has
already been reserved before.
Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
systems use DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- New.
---
arch/mips/kernel/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 23a140327a0bac1b..4693add05743d78b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
(unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+ if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
#endif
}
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
occupied by an elf core header described in the device tree.
As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
mips_reserve_vmcore(), the latter needs to check if the memory has
already been reserved before.
Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
systems use DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- New.
---
arch/mips/kernel/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 23a140327a0bac1b..4693add05743d78b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
(unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+ if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
#endif
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 8:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:50 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
occupied by an elf core header described in the device tree.
As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
mips_reserve_vmcore(), the latter needs to check if the memory has
already been reserved before.
Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
systems use DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- New.
---
arch/mips/kernel/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 23a140327a0bac1b..4693add05743d78b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
(unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+ if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
#endif
}
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-11 8:50 ` Geert Uytterhoeven
` (2 preceding siblings ...)
(?)
@ 2021-08-11 14:02 ` kernel test robot
-1 siblings, 0 replies; 95+ messages in thread
From: kernel test robot @ 2021-08-11 14:02 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]
Hi Geert,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on arm64/for-next/core arm/for-next linus/master v5.14-rc5 next-20210811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: mips-randconfig-r022-20210809 (attached as .config)
compiler: mips64-linux-gcc (GCC) 10.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/e3a0dd2c8001096543634dfedc74e52f819bd528
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
git checkout e3a0dd2c8001096543634dfedc74e52f819bd528
# save the attached .config to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/mips/kernel/setup.c: In function 'mips_reserve_vmcore':
>> arch/mips/kernel/setup.c:432:68: error: expected ')' before 'memblock_reserve'
432 | if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
| ~ ^
| )
433 | memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
| ~~~~~~~~~~~~~~~~
>> arch/mips/kernel/setup.c:435:1: error: expected expression before '}' token
435 | }
| ^
vim +432 arch/mips/kernel/setup.c
408
409 static void __init mips_reserve_vmcore(void)
410 {
411 #ifdef CONFIG_PROC_VMCORE
412 phys_addr_t start, end;
413 u64 i;
414
415 if (!elfcorehdr_size) {
416 for_each_mem_range(i, &start, &end) {
417 if (elfcorehdr_addr >= start && elfcorehdr_addr < end) {
418 /*
419 * Reserve from the elf core header to the end of
420 * the memory segment, that should all be kdump
421 * reserved memory.
422 */
423 elfcorehdr_size = end - elfcorehdr_addr;
424 break;
425 }
426 }
427 }
428
429 pr_info("Reserving %ldKB of memory@%ldKB for kdump\n",
430 (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
431
> 432 if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
433 memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
434 #endif
> 435 }
436
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 29617 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 15:35 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 15:35 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Russell King, Rob Herring, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List, Geert Uytterhoeven
On Wed, Aug 11, 2021 at 10:51 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
>
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
As pointed out by lkp, there's a closing parenthesis missing.
/me hides back under his rock.
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 15:35 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 15:35 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Russell King, Rob Herring, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List, Geert Uytterhoeven
On Wed, Aug 11, 2021 at 10:51 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
>
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
As pointed out by lkp, there's a closing parenthesis missing.
/me hides back under his rock.
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 15:35 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 15:35 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Russell King, Rob Herring, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List, Geert Uytterhoeven
On Wed, Aug 11, 2021 at 10:51 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
>
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
As pointed out by lkp, there's a closing parenthesis missing.
/me hides back under his rock.
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-11 15:35 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 15:35 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Russell King, Rob Herring, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List, Geert Uytterhoeven
On Wed, Aug 11, 2021 at 10:51 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
>
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
As pointed out by lkp, there's a closing parenthesis missing.
/me hides back under his rock.
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-16 5:52 ` Mike Rapoport
-1 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-16 5:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
Doing memblock_reserve() for the same region is usually fine, did you
encounter any issues without this patch?
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
> }
>
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-16 5:52 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-16 5:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
Doing memblock_reserve() for the same region is usually fine, did you
encounter any issues without this patch?
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
> }
>
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-16 5:52 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-16 5:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
Doing memblock_reserve() for the same region is usually fine, did you
encounter any issues without this patch?
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
> }
>
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-16 5:52 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-16 5:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> mips_reserve_vmcore(), the latter needs to check if the memory has
> already been reserved before.
Doing memblock_reserve() for the same region is usually fine, did you
encounter any issues without this patch?
> Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> systems use DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v5:
> - New.
> ---
> arch/mips/kernel/setup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 23a140327a0bac1b..4693add05743d78b 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
>
> - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> #endif
> }
>
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-16 5:52 ` Mike Rapoport
(?)
(?)
@ 2021-08-23 10:17 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:17 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Mike,
On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > occupied by an elf core header described in the device tree.
> > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > mips_reserve_vmcore(), the latter needs to check if the memory has
> > already been reserved before.
>
> Doing memblock_reserve() for the same region is usually fine, did you
> encounter any issues without this patch?
Does it also work if the same region is part of an earlier larger
reservation? I am no memblock expert, so I don't know.
I didn't run into any issues, as my MIPS platform is non-DT, but I
assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
a reason.
Thanks!
>
> > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > systems use DT.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v5:
> > - New.
> > ---
> > arch/mips/kernel/setup.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > index 23a140327a0bac1b..4693add05743d78b 100644
> > --- a/arch/mips/kernel/setup.c
> > +++ b/arch/mips/kernel/setup.c
> > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > #endif
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 10:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:17 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Mike,
On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > occupied by an elf core header described in the device tree.
> > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > mips_reserve_vmcore(), the latter needs to check if the memory has
> > already been reserved before.
>
> Doing memblock_reserve() for the same region is usually fine, did you
> encounter any issues without this patch?
Does it also work if the same region is part of an earlier larger
reservation? I am no memblock expert, so I don't know.
I didn't run into any issues, as my MIPS platform is non-DT, but I
assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
a reason.
Thanks!
>
> > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > systems use DT.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v5:
> > - New.
> > ---
> > arch/mips/kernel/setup.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > index 23a140327a0bac1b..4693add05743d78b 100644
> > --- a/arch/mips/kernel/setup.c
> > +++ b/arch/mips/kernel/setup.c
> > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > #endif
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 10:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:17 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Mike,
On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > occupied by an elf core header described in the device tree.
> > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > mips_reserve_vmcore(), the latter needs to check if the memory has
> > already been reserved before.
>
> Doing memblock_reserve() for the same region is usually fine, did you
> encounter any issues without this patch?
Does it also work if the same region is part of an earlier larger
reservation? I am no memblock expert, so I don't know.
I didn't run into any issues, as my MIPS platform is non-DT, but I
assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
a reason.
Thanks!
>
> > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > systems use DT.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v5:
> > - New.
> > ---
> > arch/mips/kernel/setup.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > index 23a140327a0bac1b..4693add05743d78b 100644
> > --- a/arch/mips/kernel/setup.c
> > +++ b/arch/mips/kernel/setup.c
> > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > #endif
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 10:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:17 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Mike,
On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > occupied by an elf core header described in the device tree.
> > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > mips_reserve_vmcore(), the latter needs to check if the memory has
> > already been reserved before.
>
> Doing memblock_reserve() for the same region is usually fine, did you
> encounter any issues without this patch?
Does it also work if the same region is part of an earlier larger
reservation? I am no memblock expert, so I don't know.
I didn't run into any issues, as my MIPS platform is non-DT, but I
assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
a reason.
Thanks!
>
> > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > systems use DT.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v5:
> > - New.
> > ---
> > arch/mips/kernel/setup.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > index 23a140327a0bac1b..4693add05743d78b 100644
> > --- a/arch/mips/kernel/setup.c
> > +++ b/arch/mips/kernel/setup.c
> > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > #endif
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-23 10:17 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-23 13:09 ` Mike Rapoport
-1 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 13:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > occupied by an elf core header described in the device tree.
> > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > already been reserved before.
> >
> > Doing memblock_reserve() for the same region is usually fine, did you
> > encounter any issues without this patch?
>
> Does it also work if the same region is part of an earlier larger
> reservation? I am no memblock expert, so I don't know.
> I didn't run into any issues, as my MIPS platform is non-DT, but I
> assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> a reason.
The memory will be reserved regardless of the earlier reservation, the
issue may appear when the reservations are made for different purpose. E.g.
if there was crash kernel allocation before the reservation of elfcorehdr.
The check in such case will prevent the second reservation, but, at least
in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
different users of the overlapping regions to step on each others toes.
Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
is only a partial overlap of the elfcorehdr with the previous reservation,
the non-overlapping part of elfcorehdr won't get reserved at all.
> Thanks!
>
> >
> > > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > > systems use DT.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v5:
> > > - New.
> > > ---
> > > arch/mips/kernel/setup.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > > index 23a140327a0bac1b..4693add05743d78b 100644
> > > --- a/arch/mips/kernel/setup.c
> > > +++ b/arch/mips/kernel/setup.c
> > > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> > >
> > > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > #endif
> > > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 13:09 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 13:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > occupied by an elf core header described in the device tree.
> > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > already been reserved before.
> >
> > Doing memblock_reserve() for the same region is usually fine, did you
> > encounter any issues without this patch?
>
> Does it also work if the same region is part of an earlier larger
> reservation? I am no memblock expert, so I don't know.
> I didn't run into any issues, as my MIPS platform is non-DT, but I
> assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> a reason.
The memory will be reserved regardless of the earlier reservation, the
issue may appear when the reservations are made for different purpose. E.g.
if there was crash kernel allocation before the reservation of elfcorehdr.
The check in such case will prevent the second reservation, but, at least
in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
different users of the overlapping regions to step on each others toes.
Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
is only a partial overlap of the elfcorehdr with the previous reservation,
the non-overlapping part of elfcorehdr won't get reserved at all.
> Thanks!
>
> >
> > > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > > systems use DT.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v5:
> > > - New.
> > > ---
> > > arch/mips/kernel/setup.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > > index 23a140327a0bac1b..4693add05743d78b 100644
> > > --- a/arch/mips/kernel/setup.c
> > > +++ b/arch/mips/kernel/setup.c
> > > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> > >
> > > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > #endif
> > > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Sincerely yours,
Mike.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 13:09 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 13:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > occupied by an elf core header described in the device tree.
> > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > already been reserved before.
> >
> > Doing memblock_reserve() for the same region is usually fine, did you
> > encounter any issues without this patch?
>
> Does it also work if the same region is part of an earlier larger
> reservation? I am no memblock expert, so I don't know.
> I didn't run into any issues, as my MIPS platform is non-DT, but I
> assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> a reason.
The memory will be reserved regardless of the earlier reservation, the
issue may appear when the reservations are made for different purpose. E.g.
if there was crash kernel allocation before the reservation of elfcorehdr.
The check in such case will prevent the second reservation, but, at least
in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
different users of the overlapping regions to step on each others toes.
Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
is only a partial overlap of the elfcorehdr with the previous reservation,
the non-overlapping part of elfcorehdr won't get reserved at all.
> Thanks!
>
> >
> > > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > > systems use DT.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v5:
> > > - New.
> > > ---
> > > arch/mips/kernel/setup.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > > index 23a140327a0bac1b..4693add05743d78b 100644
> > > --- a/arch/mips/kernel/setup.c
> > > +++ b/arch/mips/kernel/setup.c
> > > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> > >
> > > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > #endif
> > > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 13:09 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 13:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > occupied by an elf core header described in the device tree.
> > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > already been reserved before.
> >
> > Doing memblock_reserve() for the same region is usually fine, did you
> > encounter any issues without this patch?
>
> Does it also work if the same region is part of an earlier larger
> reservation? I am no memblock expert, so I don't know.
> I didn't run into any issues, as my MIPS platform is non-DT, but I
> assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> a reason.
The memory will be reserved regardless of the earlier reservation, the
issue may appear when the reservations are made for different purpose. E.g.
if there was crash kernel allocation before the reservation of elfcorehdr.
The check in such case will prevent the second reservation, but, at least
in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
different users of the overlapping regions to step on each others toes.
Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
is only a partial overlap of the elfcorehdr with the previous reservation,
the non-overlapping part of elfcorehdr won't get reserved at all.
> Thanks!
>
> >
> > > Note that mips_reserve_vmcore() cannot just be removed, as not all MIPS
> > > systems use DT.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v5:
> > > - New.
> > > ---
> > > arch/mips/kernel/setup.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> > > index 23a140327a0bac1b..4693add05743d78b 100644
> > > --- a/arch/mips/kernel/setup.c
> > > +++ b/arch/mips/kernel/setup.c
> > > @@ -429,7 +429,8 @@ static void __init mips_reserve_vmcore(void)
> > > pr_info("Reserving %ldKB of memory at %ldKB for kdump\n",
> > > (unsigned long)elfcorehdr_size >> 10, (unsigned long)elfcorehdr_addr >> 10);
> > >
> > > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > + if (!memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)
> > > + memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > > #endif
> > > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-23 13:09 ` Mike Rapoport
(?)
(?)
@ 2021-08-23 14:44 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:44 UTC (permalink / raw)
To: Mike Rapoport
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > Hi Mike,
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > occupied by an elf core header described in the device tree.
> > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > already been reserved before.
> > >
> > > Doing memblock_reserve() for the same region is usually fine, did you
> > > encounter any issues without this patch?
> >
> > Does it also work if the same region is part of an earlier larger
> > reservation? I am no memblock expert, so I don't know.
> > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > a reason.
>
> The memory will be reserved regardless of the earlier reservation, the
> issue may appear when the reservations are made for different purpose. E.g.
> if there was crash kernel allocation before the reservation of elfcorehdr.
>
> The check in such case will prevent the second reservation, but, at least
> in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> different users of the overlapping regions to step on each others toes.
If the kernel has been passed in overlapping regions, is there
anything you can do other than hope to get a message out?
> Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> is only a partial overlap of the elfcorehdr with the previous reservation,
> the non-overlapping part of elfcorehdr won't get reserved at all.
What do you suggest as the arm64 version is not the common version?
Rob
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 14:44 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:44 UTC (permalink / raw)
To: Mike Rapoport
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > Hi Mike,
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > occupied by an elf core header described in the device tree.
> > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > already been reserved before.
> > >
> > > Doing memblock_reserve() for the same region is usually fine, did you
> > > encounter any issues without this patch?
> >
> > Does it also work if the same region is part of an earlier larger
> > reservation? I am no memblock expert, so I don't know.
> > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > a reason.
>
> The memory will be reserved regardless of the earlier reservation, the
> issue may appear when the reservations are made for different purpose. E.g.
> if there was crash kernel allocation before the reservation of elfcorehdr.
>
> The check in such case will prevent the second reservation, but, at least
> in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> different users of the overlapping regions to step on each others toes.
If the kernel has been passed in overlapping regions, is there
anything you can do other than hope to get a message out?
> Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> is only a partial overlap of the elfcorehdr with the previous reservation,
> the non-overlapping part of elfcorehdr won't get reserved at all.
What do you suggest as the arm64 version is not the common version?
Rob
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 14:44 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:44 UTC (permalink / raw)
To: Mike Rapoport
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > Hi Mike,
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > occupied by an elf core header described in the device tree.
> > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > already been reserved before.
> > >
> > > Doing memblock_reserve() for the same region is usually fine, did you
> > > encounter any issues without this patch?
> >
> > Does it also work if the same region is part of an earlier larger
> > reservation? I am no memblock expert, so I don't know.
> > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > a reason.
>
> The memory will be reserved regardless of the earlier reservation, the
> issue may appear when the reservations are made for different purpose. E.g.
> if there was crash kernel allocation before the reservation of elfcorehdr.
>
> The check in such case will prevent the second reservation, but, at least
> in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> different users of the overlapping regions to step on each others toes.
If the kernel has been passed in overlapping regions, is there
anything you can do other than hope to get a message out?
> Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> is only a partial overlap of the elfcorehdr with the previous reservation,
> the non-overlapping part of elfcorehdr won't get reserved at all.
What do you suggest as the arm64 version is not the common version?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 14:44 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:44 UTC (permalink / raw)
To: Mike Rapoport
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > Hi Mike,
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > occupied by an elf core header described in the device tree.
> > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > already been reserved before.
> > >
> > > Doing memblock_reserve() for the same region is usually fine, did you
> > > encounter any issues without this patch?
> >
> > Does it also work if the same region is part of an earlier larger
> > reservation? I am no memblock expert, so I don't know.
> > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > a reason.
>
> The memory will be reserved regardless of the earlier reservation, the
> issue may appear when the reservations are made for different purpose. E.g.
> if there was crash kernel allocation before the reservation of elfcorehdr.
>
> The check in such case will prevent the second reservation, but, at least
> in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> different users of the overlapping regions to step on each others toes.
If the kernel has been passed in overlapping regions, is there
anything you can do other than hope to get a message out?
> Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> is only a partial overlap of the elfcorehdr with the previous reservation,
> the non-overlapping part of elfcorehdr won't get reserved at all.
What do you suggest as the arm64 version is not the common version?
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
2021-08-23 14:44 ` Rob Herring
(?)
(?)
@ 2021-08-23 15:20 ` Mike Rapoport
-1 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 15:20 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote:
> On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mike,
> > >
> > > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > > occupied by an elf core header described in the device tree.
> > > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > > already been reserved before.
> > > >
> > > > Doing memblock_reserve() for the same region is usually fine, did you
> > > > encounter any issues without this patch?
> > >
> > > Does it also work if the same region is part of an earlier larger
> > > reservation? I am no memblock expert, so I don't know.
> > > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > > a reason.
> >
> > The memory will be reserved regardless of the earlier reservation, the
> > issue may appear when the reservations are made for different purpose. E.g.
> > if there was crash kernel allocation before the reservation of elfcorehdr.
> >
> > The check in such case will prevent the second reservation, but, at least
> > in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> > different users of the overlapping regions to step on each others toes.
>
> If the kernel has been passed in overlapping regions, is there
> anything you can do other than hope to get a message out?
Nothing really. I've been thinking about adding flags to memblock.reserved
to at least distinguish firmware regions from the kernel allocations, but I
never got to that.
> > Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> > is only a partial overlap of the elfcorehdr with the previous reservation,
> > the non-overlapping part of elfcorehdr won't get reserved at all.
>
> What do you suggest as the arm64 version is not the common version?
I'm not really familiar with crash dump internals, so I don't know if
resetting elfcorehdr_addr to ELFCORE_ADDR_ERR is a good idea. I think at
least arm64::reserve_elfcorehdr() should reserve the entire elfcorehdr area
regardless of the overlap. Otherwise it might get overwritten by a random
memblock_alloc().
> Rob
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 15:20 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 15:20 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote:
> On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mike,
> > >
> > > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > > occupied by an elf core header described in the device tree.
> > > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > > already been reserved before.
> > > >
> > > > Doing memblock_reserve() for the same region is usually fine, did you
> > > > encounter any issues without this patch?
> > >
> > > Does it also work if the same region is part of an earlier larger
> > > reservation? I am no memblock expert, so I don't know.
> > > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > > a reason.
> >
> > The memory will be reserved regardless of the earlier reservation, the
> > issue may appear when the reservations are made for different purpose. E.g.
> > if there was crash kernel allocation before the reservation of elfcorehdr.
> >
> > The check in such case will prevent the second reservation, but, at least
> > in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> > different users of the overlapping regions to step on each others toes.
>
> If the kernel has been passed in overlapping regions, is there
> anything you can do other than hope to get a message out?
Nothing really. I've been thinking about adding flags to memblock.reserved
to at least distinguish firmware regions from the kernel allocations, but I
never got to that.
> > Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> > is only a partial overlap of the elfcorehdr with the previous reservation,
> > the non-overlapping part of elfcorehdr won't get reserved at all.
>
> What do you suggest as the arm64 version is not the common version?
I'm not really familiar with crash dump internals, so I don't know if
resetting elfcorehdr_addr to ELFCORE_ADDR_ERR is a good idea. I think at
least arm64::reserve_elfcorehdr() should reserve the entire elfcorehdr area
regardless of the overlap. Otherwise it might get overwritten by a random
memblock_alloc().
> Rob
--
Sincerely yours,
Mike.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 15:20 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 15:20 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote:
> On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mike,
> > >
> > > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > > occupied by an elf core header described in the device tree.
> > > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > > already been reserved before.
> > > >
> > > > Doing memblock_reserve() for the same region is usually fine, did you
> > > > encounter any issues without this patch?
> > >
> > > Does it also work if the same region is part of an earlier larger
> > > reservation? I am no memblock expert, so I don't know.
> > > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > > a reason.
> >
> > The memory will be reserved regardless of the earlier reservation, the
> > issue may appear when the reservations are made for different purpose. E.g.
> > if there was crash kernel allocation before the reservation of elfcorehdr.
> >
> > The check in such case will prevent the second reservation, but, at least
> > in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> > different users of the overlapping regions to step on each others toes.
>
> If the kernel has been passed in overlapping regions, is there
> anything you can do other than hope to get a message out?
Nothing really. I've been thinking about adding flags to memblock.reserved
to at least distinguish firmware regions from the kernel allocations, but I
never got to that.
> > Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> > is only a partial overlap of the elfcorehdr with the previous reservation,
> > the non-overlapping part of elfcorehdr won't get reserved at all.
>
> What do you suggest as the arm64 version is not the common version?
I'm not really familiar with crash dump internals, so I don't know if
resetting elfcorehdr_addr to ELFCORE_ADDR_ERR is a good idea. I think at
least arm64::reserve_elfcorehdr() should reserve the entire elfcorehdr area
regardless of the overlap. Otherwise it might get overwritten by a random
memblock_alloc().
> Rob
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation
@ 2021-08-23 15:20 ` Mike Rapoport
0 siblings, 0 replies; 95+ messages in thread
From: Mike Rapoport @ 2021-08-23 15:20 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote:
> On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mike,
> > >
> > > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> > > > > occupied by an elf core header described in the device tree.
> > > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
> > > > > mips_reserve_vmcore(), the latter needs to check if the memory has
> > > > > already been reserved before.
> > > >
> > > > Doing memblock_reserve() for the same region is usually fine, did you
> > > > encounter any issues without this patch?
> > >
> > > Does it also work if the same region is part of an earlier larger
> > > reservation? I am no memblock expert, so I don't know.
> > > I didn't run into any issues, as my MIPS platform is non-DT, but I
> > > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for
> > > a reason.
> >
> > The memory will be reserved regardless of the earlier reservation, the
> > issue may appear when the reservations are made for different purpose. E.g.
> > if there was crash kernel allocation before the reservation of elfcorehdr.
> >
> > The check in such case will prevent the second reservation, but, at least
> > in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent
> > different users of the overlapping regions to step on each others toes.
>
> If the kernel has been passed in overlapping regions, is there
> anything you can do other than hope to get a message out?
Nothing really. I've been thinking about adding flags to memblock.reserved
to at least distinguish firmware regions from the kernel allocations, but I
never got to that.
> > Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there
> > is only a partial overlap of the elfcorehdr with the previous reservation,
> > the non-overlapping part of elfcorehdr won't get reserved at all.
>
> What do you suggest as the arm64 version is not the common version?
I'm not really familiar with crash dump internals, so I don't know if
resetting elfcorehdr_addr to ELFCORE_ADDR_ERR is a good idea. I think at
least arm64::reserve_elfcorehdr() should reserve the entire elfcorehdr area
regardless of the overlap. Otherwise it might get overwritten by a random
memblock_alloc().
> Rob
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH v5 2/9] crash_dump: Make elfcorehdr address/size symbols always visible
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Make the forward declarations of elfcorehdr_addr and elfcorehdr_size,
and the definitions of ELFCORE_ADDR_MAX and ELFCORE_ADDR_ERR always
available, like is done for phys_initrd_start and phys_initrd_size.
Code referring to these symbols can then just check for
IS_ENABLED(CONFIG_CRASH_DUMP), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile
coverage.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
v4:
- New.
---
include/linux/crash_dump.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index a5192b718dbe4f9a..2618577a4d6da77e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -10,13 +10,14 @@
#include <linux/pgtable.h> /* for pgprot_t */
-#ifdef CONFIG_CRASH_DUMP
+/* For IS_ENABLED(CONFIG_CRASH_DUMP) */
#define ELFCORE_ADDR_MAX (-1ULL)
#define ELFCORE_ADDR_ERR (-2ULL)
extern unsigned long long elfcorehdr_addr;
extern unsigned long long elfcorehdr_size;
+#ifdef CONFIG_CRASH_DUMP
extern int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size);
extern void elfcorehdr_free(unsigned long long addr);
extern ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 2/9] crash_dump: Make elfcorehdr address/size symbols always visible
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Make the forward declarations of elfcorehdr_addr and elfcorehdr_size,
and the definitions of ELFCORE_ADDR_MAX and ELFCORE_ADDR_ERR always
available, like is done for phys_initrd_start and phys_initrd_size.
Code referring to these symbols can then just check for
IS_ENABLED(CONFIG_CRASH_DUMP), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile
coverage.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
v4:
- New.
---
include/linux/crash_dump.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index a5192b718dbe4f9a..2618577a4d6da77e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -10,13 +10,14 @@
#include <linux/pgtable.h> /* for pgprot_t */
-#ifdef CONFIG_CRASH_DUMP
+/* For IS_ENABLED(CONFIG_CRASH_DUMP) */
#define ELFCORE_ADDR_MAX (-1ULL)
#define ELFCORE_ADDR_ERR (-2ULL)
extern unsigned long long elfcorehdr_addr;
extern unsigned long long elfcorehdr_size;
+#ifdef CONFIG_CRASH_DUMP
extern int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size);
extern void elfcorehdr_free(unsigned long long addr);
extern ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos);
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 2/9] crash_dump: Make elfcorehdr address/size symbols always visible
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Make the forward declarations of elfcorehdr_addr and elfcorehdr_size,
and the definitions of ELFCORE_ADDR_MAX and ELFCORE_ADDR_ERR always
available, like is done for phys_initrd_start and phys_initrd_size.
Code referring to these symbols can then just check for
IS_ENABLED(CONFIG_CRASH_DUMP), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile
coverage.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
v4:
- New.
---
include/linux/crash_dump.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index a5192b718dbe4f9a..2618577a4d6da77e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -10,13 +10,14 @@
#include <linux/pgtable.h> /* for pgprot_t */
-#ifdef CONFIG_CRASH_DUMP
+/* For IS_ENABLED(CONFIG_CRASH_DUMP) */
#define ELFCORE_ADDR_MAX (-1ULL)
#define ELFCORE_ADDR_ERR (-2ULL)
extern unsigned long long elfcorehdr_addr;
extern unsigned long long elfcorehdr_size;
+#ifdef CONFIG_CRASH_DUMP
extern int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size);
extern void elfcorehdr_free(unsigned long long addr);
extern ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 2/9] crash_dump: Make elfcorehdr address/size symbols always visible
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Make the forward declarations of elfcorehdr_addr and elfcorehdr_size,
and the definitions of ELFCORE_ADDR_MAX and ELFCORE_ADDR_ERR always
available, like is done for phys_initrd_start and phys_initrd_size.
Code referring to these symbols can then just check for
IS_ENABLED(CONFIG_CRASH_DUMP), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile
coverage.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Make ELFCORE_ADDR_{MAX,ERR} visible, too,
v4:
- New.
---
include/linux/crash_dump.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index a5192b718dbe4f9a..2618577a4d6da77e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -10,13 +10,14 @@
#include <linux/pgtable.h> /* for pgprot_t */
-#ifdef CONFIG_CRASH_DUMP
+/* For IS_ENABLED(CONFIG_CRASH_DUMP) */
#define ELFCORE_ADDR_MAX (-1ULL)
#define ELFCORE_ADDR_ERR (-2ULL)
extern unsigned long long elfcorehdr_addr;
extern unsigned long long elfcorehdr_size;
+#ifdef CONFIG_CRASH_DUMP
extern int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size);
extern void elfcorehdr_free(unsigned long long addr);
extern ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos);
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
There are two methods to specify the location of the elf core headers:
using the "elfcorehdr=" kernel parameter, as handled by generic code in
kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the
"/chosen" node in the Device Tree, as handled by architecture-specific
code in arch/arm64/mm/init.c.
Extend support for "linux,elfcorehdr" to all platforms supporting DT by
adding platform-agnostic handling for handling this property to the FDT
core code. This can co-exist safely with the architecture-specific
handling, until the latter has been removed.
This requires moving the call to of_scan_flat_dt() up, as the code
scanning the "/chosen" node now needs to be aware of the values of
"#address-cells" and "#size-cells".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Notes:
1. To avoid reserving the region twice, this depends on "MIPS: Avoid
duplicate elf core header reservation",
2. IA64 also has custom code to reserve the region, but is not
affected, as IA64 does not use DT,
3. About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual reservation in generic code, too,
v4:
- Use IS_ENABLED() instead of #ifdef,
- Clarify what architecture-specific code is still responsible for.
---
Documentation/devicetree/bindings/chosen.txt | 6 +-
drivers/of/fdt.c | 59 +++++++++++++++++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646c537..5b0b94eb2d04e79d 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -106,9 +106,9 @@ respectively, of the root node.
linux,elfcorehdr
----------------
-This property (currently used only on arm64) holds the memory range,
-the address and the size, of the elf core header which mainly describes
-the panicked kernel's memory layout as PT_LOAD segments of elf format.
+This property holds the memory range, the address and the size, of the elf
+core header which mainly describes the panicked kernel's memory layout as
+PT_LOAD segments of elf format.
e.g.
/ {
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9e5074d52879649b..99be3e03af29089f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "OF: fdt: " fmt
+#include <linux/crash_dump.h>
#include <linux/crc32.h>
#include <linux/kernel.h>
#include <linux/initrd.h>
@@ -581,6 +582,30 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
return 0;
}
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves the memory occupied by an elf core header
+ * described in the device tree. This region contains all the
+ * information about primary kernel's core image and is used by a dump
+ * capture kernel to access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP) || !elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %llu KiB of memory at 0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+
/**
* early_init_fdt_scan_reserved_mem() - create reserved memory regions
*
@@ -606,6 +631,7 @@ void __init early_init_fdt_scan_reserved_mem(void)
of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
fdt_init_reserved_mem();
+ reserve_elfcorehdr();
}
/**
@@ -904,6 +930,32 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
}
#endif /* CONFIG_BLK_DEV_INITRD */
+/**
+ * early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
+ * tree
+ * @node: reference to node containing elfcorehdr location ('chosen')
+ */
+static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP))
+ return;
+
+ pr_debug("Looking for elfcorehdr property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("elfcorehdr_start=0x%llx elfcorehdr_size=0x%llx\n",
+ elfcorehdr_addr, elfcorehdr_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1051,6 +1103,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 0;
early_init_dt_check_for_initrd(node);
+ early_init_dt_check_for_elfcorehdr(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1195,14 +1248,14 @@ void __init early_init_dt_scan_nodes(void)
{
int rc = 0;
+ /* Initialize {size,address}-cells info */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+
/* Retrieve various information from the /chosen node */
rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
if (!rc)
pr_warn("No chosen node found, continuing without\n");
- /* Initialize {size,address}-cells info */
- of_scan_flat_dt(early_init_dt_scan_root, NULL);
-
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
There are two methods to specify the location of the elf core headers:
using the "elfcorehdr=" kernel parameter, as handled by generic code in
kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the
"/chosen" node in the Device Tree, as handled by architecture-specific
code in arch/arm64/mm/init.c.
Extend support for "linux,elfcorehdr" to all platforms supporting DT by
adding platform-agnostic handling for handling this property to the FDT
core code. This can co-exist safely with the architecture-specific
handling, until the latter has been removed.
This requires moving the call to of_scan_flat_dt() up, as the code
scanning the "/chosen" node now needs to be aware of the values of
"#address-cells" and "#size-cells".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Notes:
1. To avoid reserving the region twice, this depends on "MIPS: Avoid
duplicate elf core header reservation",
2. IA64 also has custom code to reserve the region, but is not
affected, as IA64 does not use DT,
3. About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual reservation in generic code, too,
v4:
- Use IS_ENABLED() instead of #ifdef,
- Clarify what architecture-specific code is still responsible for.
---
Documentation/devicetree/bindings/chosen.txt | 6 +-
drivers/of/fdt.c | 59 +++++++++++++++++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646c537..5b0b94eb2d04e79d 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -106,9 +106,9 @@ respectively, of the root node.
linux,elfcorehdr
----------------
-This property (currently used only on arm64) holds the memory range,
-the address and the size, of the elf core header which mainly describes
-the panicked kernel's memory layout as PT_LOAD segments of elf format.
+This property holds the memory range, the address and the size, of the elf
+core header which mainly describes the panicked kernel's memory layout as
+PT_LOAD segments of elf format.
e.g.
/ {
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9e5074d52879649b..99be3e03af29089f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "OF: fdt: " fmt
+#include <linux/crash_dump.h>
#include <linux/crc32.h>
#include <linux/kernel.h>
#include <linux/initrd.h>
@@ -581,6 +582,30 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
return 0;
}
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves the memory occupied by an elf core header
+ * described in the device tree. This region contains all the
+ * information about primary kernel's core image and is used by a dump
+ * capture kernel to access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP) || !elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %llu KiB of memory at 0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+
/**
* early_init_fdt_scan_reserved_mem() - create reserved memory regions
*
@@ -606,6 +631,7 @@ void __init early_init_fdt_scan_reserved_mem(void)
of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
fdt_init_reserved_mem();
+ reserve_elfcorehdr();
}
/**
@@ -904,6 +930,32 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
}
#endif /* CONFIG_BLK_DEV_INITRD */
+/**
+ * early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
+ * tree
+ * @node: reference to node containing elfcorehdr location ('chosen')
+ */
+static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP))
+ return;
+
+ pr_debug("Looking for elfcorehdr property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("elfcorehdr_start=0x%llx elfcorehdr_size=0x%llx\n",
+ elfcorehdr_addr, elfcorehdr_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1051,6 +1103,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 0;
early_init_dt_check_for_initrd(node);
+ early_init_dt_check_for_elfcorehdr(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1195,14 +1248,14 @@ void __init early_init_dt_scan_nodes(void)
{
int rc = 0;
+ /* Initialize {size,address}-cells info */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+
/* Retrieve various information from the /chosen node */
rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
if (!rc)
pr_warn("No chosen node found, continuing without\n");
- /* Initialize {size,address}-cells info */
- of_scan_flat_dt(early_init_dt_scan_root, NULL);
-
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
There are two methods to specify the location of the elf core headers:
using the "elfcorehdr=" kernel parameter, as handled by generic code in
kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the
"/chosen" node in the Device Tree, as handled by architecture-specific
code in arch/arm64/mm/init.c.
Extend support for "linux,elfcorehdr" to all platforms supporting DT by
adding platform-agnostic handling for handling this property to the FDT
core code. This can co-exist safely with the architecture-specific
handling, until the latter has been removed.
This requires moving the call to of_scan_flat_dt() up, as the code
scanning the "/chosen" node now needs to be aware of the values of
"#address-cells" and "#size-cells".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Notes:
1. To avoid reserving the region twice, this depends on "MIPS: Avoid
duplicate elf core header reservation",
2. IA64 also has custom code to reserve the region, but is not
affected, as IA64 does not use DT,
3. About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual reservation in generic code, too,
v4:
- Use IS_ENABLED() instead of #ifdef,
- Clarify what architecture-specific code is still responsible for.
---
Documentation/devicetree/bindings/chosen.txt | 6 +-
drivers/of/fdt.c | 59 +++++++++++++++++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646c537..5b0b94eb2d04e79d 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -106,9 +106,9 @@ respectively, of the root node.
linux,elfcorehdr
----------------
-This property (currently used only on arm64) holds the memory range,
-the address and the size, of the elf core header which mainly describes
-the panicked kernel's memory layout as PT_LOAD segments of elf format.
+This property holds the memory range, the address and the size, of the elf
+core header which mainly describes the panicked kernel's memory layout as
+PT_LOAD segments of elf format.
e.g.
/ {
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9e5074d52879649b..99be3e03af29089f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "OF: fdt: " fmt
+#include <linux/crash_dump.h>
#include <linux/crc32.h>
#include <linux/kernel.h>
#include <linux/initrd.h>
@@ -581,6 +582,30 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
return 0;
}
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves the memory occupied by an elf core header
+ * described in the device tree. This region contains all the
+ * information about primary kernel's core image and is used by a dump
+ * capture kernel to access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP) || !elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %llu KiB of memory at 0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+
/**
* early_init_fdt_scan_reserved_mem() - create reserved memory regions
*
@@ -606,6 +631,7 @@ void __init early_init_fdt_scan_reserved_mem(void)
of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
fdt_init_reserved_mem();
+ reserve_elfcorehdr();
}
/**
@@ -904,6 +930,32 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
}
#endif /* CONFIG_BLK_DEV_INITRD */
+/**
+ * early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
+ * tree
+ * @node: reference to node containing elfcorehdr location ('chosen')
+ */
+static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP))
+ return;
+
+ pr_debug("Looking for elfcorehdr property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("elfcorehdr_start=0x%llx elfcorehdr_size=0x%llx\n",
+ elfcorehdr_addr, elfcorehdr_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1051,6 +1103,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 0;
early_init_dt_check_for_initrd(node);
+ early_init_dt_check_for_elfcorehdr(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1195,14 +1248,14 @@ void __init early_init_dt_scan_nodes(void)
{
int rc = 0;
+ /* Initialize {size,address}-cells info */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+
/* Retrieve various information from the /chosen node */
rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
if (!rc)
pr_warn("No chosen node found, continuing without\n");
- /* Initialize {size,address}-cells info */
- of_scan_flat_dt(early_init_dt_scan_root, NULL);
-
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
There are two methods to specify the location of the elf core headers:
using the "elfcorehdr=" kernel parameter, as handled by generic code in
kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the
"/chosen" node in the Device Tree, as handled by architecture-specific
code in arch/arm64/mm/init.c.
Extend support for "linux,elfcorehdr" to all platforms supporting DT by
adding platform-agnostic handling for handling this property to the FDT
core code. This can co-exist safely with the architecture-specific
handling, until the latter has been removed.
This requires moving the call to of_scan_flat_dt() up, as the code
scanning the "/chosen" node now needs to be aware of the values of
"#address-cells" and "#size-cells".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Notes:
1. To avoid reserving the region twice, this depends on "MIPS: Avoid
duplicate elf core header reservation",
2. IA64 also has custom code to reserve the region, but is not
affected, as IA64 does not use DT,
3. About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual reservation in generic code, too,
v4:
- Use IS_ENABLED() instead of #ifdef,
- Clarify what architecture-specific code is still responsible for.
---
Documentation/devicetree/bindings/chosen.txt | 6 +-
drivers/of/fdt.c | 59 +++++++++++++++++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646c537..5b0b94eb2d04e79d 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -106,9 +106,9 @@ respectively, of the root node.
linux,elfcorehdr
----------------
-This property (currently used only on arm64) holds the memory range,
-the address and the size, of the elf core header which mainly describes
-the panicked kernel's memory layout as PT_LOAD segments of elf format.
+This property holds the memory range, the address and the size, of the elf
+core header which mainly describes the panicked kernel's memory layout as
+PT_LOAD segments of elf format.
e.g.
/ {
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9e5074d52879649b..99be3e03af29089f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "OF: fdt: " fmt
+#include <linux/crash_dump.h>
#include <linux/crc32.h>
#include <linux/kernel.h>
#include <linux/initrd.h>
@@ -581,6 +582,30 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
return 0;
}
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves the memory occupied by an elf core header
+ * described in the device tree. This region contains all the
+ * information about primary kernel's core image and is used by a dump
+ * capture kernel to access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP) || !elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %llu KiB of memory at 0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+
/**
* early_init_fdt_scan_reserved_mem() - create reserved memory regions
*
@@ -606,6 +631,7 @@ void __init early_init_fdt_scan_reserved_mem(void)
of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
fdt_init_reserved_mem();
+ reserve_elfcorehdr();
}
/**
@@ -904,6 +930,32 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
}
#endif /* CONFIG_BLK_DEV_INITRD */
+/**
+ * early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
+ * tree
+ * @node: reference to node containing elfcorehdr location ('chosen')
+ */
+static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DUMP))
+ return;
+
+ pr_debug("Looking for elfcorehdr property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("elfcorehdr_start=0x%llx elfcorehdr_size=0x%llx\n",
+ elfcorehdr_addr, elfcorehdr_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1051,6 +1103,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 0;
early_init_dt_check_for_initrd(node);
+ early_init_dt_check_for_elfcorehdr(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1195,14 +1248,14 @@ void __init early_init_dt_scan_nodes(void)
{
int rc = 0;
+ /* Initialize {size,address}-cells info */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+
/* Retrieve various information from the /chosen node */
rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
if (!rc)
pr_warn("No chosen node found, continuing without\n");
- /* Initialize {size,address}-cells info */
- of_scan_flat_dt(early_init_dt_scan_root, NULL);
-
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
2021-08-11 8:51 ` Geert Uytterhoeven
` (2 preceding siblings ...)
(?)
@ 2021-08-11 20:46 ` kernel test robot
2021-08-12 8:16 ` Geert Uytterhoeven
-1 siblings, 1 reply; 95+ messages in thread
From: kernel test robot @ 2021-08-11 20:46 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4218 bytes --]
Hi Geert,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on arm64/for-next/core arm/for-next linus/master v5.14-rc5 next-20210811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 10.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/34ef57fdde286c4999f0deea8ee16d56d2ac3bae
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
git checkout 34ef57fdde286c4999f0deea8ee16d56d2ac3bae
# save the attached .config to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/of/fdt.c:593:20: error: conflicting types for 'reserve_elfcorehdr'
593 | static void __init reserve_elfcorehdr(void)
| ^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/mmzone.h:16,
from arch/ia64/include/asm/nodedata.h:17,
from arch/ia64/include/asm/processor.h:81,
from arch/ia64/include/asm/thread_info.h:12,
from include/linux/thread_info.h:60,
from include/asm-generic/preempt.h:5,
from ./arch/ia64/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rculist.h:11,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from include/linux/ptrace.h:6,
from arch/ia64/include/asm/user.h:32,
from include/linux/user.h:1,
from include/linux/elfcore.h:5,
from include/linux/crash_core.h:6,
from include/linux/kexec.h:18,
from include/linux/crash_dump.h:5,
from drivers/of/fdt.c:11:
arch/ia64/include/asm/meminit.h:43:12: note: previous declaration of 'reserve_elfcorehdr' was here
43 | extern int reserve_elfcorehdr(u64 *start, u64 *end);
| ^~~~~~~~~~~~~~~~~~
vim +/reserve_elfcorehdr +593 drivers/of/fdt.c
584
585 /*
586 * reserve_elfcorehdr() - reserves memory for elf core header
587 *
588 * This function reserves the memory occupied by an elf core header
589 * described in the device tree. This region contains all the
590 * information about primary kernel's core image and is used by a dump
591 * capture kernel to access the system memory on primary kernel.
592 */
> 593 static void __init reserve_elfcorehdr(void)
594 {
595 if (!IS_ENABLED(CONFIG_CRASH_DUMP) || !elfcorehdr_size)
596 return;
597
598 if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
599 pr_warn("elfcorehdr is overlapped\n");
600 return;
601 }
602
603 memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
604
605 pr_info("Reserving %llu KiB of memory at 0x%llx for elfcorehdr\n",
606 elfcorehdr_size >> 10, elfcorehdr_addr);
607 }
608
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 64456 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 3/9] of: fdt: Add generic support for handling elf core headers property
2021-08-11 20:46 ` kernel test robot
@ 2021-08-12 8:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-12 8:16 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]
On Wed, Aug 11, 2021 at 10:46 PM kernel test robot <lkp@intel.com> wrote:
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on arm64/for-next/core arm/for-next linus/master v5.14-rc5 next-20210811]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 10.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/0day-ci/linux/commit/34ef57fdde286c4999f0deea8ee16d56d2ac3bae
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Geert-Uytterhoeven/Add-generic-support-for-kdump-DT-properties/20210811-165455
> git checkout 34ef57fdde286c4999f0deea8ee16d56d2ac3bae
> # save the attached .config to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/of/fdt.c:593:20: error: conflicting types for 'reserve_elfcorehdr'
> 593 | static void __init reserve_elfcorehdr(void)
> | ^~~~~~~~~~~~~~~~~~
> In file included from arch/ia64/include/asm/mmzone.h:16,
> from arch/ia64/include/asm/nodedata.h:17,
> from arch/ia64/include/asm/processor.h:81,
> from arch/ia64/include/asm/thread_info.h:12,
> from include/linux/thread_info.h:60,
> from include/asm-generic/preempt.h:5,
> from ./arch/ia64/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:78,
> from include/linux/rcupdate.h:27,
> from include/linux/rculist.h:11,
> from include/linux/pid.h:5,
> from include/linux/sched.h:14,
> from include/linux/ptrace.h:6,
> from arch/ia64/include/asm/user.h:32,
> from include/linux/user.h:1,
> from include/linux/elfcore.h:5,
> from include/linux/crash_core.h:6,
> from include/linux/kexec.h:18,
> from include/linux/crash_dump.h:5,
> from drivers/of/fdt.c:11:
> arch/ia64/include/asm/meminit.h:43:12: note: previous declaration of 'reserve_elfcorehdr' was here
> 43 | extern int reserve_elfcorehdr(u64 *start, u64 *end);
> | ^~~~~~~~~~~~~~~~~~
Thanks, I will rename reserve_elfcorehdr() in the core FDT code to
fdt_reserve_elfcorehdr(), and send a separate patch to make the ia64
variant static, as it no longer needs to be global.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH v5 4/9] of: fdt: Add generic support for handling usable memory range property
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for handling the "linux,usable-memory-range" property in the
"/chosen" node to the FDT core code. This can co-exist safely with the
architecture-specific handling, until the latter has been removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual capping in generic code, too,
v4:
- New.
---
Documentation/devicetree/bindings/chosen.txt | 6 ++--
drivers/of/fdt.c | 30 ++++++++++++++++++++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 5b0b94eb2d04e79d..1cc3aa10dcb10588 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -79,9 +79,9 @@ a different secondary CPU release mechanism)
linux,usable-memory-range
-------------------------
-This property (arm64 only) holds a base address and size, describing a
-limited region in which memory may be considered available for use by
-the kernel. Memory outside of this range is not available for use.
+This property holds a base address and size, describing a limited region in
+which memory may be considered available for use by the kernel. Memory outside
+of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 99be3e03af29089f..bc041d8141e86e62 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -956,6 +956,32 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static phys_addr_t cap_mem_addr;
+static phys_addr_t cap_mem_size;
+
+/**
+ * early_init_dt_check_for_usable_mem_range - Decode usable memory range
+ * location from flat tree
+ * @node: reference to node containing usable memory range location ('chosen')
+ */
+static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ pr_debug("Looking for usable-memory-range property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
+ &cap_mem_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1104,6 +1130,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_usable_mem_range(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1258,6 +1285,9 @@ void __init early_init_dt_scan_nodes(void)
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+
+ /* Handle linux,usable-memory-range property */
+ memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
}
bool __init early_init_dt_scan(void *params)
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 4/9] of: fdt: Add generic support for handling usable memory range property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for handling the "linux,usable-memory-range" property in the
"/chosen" node to the FDT core code. This can co-exist safely with the
architecture-specific handling, until the latter has been removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual capping in generic code, too,
v4:
- New.
---
Documentation/devicetree/bindings/chosen.txt | 6 ++--
drivers/of/fdt.c | 30 ++++++++++++++++++++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 5b0b94eb2d04e79d..1cc3aa10dcb10588 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -79,9 +79,9 @@ a different secondary CPU release mechanism)
linux,usable-memory-range
-------------------------
-This property (arm64 only) holds a base address and size, describing a
-limited region in which memory may be considered available for use by
-the kernel. Memory outside of this range is not available for use.
+This property holds a base address and size, describing a limited region in
+which memory may be considered available for use by the kernel. Memory outside
+of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 99be3e03af29089f..bc041d8141e86e62 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -956,6 +956,32 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static phys_addr_t cap_mem_addr;
+static phys_addr_t cap_mem_size;
+
+/**
+ * early_init_dt_check_for_usable_mem_range - Decode usable memory range
+ * location from flat tree
+ * @node: reference to node containing usable memory range location ('chosen')
+ */
+static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ pr_debug("Looking for usable-memory-range property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
+ &cap_mem_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1104,6 +1130,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_usable_mem_range(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1258,6 +1285,9 @@ void __init early_init_dt_scan_nodes(void)
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+
+ /* Handle linux,usable-memory-range property */
+ memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
}
bool __init early_init_dt_scan(void *params)
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 4/9] of: fdt: Add generic support for handling usable memory range property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for handling the "linux,usable-memory-range" property in the
"/chosen" node to the FDT core code. This can co-exist safely with the
architecture-specific handling, until the latter has been removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual capping in generic code, too,
v4:
- New.
---
Documentation/devicetree/bindings/chosen.txt | 6 ++--
drivers/of/fdt.c | 30 ++++++++++++++++++++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 5b0b94eb2d04e79d..1cc3aa10dcb10588 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -79,9 +79,9 @@ a different secondary CPU release mechanism)
linux,usable-memory-range
-------------------------
-This property (arm64 only) holds a base address and size, describing a
-limited region in which memory may be considered available for use by
-the kernel. Memory outside of this range is not available for use.
+This property holds a base address and size, describing a limited region in
+which memory may be considered available for use by the kernel. Memory outside
+of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 99be3e03af29089f..bc041d8141e86e62 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -956,6 +956,32 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static phys_addr_t cap_mem_addr;
+static phys_addr_t cap_mem_size;
+
+/**
+ * early_init_dt_check_for_usable_mem_range - Decode usable memory range
+ * location from flat tree
+ * @node: reference to node containing usable memory range location ('chosen')
+ */
+static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ pr_debug("Looking for usable-memory-range property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
+ &cap_mem_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1104,6 +1130,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_usable_mem_range(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1258,6 +1285,9 @@ void __init early_init_dt_scan_nodes(void)
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+
+ /* Handle linux,usable-memory-range property */
+ memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
}
bool __init early_init_dt_scan(void *params)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 4/9] of: fdt: Add generic support for handling usable memory range property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for handling the "linux,usable-memory-range" property in the
"/chosen" node to the FDT core code. This can co-exist safely with the
architecture-specific handling, until the latter has been removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
About the change to chosen.txt: I have a similar change for
schemas/chosen.yaml in dt-schema.
v5:
- Handle the actual capping in generic code, too,
v4:
- New.
---
Documentation/devicetree/bindings/chosen.txt | 6 ++--
drivers/of/fdt.c | 30 ++++++++++++++++++++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 5b0b94eb2d04e79d..1cc3aa10dcb10588 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -79,9 +79,9 @@ a different secondary CPU release mechanism)
linux,usable-memory-range
-------------------------
-This property (arm64 only) holds a base address and size, describing a
-limited region in which memory may be considered available for use by
-the kernel. Memory outside of this range is not available for use.
+This property holds a base address and size, describing a limited region in
+which memory may be considered available for use by the kernel. Memory outside
+of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 99be3e03af29089f..bc041d8141e86e62 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -956,6 +956,32 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static phys_addr_t cap_mem_addr;
+static phys_addr_t cap_mem_size;
+
+/**
+ * early_init_dt_check_for_usable_mem_range - Decode usable memory range
+ * location from flat tree
+ * @node: reference to node containing usable memory range location ('chosen')
+ */
+static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
+{
+ const __be32 *prop;
+ int len;
+
+ pr_debug("Looking for usable-memory-range property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
+ if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return;
+
+ cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
+ &cap_mem_size);
+}
+
#ifdef CONFIG_SERIAL_EARLYCON
int __init early_init_dt_scan_chosen_stdout(void)
@@ -1104,6 +1130,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_usable_mem_range(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1258,6 +1285,9 @@ void __init early_init_dt_scan_nodes(void)
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+
+ /* Handle linux,usable-memory-range property */
+ memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
}
bool __init early_init_dt_scan(void *params)
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v5 5/9] of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD"
by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile
coverage and to simplify the code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- No changes,
v4:
- New.
---
drivers/of/fdt.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bc041d8141e86e62..0142b9334559baec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,7 +880,6 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
return best_data;
}
-#ifdef CONFIG_BLK_DEV_INITRD
static void __early_init_dt_declare_initrd(unsigned long start,
unsigned long end)
{
@@ -906,6 +905,9 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
int len;
const __be32 *prop;
+ if (!IS_ENABLED(CONFIG_BLK_DEV_INITRD))
+ return;
+
pr_debug("Looking for initrd properties... ");
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
@@ -924,11 +926,6 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n", start, end);
}
-#else
-static inline void early_init_dt_check_for_initrd(unsigned long node)
-{
-}
-#endif /* CONFIG_BLK_DEV_INITRD */
/**
* early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 5/9] of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD"
by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile
coverage and to simplify the code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- No changes,
v4:
- New.
---
drivers/of/fdt.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bc041d8141e86e62..0142b9334559baec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,7 +880,6 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
return best_data;
}
-#ifdef CONFIG_BLK_DEV_INITRD
static void __early_init_dt_declare_initrd(unsigned long start,
unsigned long end)
{
@@ -906,6 +905,9 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
int len;
const __be32 *prop;
+ if (!IS_ENABLED(CONFIG_BLK_DEV_INITRD))
+ return;
+
pr_debug("Looking for initrd properties... ");
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
@@ -924,11 +926,6 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n", start, end);
}
-#else
-static inline void early_init_dt_check_for_initrd(unsigned long node)
-{
-}
-#endif /* CONFIG_BLK_DEV_INITRD */
/**
* early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 5/9] of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD"
by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile
coverage and to simplify the code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- No changes,
v4:
- New.
---
drivers/of/fdt.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bc041d8141e86e62..0142b9334559baec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,7 +880,6 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
return best_data;
}
-#ifdef CONFIG_BLK_DEV_INITRD
static void __early_init_dt_declare_initrd(unsigned long start,
unsigned long end)
{
@@ -906,6 +905,9 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
int len;
const __be32 *prop;
+ if (!IS_ENABLED(CONFIG_BLK_DEV_INITRD))
+ return;
+
pr_debug("Looking for initrd properties... ");
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
@@ -924,11 +926,6 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n", start, end);
}
-#else
-static inline void early_init_dt_check_for_initrd(unsigned long node)
-{
-}
-#endif /* CONFIG_BLK_DEV_INITRD */
/**
* early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 5/9] of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD"
by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile
coverage and to simplify the code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- No changes,
v4:
- New.
---
drivers/of/fdt.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bc041d8141e86e62..0142b9334559baec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,7 +880,6 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
return best_data;
}
-#ifdef CONFIG_BLK_DEV_INITRD
static void __early_init_dt_declare_initrd(unsigned long start,
unsigned long end)
{
@@ -906,6 +905,9 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
int len;
const __be32 *prop;
+ if (!IS_ENABLED(CONFIG_BLK_DEV_INITRD))
+ return;
+
pr_debug("Looking for initrd properties... ");
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
@@ -924,11 +926,6 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n", start, end);
}
-#else
-static inline void early_init_dt_check_for_initrd(unsigned long node)
-{
-}
-#endif /* CONFIG_BLK_DEV_INITRD */
/**
* early_init_dt_check_for_elfcorehdr - Decode elfcorehdr location from flat
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v5 6/9] riscv: Remove non-standard linux,elfcorehdr handling
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven,
Palmer Dabbelt
RISC-V uses platform-specific code to locate the elf core header in
memory. However, this does not conform to the standard
"linux,elfcorehdr" DT bindings, as it relies on a reserved memory node
with the "linux,elfcorehdr" compatible value, instead of on a
"linux,elfcorehdr" property under the "/chosen" node.
The non-compliant code can just be removed, as the standard behavior is
already implemented by platform-agnostic handling in the FDT core code.
Fixes: 5640975003d0234d ("RISC-V: Add crash kernel support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
v5:
- Add Reviewed-by, Acked-by,
v4:
- No changes.
---
arch/riscv/mm/init.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 88134cc288d9a60b..3f284b2d327166af 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -860,26 +860,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-/*
- * We keep track of the ELF core header of the crashed
- * kernel with a reserved-memory region with compatible
- * string "linux,elfcorehdr". Here we register a callback
- * to populate elfcorehdr_addr/size when this region is
- * present. Note that this region will be marked as
- * reserved once we call early_init_fdt_scan_reserved_mem()
- * later on.
- */
-static int __init elfcore_hdr_setup(struct reserved_mem *rmem)
-{
- elfcorehdr_addr = rmem->base;
- elfcorehdr_size = rmem->size;
- return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
-#endif
-
void __init paging_init(void)
{
setup_bootmem();
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 6/9] riscv: Remove non-standard linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven,
Palmer Dabbelt
RISC-V uses platform-specific code to locate the elf core header in
memory. However, this does not conform to the standard
"linux,elfcorehdr" DT bindings, as it relies on a reserved memory node
with the "linux,elfcorehdr" compatible value, instead of on a
"linux,elfcorehdr" property under the "/chosen" node.
The non-compliant code can just be removed, as the standard behavior is
already implemented by platform-agnostic handling in the FDT core code.
Fixes: 5640975003d0234d ("RISC-V: Add crash kernel support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
v5:
- Add Reviewed-by, Acked-by,
v4:
- No changes.
---
arch/riscv/mm/init.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 88134cc288d9a60b..3f284b2d327166af 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -860,26 +860,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-/*
- * We keep track of the ELF core header of the crashed
- * kernel with a reserved-memory region with compatible
- * string "linux,elfcorehdr". Here we register a callback
- * to populate elfcorehdr_addr/size when this region is
- * present. Note that this region will be marked as
- * reserved once we call early_init_fdt_scan_reserved_mem()
- * later on.
- */
-static int __init elfcore_hdr_setup(struct reserved_mem *rmem)
-{
- elfcorehdr_addr = rmem->base;
- elfcorehdr_size = rmem->size;
- return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
-#endif
-
void __init paging_init(void)
{
setup_bootmem();
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 6/9] riscv: Remove non-standard linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven,
Palmer Dabbelt
RISC-V uses platform-specific code to locate the elf core header in
memory. However, this does not conform to the standard
"linux,elfcorehdr" DT bindings, as it relies on a reserved memory node
with the "linux,elfcorehdr" compatible value, instead of on a
"linux,elfcorehdr" property under the "/chosen" node.
The non-compliant code can just be removed, as the standard behavior is
already implemented by platform-agnostic handling in the FDT core code.
Fixes: 5640975003d0234d ("RISC-V: Add crash kernel support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
v5:
- Add Reviewed-by, Acked-by,
v4:
- No changes.
---
arch/riscv/mm/init.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 88134cc288d9a60b..3f284b2d327166af 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -860,26 +860,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-/*
- * We keep track of the ELF core header of the crashed
- * kernel with a reserved-memory region with compatible
- * string "linux,elfcorehdr". Here we register a callback
- * to populate elfcorehdr_addr/size when this region is
- * present. Note that this region will be marked as
- * reserved once we call early_init_fdt_scan_reserved_mem()
- * later on.
- */
-static int __init elfcore_hdr_setup(struct reserved_mem *rmem)
-{
- elfcorehdr_addr = rmem->base;
- elfcorehdr_size = rmem->size;
- return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
-#endif
-
void __init paging_init(void)
{
setup_bootmem();
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 6/9] riscv: Remove non-standard linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven,
Palmer Dabbelt
RISC-V uses platform-specific code to locate the elf core header in
memory. However, this does not conform to the standard
"linux,elfcorehdr" DT bindings, as it relies on a reserved memory node
with the "linux,elfcorehdr" compatible value, instead of on a
"linux,elfcorehdr" property under the "/chosen" node.
The non-compliant code can just be removed, as the standard behavior is
already implemented by platform-agnostic handling in the FDT core code.
Fixes: 5640975003d0234d ("RISC-V: Add crash kernel support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
v5:
- Add Reviewed-by, Acked-by,
v4:
- No changes.
---
arch/riscv/mm/init.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 88134cc288d9a60b..3f284b2d327166af 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -860,26 +860,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-/*
- * We keep track of the ELF core header of the crashed
- * kernel with a reserved-memory region with compatible
- * string "linux,elfcorehdr". Here we register a callback
- * to populate elfcorehdr_addr/size when this region is
- * present. Note that this region will be marked as
- * reserved once we call early_init_fdt_scan_reserved_mem()
- * later on.
- */
-static int __init elfcore_hdr_setup(struct reserved_mem *rmem)
-{
- elfcorehdr_addr = rmem->base;
- elfcorehdr_size = rmem->size;
- return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
-#endif
-
void __init paging_init(void)
{
setup_bootmem();
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,elfcorehdr" property under the "/chosen" node in DT, as the
platform-agnostic handling in the FDT core code already takes care of
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- s/handlng/parsing/ in patch description.
---
arch/arm64/mm/init.c | 53 --------------------------------------------
1 file changed, 53 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8490ed2917ff2430..bac4f06bb7d900a2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -124,57 +124,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
- const char *uname, int depth, void *data)
-{
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
- elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-/*
- * reserve_elfcorehdr() - reserves memory for elf core header
- *
- * This function reserves the memory occupied by an elf core header
- * described in the device tree. This region contains all the
- * information about primary kernel's core image and is used by a dump
- * capture kernel to access the system memory on primary kernel.
- */
-static void __init reserve_elfcorehdr(void)
-{
- of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
-
- if (!elfcorehdr_size)
- return;
-
- if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
- pr_warn("elfcorehdr is overlapped\n");
- return;
- }
-
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
-
- pr_info("Reserving %lldKB of memory at 0x%llx for elfcorehdr\n",
- elfcorehdr_size >> 10, elfcorehdr_addr);
-}
-#else
-static void __init reserve_elfcorehdr(void)
-{
-}
-#endif /* CONFIG_CRASH_DUMP */
-
/*
* Return the maximum physical address for a zone accessible by the given bits
* limit. If DRAM starts above 32-bit, expand the zone to the maximum
@@ -395,8 +344,6 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- reserve_elfcorehdr();
-
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,elfcorehdr" property under the "/chosen" node in DT, as the
platform-agnostic handling in the FDT core code already takes care of
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- s/handlng/parsing/ in patch description.
---
arch/arm64/mm/init.c | 53 --------------------------------------------
1 file changed, 53 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8490ed2917ff2430..bac4f06bb7d900a2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -124,57 +124,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
- const char *uname, int depth, void *data)
-{
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
- elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-/*
- * reserve_elfcorehdr() - reserves memory for elf core header
- *
- * This function reserves the memory occupied by an elf core header
- * described in the device tree. This region contains all the
- * information about primary kernel's core image and is used by a dump
- * capture kernel to access the system memory on primary kernel.
- */
-static void __init reserve_elfcorehdr(void)
-{
- of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
-
- if (!elfcorehdr_size)
- return;
-
- if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
- pr_warn("elfcorehdr is overlapped\n");
- return;
- }
-
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
-
- pr_info("Reserving %lldKB of memory at 0x%llx for elfcorehdr\n",
- elfcorehdr_size >> 10, elfcorehdr_addr);
-}
-#else
-static void __init reserve_elfcorehdr(void)
-{
-}
-#endif /* CONFIG_CRASH_DUMP */
-
/*
* Return the maximum physical address for a zone accessible by the given bits
* limit. If DRAM starts above 32-bit, expand the zone to the maximum
@@ -395,8 +344,6 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- reserve_elfcorehdr();
-
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
}
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,elfcorehdr" property under the "/chosen" node in DT, as the
platform-agnostic handling in the FDT core code already takes care of
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- s/handlng/parsing/ in patch description.
---
arch/arm64/mm/init.c | 53 --------------------------------------------
1 file changed, 53 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8490ed2917ff2430..bac4f06bb7d900a2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -124,57 +124,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
- const char *uname, int depth, void *data)
-{
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
- elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-/*
- * reserve_elfcorehdr() - reserves memory for elf core header
- *
- * This function reserves the memory occupied by an elf core header
- * described in the device tree. This region contains all the
- * information about primary kernel's core image and is used by a dump
- * capture kernel to access the system memory on primary kernel.
- */
-static void __init reserve_elfcorehdr(void)
-{
- of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
-
- if (!elfcorehdr_size)
- return;
-
- if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
- pr_warn("elfcorehdr is overlapped\n");
- return;
- }
-
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
-
- pr_info("Reserving %lldKB of memory at 0x%llx for elfcorehdr\n",
- elfcorehdr_size >> 10, elfcorehdr_addr);
-}
-#else
-static void __init reserve_elfcorehdr(void)
-{
-}
-#endif /* CONFIG_CRASH_DUMP */
-
/*
* Return the maximum physical address for a zone accessible by the given bits
* limit. If DRAM starts above 32-bit, expand the zone to the maximum
@@ -395,8 +344,6 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- reserve_elfcorehdr();
-
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,elfcorehdr" property under the "/chosen" node in DT, as the
platform-agnostic handling in the FDT core code already takes care of
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- s/handlng/parsing/ in patch description.
---
arch/arm64/mm/init.c | 53 --------------------------------------------
1 file changed, 53 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8490ed2917ff2430..bac4f06bb7d900a2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -124,57 +124,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
- const char *uname, int depth, void *data)
-{
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
- elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-/*
- * reserve_elfcorehdr() - reserves memory for elf core header
- *
- * This function reserves the memory occupied by an elf core header
- * described in the device tree. This region contains all the
- * information about primary kernel's core image and is used by a dump
- * capture kernel to access the system memory on primary kernel.
- */
-static void __init reserve_elfcorehdr(void)
-{
- of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
-
- if (!elfcorehdr_size)
- return;
-
- if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
- pr_warn("elfcorehdr is overlapped\n");
- return;
- }
-
- memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
-
- pr_info("Reserving %lldKB of memory at 0x%llx for elfcorehdr\n",
- elfcorehdr_size >> 10, elfcorehdr_addr);
-}
-#else
-static void __init reserve_elfcorehdr(void)
-{
-}
-#endif /* CONFIG_CRASH_DUMP */
-
/*
* Return the maximum physical address for a zone accessible by the given bits
* limit. If DRAM starts above 32-bit, expand the zone to the maximum
@@ -395,8 +344,6 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- reserve_elfcorehdr();
-
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
}
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
2021-08-11 8:51 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-23 12:55 ` Catalin Marinas
-1 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:05AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,elfcorehdr" property under the "/chosen" node in DT, as the
> platform-agnostic handling in the FDT core code already takes care of
> this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:05AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,elfcorehdr" property under the "/chosen" node in DT, as the
> platform-agnostic handling in the FDT core code already takes care of
> this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:05AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,elfcorehdr" property under the "/chosen" node in DT, as the
> platform-agnostic handling in the FDT core code already takes care of
> this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 7/9] arm64: kdump: Remove custom linux,elfcorehdr handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:05AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,elfcorehdr" property under the "/chosen" node in DT, as the
> platform-agnostic handling in the FDT core code already takes care of
> this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH v5 8/9] arm64: kdump: Remove custom linux,usable-memory-range handling
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,usable-memory-range" property under the "/chosen" node in DT, as
the platform-agnostic FDT core code already takes care of this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- New.
---
arch/arm64/mm/init.c | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index bac4f06bb7d900a2..4e90a1d170587376 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -197,45 +197,10 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
-static int __init early_init_dt_scan_usablemem(unsigned long node,
- const char *uname, int depth, void *data)
-{
- struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-static void __init fdt_enforce_memory_region(void)
-{
- struct memblock_region reg = {
- .size = 0,
- };
-
- of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
-
- if (reg.size)
- memblock_cap_memory_range(reg.base, reg.size);
-}
-
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
- /* Handle linux,usable-memory-range property */
- fdt_enforce_memory_region();
-
/* Remove memory above our supported physical address size */
memblock_remove(1ULL << PHYS_MASK_SHIFT, ULLONG_MAX);
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 8/9] arm64: kdump: Remove custom linux, usable-memory-range handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,usable-memory-range" property under the "/chosen" node in DT, as
the platform-agnostic FDT core code already takes care of this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- New.
---
arch/arm64/mm/init.c | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index bac4f06bb7d900a2..4e90a1d170587376 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -197,45 +197,10 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
-static int __init early_init_dt_scan_usablemem(unsigned long node,
- const char *uname, int depth, void *data)
-{
- struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-static void __init fdt_enforce_memory_region(void)
-{
- struct memblock_region reg = {
- .size = 0,
- };
-
- of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
-
- if (reg.size)
- memblock_cap_memory_range(reg.base, reg.size);
-}
-
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
- /* Handle linux,usable-memory-range property */
- fdt_enforce_memory_region();
-
/* Remove memory above our supported physical address size */
memblock_remove(1ULL << PHYS_MASK_SHIFT, ULLONG_MAX);
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 8/9] arm64: kdump: Remove custom linux, usable-memory-range handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,usable-memory-range" property under the "/chosen" node in DT, as
the platform-agnostic FDT core code already takes care of this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- New.
---
arch/arm64/mm/init.c | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index bac4f06bb7d900a2..4e90a1d170587376 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -197,45 +197,10 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
-static int __init early_init_dt_scan_usablemem(unsigned long node,
- const char *uname, int depth, void *data)
-{
- struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-static void __init fdt_enforce_memory_region(void)
-{
- struct memblock_region reg = {
- .size = 0,
- };
-
- of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
-
- if (reg.size)
- memblock_cap_memory_range(reg.base, reg.size);
-}
-
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
- /* Handle linux,usable-memory-range property */
- fdt_enforce_memory_region();
-
/* Remove memory above our supported physical address size */
memblock_remove(1ULL << PHYS_MASK_SHIFT, ULLONG_MAX);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 8/9] arm64: kdump: Remove custom linux, usable-memory-range handling
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Remove the architecture-specific code for handling the
"linux,usable-memory-range" property under the "/chosen" node in DT, as
the platform-agnostic FDT core code already takes care of this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v5:
- Remove all handling, not just parsing,
v4:
- New.
---
arch/arm64/mm/init.c | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index bac4f06bb7d900a2..4e90a1d170587376 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -197,45 +197,10 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
-static int __init early_init_dt_scan_usablemem(unsigned long node,
- const char *uname, int depth, void *data)
-{
- struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
-
- if (depth != 1 || strcmp(uname, "chosen") != 0)
- return 0;
-
- reg = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
- if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
- return 1;
-
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
-
- return 1;
-}
-
-static void __init fdt_enforce_memory_region(void)
-{
- struct memblock_region reg = {
- .size = 0,
- };
-
- of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
-
- if (reg.size)
- memblock_cap_memory_range(reg.base, reg.size);
-}
-
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
- /* Handle linux,usable-memory-range property */
- fdt_enforce_memory_region();
-
/* Remove memory above our supported physical address size */
memblock_remove(1ULL << PHYS_MASK_SHIFT, ULLONG_MAX);
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH v5 8/9] arm64: kdump: Remove custom linux,usable-memory-range handling
2021-08-11 8:51 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-23 12:55 ` Catalin Marinas
-1 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:06AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,usable-memory-range" property under the "/chosen" node in DT, as
> the platform-agnostic FDT core code already takes care of this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 8/9] arm64: kdump: Remove custom linux,usable-memory-range handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:06AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,usable-memory-range" property under the "/chosen" node in DT, as
> the platform-agnostic FDT core code already takes care of this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 8/9] arm64: kdump: Remove custom linux,usable-memory-range handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:06AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,usable-memory-range" property under the "/chosen" node in DT, as
> the platform-agnostic FDT core code already takes care of this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH v5 8/9] arm64: kdump: Remove custom linux,usable-memory-range handling
@ 2021-08-23 12:55 ` Catalin Marinas
0 siblings, 0 replies; 95+ messages in thread
From: Catalin Marinas @ 2021-08-23 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Will Deacon, Thomas Bogendoerfer, Nick Kossifidis,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Frank Rowand,
Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:51:06AM +0200, Geert Uytterhoeven wrote:
> Remove the architecture-specific code for handling the
> "linux,usable-memory-range" property under the "/chosen" node in DT, as
> the platform-agnostic FDT core code already takes care of this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH v5 9/9] ARM: uncompress: Parse "linux,usable-memory-range" DT property
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-11 8:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for parsing the "linux,usable-memory-range" DT property.
This property is used to describe the usable memory reserved for the
crash dump kernel, and thus makes the memory reservation explicit.
If present, Linux no longer needs to mask the program counter, and rely
on the "mem=" kernel parameter to obtain the start and size of usable
memory.
For backwards compatibility, the traditional method to derive the start
of memory is still used if "linux,usable-memory-range" is absent.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add DT
properties to crash dump kernel's DTB", which is still valid:
https://lore.kernel.org/linux-arm-kernel/20200902154129.6358-1-geert+renesas@glider.be/
v5:
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c,
v4:
- Remove references to architectures in chosen.txt, to avoid having to
change this again when more architectures copy kdump support,
- Remove the architecture-specific code for parsing
"linux,usable-memory-range" and "linux,elfcorehdr", as the FDT core
code now takes care of this,
- Move chosen.txt change to patch changing the FDT core,
- Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of #ifdef,
v3:
- Rebase on top of accepted solution for DTB memory information
handling, which is part of v5.12-rc1,
v2:
- Rebase on top of reworked DTB memory information handling.
---
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++++++++++---
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index 62450d824c3ca180..9291a2661bdfe57f 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -55,16 +55,17 @@ static uint64_t get_val(const fdt32_t *cells, uint32_t ncells)
* DTB, and, if out-of-range, replace it by the real start address.
* To preserve backwards compatibility (systems reserving a block of memory
* at the start of physical memory, kdump, ...), the traditional method is
- * always used if it yields a valid address.
+ * used if it yields a valid address, unless the "linux,usable-memory-range"
+ * property is present.
*
* Return value: start address of physical memory to use
*/
uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
{
- uint32_t addr_cells, size_cells, base;
+ uint32_t addr_cells, size_cells, usable_base, base;
uint32_t fdt_mem_start = 0xffffffff;
- const fdt32_t *reg, *endp;
- uint64_t size, end;
+ const fdt32_t *usable, *reg, *endp;
+ uint64_t size, usable_end, end;
const char *type;
int offset, len;
@@ -80,6 +81,27 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
if (addr_cells > 2 || size_cells > 2)
return mem_start;
+ /*
+ * Usable memory in case of a crash dump kernel
+ * This property describes a limitation: memory within this range is
+ * only valid when also described through another mechanism
+ */
+ usable = get_prop(fdt, "/chosen", "linux,usable-memory-range",
+ (addr_cells + size_cells) * sizeof(fdt32_t));
+ if (usable) {
+ size = get_val(usable + addr_cells, size_cells);
+ if (!size)
+ return mem_start;
+
+ if (addr_cells > 1 && fdt32_ld(usable)) {
+ /* Outside 32-bit address space */
+ return mem_start;
+ }
+
+ usable_base = fdt32_ld(usable + addr_cells - 1);
+ usable_end = usable_base + size;
+ }
+
/* Walk all memory nodes and regions */
for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
offset = fdt_next_node(fdt, offset, NULL)) {
@@ -107,7 +129,20 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
base = fdt32_ld(reg + addr_cells - 1);
end = base + size;
- if (mem_start >= base && mem_start < end) {
+ if (usable) {
+ /*
+ * Clip to usable range, which takes precedence
+ * over mem_start
+ */
+ if (base < usable_base)
+ base = usable_base;
+
+ if (end > usable_end)
+ end = usable_end;
+
+ if (end <= base)
+ continue;
+ } else if (mem_start >= base && mem_start < end) {
/* Calculated address is valid, use it */
return mem_start;
}
@@ -123,7 +158,8 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
}
/*
- * The calculated address is not usable.
+ * The calculated address is not usable, or was overridden by the
+ * "linux,usable-memory-range" property.
* Use the lowest usable physical memory address from the DTB instead,
* and make sure this is a multiple of 2 MiB for phys/virt patching.
*/
--
2.25.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 9/9] ARM: uncompress: Parse "linux, usable-memory-range" DT property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for parsing the "linux,usable-memory-range" DT property.
This property is used to describe the usable memory reserved for the
crash dump kernel, and thus makes the memory reservation explicit.
If present, Linux no longer needs to mask the program counter, and rely
on the "mem=" kernel parameter to obtain the start and size of usable
memory.
For backwards compatibility, the traditional method to derive the start
of memory is still used if "linux,usable-memory-range" is absent.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add DT
properties to crash dump kernel's DTB", which is still valid:
https://lore.kernel.org/linux-arm-kernel/20200902154129.6358-1-geert+renesas@glider.be/
v5:
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c,
v4:
- Remove references to architectures in chosen.txt, to avoid having to
change this again when more architectures copy kdump support,
- Remove the architecture-specific code for parsing
"linux,usable-memory-range" and "linux,elfcorehdr", as the FDT core
code now takes care of this,
- Move chosen.txt change to patch changing the FDT core,
- Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of #ifdef,
v3:
- Rebase on top of accepted solution for DTB memory information
handling, which is part of v5.12-rc1,
v2:
- Rebase on top of reworked DTB memory information handling.
---
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++++++++++---
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index 62450d824c3ca180..9291a2661bdfe57f 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -55,16 +55,17 @@ static uint64_t get_val(const fdt32_t *cells, uint32_t ncells)
* DTB, and, if out-of-range, replace it by the real start address.
* To preserve backwards compatibility (systems reserving a block of memory
* at the start of physical memory, kdump, ...), the traditional method is
- * always used if it yields a valid address.
+ * used if it yields a valid address, unless the "linux,usable-memory-range"
+ * property is present.
*
* Return value: start address of physical memory to use
*/
uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
{
- uint32_t addr_cells, size_cells, base;
+ uint32_t addr_cells, size_cells, usable_base, base;
uint32_t fdt_mem_start = 0xffffffff;
- const fdt32_t *reg, *endp;
- uint64_t size, end;
+ const fdt32_t *usable, *reg, *endp;
+ uint64_t size, usable_end, end;
const char *type;
int offset, len;
@@ -80,6 +81,27 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
if (addr_cells > 2 || size_cells > 2)
return mem_start;
+ /*
+ * Usable memory in case of a crash dump kernel
+ * This property describes a limitation: memory within this range is
+ * only valid when also described through another mechanism
+ */
+ usable = get_prop(fdt, "/chosen", "linux,usable-memory-range",
+ (addr_cells + size_cells) * sizeof(fdt32_t));
+ if (usable) {
+ size = get_val(usable + addr_cells, size_cells);
+ if (!size)
+ return mem_start;
+
+ if (addr_cells > 1 && fdt32_ld(usable)) {
+ /* Outside 32-bit address space */
+ return mem_start;
+ }
+
+ usable_base = fdt32_ld(usable + addr_cells - 1);
+ usable_end = usable_base + size;
+ }
+
/* Walk all memory nodes and regions */
for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
offset = fdt_next_node(fdt, offset, NULL)) {
@@ -107,7 +129,20 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
base = fdt32_ld(reg + addr_cells - 1);
end = base + size;
- if (mem_start >= base && mem_start < end) {
+ if (usable) {
+ /*
+ * Clip to usable range, which takes precedence
+ * over mem_start
+ */
+ if (base < usable_base)
+ base = usable_base;
+
+ if (end > usable_end)
+ end = usable_end;
+
+ if (end <= base)
+ continue;
+ } else if (mem_start >= base && mem_start < end) {
/* Calculated address is valid, use it */
return mem_start;
}
@@ -123,7 +158,8 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
}
/*
- * The calculated address is not usable.
+ * The calculated address is not usable, or was overridden by the
+ * "linux,usable-memory-range" property.
* Use the lowest usable physical memory address from the DTB instead,
* and make sure this is a multiple of 2 MiB for phys/virt patching.
*/
--
2.25.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 9/9] ARM: uncompress: Parse "linux, usable-memory-range" DT property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for parsing the "linux,usable-memory-range" DT property.
This property is used to describe the usable memory reserved for the
crash dump kernel, and thus makes the memory reservation explicit.
If present, Linux no longer needs to mask the program counter, and rely
on the "mem=" kernel parameter to obtain the start and size of usable
memory.
For backwards compatibility, the traditional method to derive the start
of memory is still used if "linux,usable-memory-range" is absent.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add DT
properties to crash dump kernel's DTB", which is still valid:
https://lore.kernel.org/linux-arm-kernel/20200902154129.6358-1-geert+renesas@glider.be/
v5:
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c,
v4:
- Remove references to architectures in chosen.txt, to avoid having to
change this again when more architectures copy kdump support,
- Remove the architecture-specific code for parsing
"linux,usable-memory-range" and "linux,elfcorehdr", as the FDT core
code now takes care of this,
- Move chosen.txt change to patch changing the FDT core,
- Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of #ifdef,
v3:
- Rebase on top of accepted solution for DTB memory information
handling, which is part of v5.12-rc1,
v2:
- Rebase on top of reworked DTB memory information handling.
---
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++++++++++---
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index 62450d824c3ca180..9291a2661bdfe57f 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -55,16 +55,17 @@ static uint64_t get_val(const fdt32_t *cells, uint32_t ncells)
* DTB, and, if out-of-range, replace it by the real start address.
* To preserve backwards compatibility (systems reserving a block of memory
* at the start of physical memory, kdump, ...), the traditional method is
- * always used if it yields a valid address.
+ * used if it yields a valid address, unless the "linux,usable-memory-range"
+ * property is present.
*
* Return value: start address of physical memory to use
*/
uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
{
- uint32_t addr_cells, size_cells, base;
+ uint32_t addr_cells, size_cells, usable_base, base;
uint32_t fdt_mem_start = 0xffffffff;
- const fdt32_t *reg, *endp;
- uint64_t size, end;
+ const fdt32_t *usable, *reg, *endp;
+ uint64_t size, usable_end, end;
const char *type;
int offset, len;
@@ -80,6 +81,27 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
if (addr_cells > 2 || size_cells > 2)
return mem_start;
+ /*
+ * Usable memory in case of a crash dump kernel
+ * This property describes a limitation: memory within this range is
+ * only valid when also described through another mechanism
+ */
+ usable = get_prop(fdt, "/chosen", "linux,usable-memory-range",
+ (addr_cells + size_cells) * sizeof(fdt32_t));
+ if (usable) {
+ size = get_val(usable + addr_cells, size_cells);
+ if (!size)
+ return mem_start;
+
+ if (addr_cells > 1 && fdt32_ld(usable)) {
+ /* Outside 32-bit address space */
+ return mem_start;
+ }
+
+ usable_base = fdt32_ld(usable + addr_cells - 1);
+ usable_end = usable_base + size;
+ }
+
/* Walk all memory nodes and regions */
for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
offset = fdt_next_node(fdt, offset, NULL)) {
@@ -107,7 +129,20 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
base = fdt32_ld(reg + addr_cells - 1);
end = base + size;
- if (mem_start >= base && mem_start < end) {
+ if (usable) {
+ /*
+ * Clip to usable range, which takes precedence
+ * over mem_start
+ */
+ if (base < usable_base)
+ base = usable_base;
+
+ if (end > usable_end)
+ end = usable_end;
+
+ if (end <= base)
+ continue;
+ } else if (mem_start >= base && mem_start < end) {
/* Calculated address is valid, use it */
return mem_start;
}
@@ -123,7 +158,8 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
}
/*
- * The calculated address is not usable.
+ * The calculated address is not usable, or was overridden by the
+ * "linux,usable-memory-range" property.
* Use the lowest usable physical memory address from the DTB instead,
* and make sure this is a multiple of 2 MiB for phys/virt patching.
*/
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH v5 9/9] ARM: uncompress: Parse "linux, usable-memory-range" DT property
@ 2021-08-11 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-11 8:51 UTC (permalink / raw)
To: Rob Herring, Russell King, Nicolas Pitre, Ard Biesheuvel,
Linus Walleij, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young
Cc: Baoquan He, Vivek Goyal, Mike Rapoport, devicetree,
linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Add support for parsing the "linux,usable-memory-range" DT property.
This property is used to describe the usable memory reserved for the
crash dump kernel, and thus makes the memory reservation explicit.
If present, Linux no longer needs to mask the program counter, and rely
on the "mem=" kernel parameter to obtain the start and size of usable
memory.
For backwards compatibility, the traditional method to derive the start
of memory is still used if "linux,usable-memory-range" is absent.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add DT
properties to crash dump kernel's DTB", which is still valid:
https://lore.kernel.org/linux-arm-kernel/20200902154129.6358-1-geert+renesas@glider.be/
v5:
- Remove the addition of "linux,elfcorehdr" and
"linux,usable-memory-range" handling to arch/arm/mm/init.c,
v4:
- Remove references to architectures in chosen.txt, to avoid having to
change this again when more architectures copy kdump support,
- Remove the architecture-specific code for parsing
"linux,usable-memory-range" and "linux,elfcorehdr", as the FDT core
code now takes care of this,
- Move chosen.txt change to patch changing the FDT core,
- Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of #ifdef,
v3:
- Rebase on top of accepted solution for DTB memory information
handling, which is part of v5.12-rc1,
v2:
- Rebase on top of reworked DTB memory information handling.
---
.../arm/boot/compressed/fdt_check_mem_start.c | 48 ++++++++++++++++---
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index 62450d824c3ca180..9291a2661bdfe57f 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -55,16 +55,17 @@ static uint64_t get_val(const fdt32_t *cells, uint32_t ncells)
* DTB, and, if out-of-range, replace it by the real start address.
* To preserve backwards compatibility (systems reserving a block of memory
* at the start of physical memory, kdump, ...), the traditional method is
- * always used if it yields a valid address.
+ * used if it yields a valid address, unless the "linux,usable-memory-range"
+ * property is present.
*
* Return value: start address of physical memory to use
*/
uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
{
- uint32_t addr_cells, size_cells, base;
+ uint32_t addr_cells, size_cells, usable_base, base;
uint32_t fdt_mem_start = 0xffffffff;
- const fdt32_t *reg, *endp;
- uint64_t size, end;
+ const fdt32_t *usable, *reg, *endp;
+ uint64_t size, usable_end, end;
const char *type;
int offset, len;
@@ -80,6 +81,27 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
if (addr_cells > 2 || size_cells > 2)
return mem_start;
+ /*
+ * Usable memory in case of a crash dump kernel
+ * This property describes a limitation: memory within this range is
+ * only valid when also described through another mechanism
+ */
+ usable = get_prop(fdt, "/chosen", "linux,usable-memory-range",
+ (addr_cells + size_cells) * sizeof(fdt32_t));
+ if (usable) {
+ size = get_val(usable + addr_cells, size_cells);
+ if (!size)
+ return mem_start;
+
+ if (addr_cells > 1 && fdt32_ld(usable)) {
+ /* Outside 32-bit address space */
+ return mem_start;
+ }
+
+ usable_base = fdt32_ld(usable + addr_cells - 1);
+ usable_end = usable_base + size;
+ }
+
/* Walk all memory nodes and regions */
for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
offset = fdt_next_node(fdt, offset, NULL)) {
@@ -107,7 +129,20 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
base = fdt32_ld(reg + addr_cells - 1);
end = base + size;
- if (mem_start >= base && mem_start < end) {
+ if (usable) {
+ /*
+ * Clip to usable range, which takes precedence
+ * over mem_start
+ */
+ if (base < usable_base)
+ base = usable_base;
+
+ if (end > usable_end)
+ end = usable_end;
+
+ if (end <= base)
+ continue;
+ } else if (mem_start >= base && mem_start < end) {
/* Calculated address is valid, use it */
return mem_start;
}
@@ -123,7 +158,8 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
}
/*
- * The calculated address is not usable.
+ * The calculated address is not usable, or was overridden by the
+ * "linux,usable-memory-range" property.
* Use the lowest usable physical memory address from the DTB instead,
* and make sure this is a multiple of 2 MiB for phys/virt patching.
*/
--
2.25.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 95+ messages in thread
* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
2021-08-11 8:50 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-15 15:25 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-15 15:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
devicetree, linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds generic support for parsing DT properties related
> to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> the "/chosen" node), makes use of it on arm32, and performs a few
> cleanups. It is an evolution of the combination of [1] and [2].
The DT bits look fine to me. How do you expect this to be merged? I'm
happy to take it if arch maintainers can ack it.
>
> The series consists of 6 parts:
> 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> to avoid duplicating elf core header reservation later.
> 2. Patch 2 prepares the visibility of variables used to hold
> information retrieved from the DT properties.
> 3. Patches 3-5 add support to the FDT core for handling the
> properties.
> This can co-exist safely with architecture-specific handling, until
> the latter has been removed.
Looks like patch 5 doesn't have any dependencies with the series?
> 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> riscv.
I thought this should be applied for 5.14?
> 5. Patches 7-8 convert arm64 to use the generic handling instead of
> its own implementation.
> 6. Patch 9 adds support for kdump properties to arm32.
> The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> DT properties to crash dump kernel's DTB"[3], which is still valid.
This one can be applied on its own, right?
Rob
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-15 15:25 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-15 15:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
devicetree, linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds generic support for parsing DT properties related
> to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> the "/chosen" node), makes use of it on arm32, and performs a few
> cleanups. It is an evolution of the combination of [1] and [2].
The DT bits look fine to me. How do you expect this to be merged? I'm
happy to take it if arch maintainers can ack it.
>
> The series consists of 6 parts:
> 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> to avoid duplicating elf core header reservation later.
> 2. Patch 2 prepares the visibility of variables used to hold
> information retrieved from the DT properties.
> 3. Patches 3-5 add support to the FDT core for handling the
> properties.
> This can co-exist safely with architecture-specific handling, until
> the latter has been removed.
Looks like patch 5 doesn't have any dependencies with the series?
> 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> riscv.
I thought this should be applied for 5.14?
> 5. Patches 7-8 convert arm64 to use the generic handling instead of
> its own implementation.
> 6. Patch 9 adds support for kdump properties to arm32.
> The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> DT properties to crash dump kernel's DTB"[3], which is still valid.
This one can be applied on its own, right?
Rob
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-15 15:25 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-15 15:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
devicetree, linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds generic support for parsing DT properties related
> to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> the "/chosen" node), makes use of it on arm32, and performs a few
> cleanups. It is an evolution of the combination of [1] and [2].
The DT bits look fine to me. How do you expect this to be merged? I'm
happy to take it if arch maintainers can ack it.
>
> The series consists of 6 parts:
> 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> to avoid duplicating elf core header reservation later.
> 2. Patch 2 prepares the visibility of variables used to hold
> information retrieved from the DT properties.
> 3. Patches 3-5 add support to the FDT core for handling the
> properties.
> This can co-exist safely with architecture-specific handling, until
> the latter has been removed.
Looks like patch 5 doesn't have any dependencies with the series?
> 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> riscv.
I thought this should be applied for 5.14?
> 5. Patches 7-8 convert arm64 to use the generic handling instead of
> its own implementation.
> 6. Patch 9 adds support for kdump properties to arm32.
> The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> DT properties to crash dump kernel's DTB"[3], which is still valid.
This one can be applied on its own, right?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-15 15:25 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-15 15:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
devicetree, linux-arm-kernel, linux-mips, linux-riscv, kexec,
linux-renesas-soc, linux-kernel
On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds generic support for parsing DT properties related
> to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> the "/chosen" node), makes use of it on arm32, and performs a few
> cleanups. It is an evolution of the combination of [1] and [2].
The DT bits look fine to me. How do you expect this to be merged? I'm
happy to take it if arch maintainers can ack it.
>
> The series consists of 6 parts:
> 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> to avoid duplicating elf core header reservation later.
> 2. Patch 2 prepares the visibility of variables used to hold
> information retrieved from the DT properties.
> 3. Patches 3-5 add support to the FDT core for handling the
> properties.
> This can co-exist safely with architecture-specific handling, until
> the latter has been removed.
Looks like patch 5 doesn't have any dependencies with the series?
> 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> riscv.
I thought this should be applied for 5.14?
> 5. Patches 7-8 convert arm64 to use the generic handling instead of
> its own implementation.
> 6. Patch 9 adds support for kdump properties to arm32.
> The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> DT properties to crash dump kernel's DTB"[3], which is still valid.
This one can be applied on its own, right?
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
2021-08-15 15:25 ` Rob Herring
(?)
(?)
@ 2021-08-23 10:13 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:13 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Rob,
On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > This patch series adds generic support for parsing DT properties related
> > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > the "/chosen" node), makes use of it on arm32, and performs a few
> > cleanups. It is an evolution of the combination of [1] and [2].
>
> The DT bits look fine to me. How do you expect this to be merged? I'm
> happy to take it if arch maintainers can ack it.
I had hoped you could take the series...
> > The series consists of 6 parts:
> > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > to avoid duplicating elf core header reservation later.
> > 2. Patch 2 prepares the visibility of variables used to hold
> > information retrieved from the DT properties.
> > 3. Patches 3-5 add support to the FDT core for handling the
> > properties.
> > This can co-exist safely with architecture-specific handling, until
> > the latter has been removed.
>
> Looks like patch 5 doesn't have any dependencies with the series?
Indeed. So you can take it independently.
> > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > riscv.
>
> I thought this should be applied for 5.14?
Me too, but unfortunately that hasn't happened yet...
> > 5. Patches 7-8 convert arm64 to use the generic handling instead of
> > its own implementation.
> > 6. Patch 9 adds support for kdump properties to arm32.
> > The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> > DT properties to crash dump kernel's DTB"[3], which is still valid.
>
> This one can be applied on its own, right?
While that wouldn't break anything (i.e. no regression), it still
wouldn't work if the DT properties are present, and the now-legacy
"mem=" kernel command line parameter is not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 10:13 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:13 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Rob,
On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > This patch series adds generic support for parsing DT properties related
> > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > the "/chosen" node), makes use of it on arm32, and performs a few
> > cleanups. It is an evolution of the combination of [1] and [2].
>
> The DT bits look fine to me. How do you expect this to be merged? I'm
> happy to take it if arch maintainers can ack it.
I had hoped you could take the series...
> > The series consists of 6 parts:
> > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > to avoid duplicating elf core header reservation later.
> > 2. Patch 2 prepares the visibility of variables used to hold
> > information retrieved from the DT properties.
> > 3. Patches 3-5 add support to the FDT core for handling the
> > properties.
> > This can co-exist safely with architecture-specific handling, until
> > the latter has been removed.
>
> Looks like patch 5 doesn't have any dependencies with the series?
Indeed. So you can take it independently.
> > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > riscv.
>
> I thought this should be applied for 5.14?
Me too, but unfortunately that hasn't happened yet...
> > 5. Patches 7-8 convert arm64 to use the generic handling instead of
> > its own implementation.
> > 6. Patch 9 adds support for kdump properties to arm32.
> > The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> > DT properties to crash dump kernel's DTB"[3], which is still valid.
>
> This one can be applied on its own, right?
While that wouldn't break anything (i.e. no regression), it still
wouldn't work if the DT properties are present, and the now-legacy
"mem=" kernel command line parameter is not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 10:13 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:13 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Rob,
On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > This patch series adds generic support for parsing DT properties related
> > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > the "/chosen" node), makes use of it on arm32, and performs a few
> > cleanups. It is an evolution of the combination of [1] and [2].
>
> The DT bits look fine to me. How do you expect this to be merged? I'm
> happy to take it if arch maintainers can ack it.
I had hoped you could take the series...
> > The series consists of 6 parts:
> > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > to avoid duplicating elf core header reservation later.
> > 2. Patch 2 prepares the visibility of variables used to hold
> > information retrieved from the DT properties.
> > 3. Patches 3-5 add support to the FDT core for handling the
> > properties.
> > This can co-exist safely with architecture-specific handling, until
> > the latter has been removed.
>
> Looks like patch 5 doesn't have any dependencies with the series?
Indeed. So you can take it independently.
> > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > riscv.
>
> I thought this should be applied for 5.14?
Me too, but unfortunately that hasn't happened yet...
> > 5. Patches 7-8 convert arm64 to use the generic handling instead of
> > its own implementation.
> > 6. Patch 9 adds support for kdump properties to arm32.
> > The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> > DT properties to crash dump kernel's DTB"[3], which is still valid.
>
> This one can be applied on its own, right?
While that wouldn't break anything (i.e. no regression), it still
wouldn't work if the DT properties are present, and the now-legacy
"mem=" kernel command line parameter is not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 10:13 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-23 10:13 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
Hi Rob,
On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > This patch series adds generic support for parsing DT properties related
> > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > the "/chosen" node), makes use of it on arm32, and performs a few
> > cleanups. It is an evolution of the combination of [1] and [2].
>
> The DT bits look fine to me. How do you expect this to be merged? I'm
> happy to take it if arch maintainers can ack it.
I had hoped you could take the series...
> > The series consists of 6 parts:
> > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > to avoid duplicating elf core header reservation later.
> > 2. Patch 2 prepares the visibility of variables used to hold
> > information retrieved from the DT properties.
> > 3. Patches 3-5 add support to the FDT core for handling the
> > properties.
> > This can co-exist safely with architecture-specific handling, until
> > the latter has been removed.
>
> Looks like patch 5 doesn't have any dependencies with the series?
Indeed. So you can take it independently.
> > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > riscv.
>
> I thought this should be applied for 5.14?
Me too, but unfortunately that hasn't happened yet...
> > 5. Patches 7-8 convert arm64 to use the generic handling instead of
> > its own implementation.
> > 6. Patch 9 adds support for kdump properties to arm32.
> > The corresponding patch for kexec-tools is "[PATCH] arm: kdump: Add
> > DT properties to crash dump kernel's DTB"[3], which is still valid.
>
> This one can be applied on its own, right?
While that wouldn't break anything (i.e. no regression), it still
wouldn't work if the DT properties are present, and the now-legacy
"mem=" kernel command line parameter is not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
2021-08-23 10:13 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-23 14:52 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > This patch series adds generic support for parsing DT properties related
> > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > cleanups. It is an evolution of the combination of [1] and [2].
> >
> > The DT bits look fine to me. How do you expect this to be merged? I'm
> > happy to take it if arch maintainers can ack it.
>
> I had hoped you could take the series...
My current thought is I'll take 2-5, 7 and 8 given that's what I have
acks for and the others can be applied independently.
> > > The series consists of 6 parts:
> > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > to avoid duplicating elf core header reservation later.
> > > 2. Patch 2 prepares the visibility of variables used to hold
> > > information retrieved from the DT properties.
> > > 3. Patches 3-5 add support to the FDT core for handling the
> > > properties.
> > > This can co-exist safely with architecture-specific handling, until
> > > the latter has been removed.
> >
> > Looks like patch 5 doesn't have any dependencies with the series?
>
> Indeed. So you can take it independently.
>
> > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > riscv.
> >
> > I thought this should be applied for 5.14?
>
> Me too, but unfortunately that hasn't happened yet...
Buried in the middle of this series is not going to encourage it to be
picked up as a fix.
Rob
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 14:52 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > This patch series adds generic support for parsing DT properties related
> > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > cleanups. It is an evolution of the combination of [1] and [2].
> >
> > The DT bits look fine to me. How do you expect this to be merged? I'm
> > happy to take it if arch maintainers can ack it.
>
> I had hoped you could take the series...
My current thought is I'll take 2-5, 7 and 8 given that's what I have
acks for and the others can be applied independently.
> > > The series consists of 6 parts:
> > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > to avoid duplicating elf core header reservation later.
> > > 2. Patch 2 prepares the visibility of variables used to hold
> > > information retrieved from the DT properties.
> > > 3. Patches 3-5 add support to the FDT core for handling the
> > > properties.
> > > This can co-exist safely with architecture-specific handling, until
> > > the latter has been removed.
> >
> > Looks like patch 5 doesn't have any dependencies with the series?
>
> Indeed. So you can take it independently.
>
> > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > riscv.
> >
> > I thought this should be applied for 5.14?
>
> Me too, but unfortunately that hasn't happened yet...
Buried in the middle of this series is not going to encourage it to be
picked up as a fix.
Rob
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 14:52 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > This patch series adds generic support for parsing DT properties related
> > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > cleanups. It is an evolution of the combination of [1] and [2].
> >
> > The DT bits look fine to me. How do you expect this to be merged? I'm
> > happy to take it if arch maintainers can ack it.
>
> I had hoped you could take the series...
My current thought is I'll take 2-5, 7 and 8 given that's what I have
acks for and the others can be applied independently.
> > > The series consists of 6 parts:
> > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > to avoid duplicating elf core header reservation later.
> > > 2. Patch 2 prepares the visibility of variables used to hold
> > > information retrieved from the DT properties.
> > > 3. Patches 3-5 add support to the FDT core for handling the
> > > properties.
> > > This can co-exist safely with architecture-specific handling, until
> > > the latter has been removed.
> >
> > Looks like patch 5 doesn't have any dependencies with the series?
>
> Indeed. So you can take it independently.
>
> > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > riscv.
> >
> > I thought this should be applied for 5.14?
>
> Me too, but unfortunately that hasn't happened yet...
Buried in the middle of this series is not going to encourage it to be
picked up as a fix.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-23 14:52 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-23 14:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > This patch series adds generic support for parsing DT properties related
> > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > cleanups. It is an evolution of the combination of [1] and [2].
> >
> > The DT bits look fine to me. How do you expect this to be merged? I'm
> > happy to take it if arch maintainers can ack it.
>
> I had hoped you could take the series...
My current thought is I'll take 2-5, 7 and 8 given that's what I have
acks for and the others can be applied independently.
> > > The series consists of 6 parts:
> > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > to avoid duplicating elf core header reservation later.
> > > 2. Patch 2 prepares the visibility of variables used to hold
> > > information retrieved from the DT properties.
> > > 3. Patches 3-5 add support to the FDT core for handling the
> > > properties.
> > > This can co-exist safely with architecture-specific handling, until
> > > the latter has been removed.
> >
> > Looks like patch 5 doesn't have any dependencies with the series?
>
> Indeed. So you can take it independently.
>
> > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > riscv.
> >
> > I thought this should be applied for 5.14?
>
> Me too, but unfortunately that hasn't happened yet...
Buried in the middle of this series is not going to encourage it to be
picked up as a fix.
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
2021-08-23 14:52 ` Rob Herring
(?)
(?)
@ 2021-08-24 11:55 ` Geert Uytterhoeven
-1 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-24 11:55 UTC (permalink / raw)
To: Rob Herring, Russell King
Cc: Nicolas Pitre, Ard Biesheuvel, Linus Walleij, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Nick Kossifidis, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Frank Rowand, Dave Young, Baoquan He,
Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > This patch series adds generic support for parsing DT properties related
> > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > cleanups. It is an evolution of the combination of [1] and [2].
> > >
> > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > happy to take it if arch maintainers can ack it.
> >
> > I had hoped you could take the series...
>
> My current thought is I'll take 2-5, 7 and 8 given that's what I have
> acks for and the others can be applied independently.
Note that Palmer did ack patch 6, so you can include it.
Russell: any thoughts about patch 9?
Thanks!
> > > > The series consists of 6 parts:
> > > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > > to avoid duplicating elf core header reservation later.
> > > > 2. Patch 2 prepares the visibility of variables used to hold
> > > > information retrieved from the DT properties.
> > > > 3. Patches 3-5 add support to the FDT core for handling the
> > > > properties.
> > > > This can co-exist safely with architecture-specific handling, until
> > > > the latter has been removed.
> > >
> > > Looks like patch 5 doesn't have any dependencies with the series?
> >
> > Indeed. So you can take it independently.
> >
> > > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > > riscv.
> > >
> > > I thought this should be applied for 5.14?
> >
> > Me too, but unfortunately that hasn't happened yet...
>
> Buried in the middle of this series is not going to encourage it to be
> picked up as a fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 11:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-24 11:55 UTC (permalink / raw)
To: Rob Herring, Russell King
Cc: Nicolas Pitre, Ard Biesheuvel, Linus Walleij, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Nick Kossifidis, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Frank Rowand, Dave Young, Baoquan He,
Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > This patch series adds generic support for parsing DT properties related
> > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > cleanups. It is an evolution of the combination of [1] and [2].
> > >
> > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > happy to take it if arch maintainers can ack it.
> >
> > I had hoped you could take the series...
>
> My current thought is I'll take 2-5, 7 and 8 given that's what I have
> acks for and the others can be applied independently.
Note that Palmer did ack patch 6, so you can include it.
Russell: any thoughts about patch 9?
Thanks!
> > > > The series consists of 6 parts:
> > > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > > to avoid duplicating elf core header reservation later.
> > > > 2. Patch 2 prepares the visibility of variables used to hold
> > > > information retrieved from the DT properties.
> > > > 3. Patches 3-5 add support to the FDT core for handling the
> > > > properties.
> > > > This can co-exist safely with architecture-specific handling, until
> > > > the latter has been removed.
> > >
> > > Looks like patch 5 doesn't have any dependencies with the series?
> >
> > Indeed. So you can take it independently.
> >
> > > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > > riscv.
> > >
> > > I thought this should be applied for 5.14?
> >
> > Me too, but unfortunately that hasn't happened yet...
>
> Buried in the middle of this series is not going to encourage it to be
> picked up as a fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 11:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-24 11:55 UTC (permalink / raw)
To: Rob Herring, Russell King
Cc: Nicolas Pitre, Ard Biesheuvel, Linus Walleij, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Nick Kossifidis, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Frank Rowand, Dave Young, Baoquan He,
Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > This patch series adds generic support for parsing DT properties related
> > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > cleanups. It is an evolution of the combination of [1] and [2].
> > >
> > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > happy to take it if arch maintainers can ack it.
> >
> > I had hoped you could take the series...
>
> My current thought is I'll take 2-5, 7 and 8 given that's what I have
> acks for and the others can be applied independently.
Note that Palmer did ack patch 6, so you can include it.
Russell: any thoughts about patch 9?
Thanks!
> > > > The series consists of 6 parts:
> > > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > > to avoid duplicating elf core header reservation later.
> > > > 2. Patch 2 prepares the visibility of variables used to hold
> > > > information retrieved from the DT properties.
> > > > 3. Patches 3-5 add support to the FDT core for handling the
> > > > properties.
> > > > This can co-exist safely with architecture-specific handling, until
> > > > the latter has been removed.
> > >
> > > Looks like patch 5 doesn't have any dependencies with the series?
> >
> > Indeed. So you can take it independently.
> >
> > > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > > riscv.
> > >
> > > I thought this should be applied for 5.14?
> >
> > Me too, but unfortunately that hasn't happened yet...
>
> Buried in the middle of this series is not going to encourage it to be
> picked up as a fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 11:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 95+ messages in thread
From: Geert Uytterhoeven @ 2021-08-24 11:55 UTC (permalink / raw)
To: Rob Herring, Russell King
Cc: Nicolas Pitre, Ard Biesheuvel, Linus Walleij, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Nick Kossifidis, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Frank Rowand, Dave Young, Baoquan He,
Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > This patch series adds generic support for parsing DT properties related
> > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > cleanups. It is an evolution of the combination of [1] and [2].
> > >
> > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > happy to take it if arch maintainers can ack it.
> >
> > I had hoped you could take the series...
>
> My current thought is I'll take 2-5, 7 and 8 given that's what I have
> acks for and the others can be applied independently.
Note that Palmer did ack patch 6, so you can include it.
Russell: any thoughts about patch 9?
Thanks!
> > > > The series consists of 6 parts:
> > > > 1. Patch 1 prepares architecture-specific code (needed for MIPS only)
> > > > to avoid duplicating elf core header reservation later.
> > > > 2. Patch 2 prepares the visibility of variables used to hold
> > > > information retrieved from the DT properties.
> > > > 3. Patches 3-5 add support to the FDT core for handling the
> > > > properties.
> > > > This can co-exist safely with architecture-specific handling, until
> > > > the latter has been removed.
> > >
> > > Looks like patch 5 doesn't have any dependencies with the series?
> >
> > Indeed. So you can take it independently.
> >
> > > > 4. Patch 6 removes the non-standard handling of "linux,elfcorehdr" on
> > > > riscv.
> > >
> > > I thought this should be applied for 5.14?
> >
> > Me too, but unfortunately that hasn't happened yet...
>
> Buried in the middle of this series is not going to encourage it to be
> picked up as a fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
2021-08-24 11:55 ` Geert Uytterhoeven
(?)
(?)
@ 2021-08-24 22:43 ` Rob Herring
-1 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-24 22:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Tue, Aug 24, 2021 at 6:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > > This patch series adds generic support for parsing DT properties related
> > > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > > cleanups. It is an evolution of the combination of [1] and [2].
> > > >
> > > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > > happy to take it if arch maintainers can ack it.
> > >
> > > I had hoped you could take the series...
> >
> > My current thought is I'll take 2-5, 7 and 8 given that's what I have
> > acks for and the others can be applied independently.
>
> Note that Palmer did ack patch 6, so you can include it.
Right, but Palmer should have taken it if it's for 5.14.
Anyways, I've now applied patches 2-8. If we want to improve the
handling over what arm64 code did as discussed, I think that's a
separate patch anyways.
Rob
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 22:43 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-24 22:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Tue, Aug 24, 2021 at 6:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > > This patch series adds generic support for parsing DT properties related
> > > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > > cleanups. It is an evolution of the combination of [1] and [2].
> > > >
> > > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > > happy to take it if arch maintainers can ack it.
> > >
> > > I had hoped you could take the series...
> >
> > My current thought is I'll take 2-5, 7 and 8 given that's what I have
> > acks for and the others can be applied independently.
>
> Note that Palmer did ack patch 6, so you can include it.
Right, but Palmer should have taken it if it's for 5.14.
Anyways, I've now applied patches 2-8. If we want to improve the
handling over what arm64 code did as discussed, I think that's a
separate patch anyways.
Rob
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 22:43 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-24 22:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Tue, Aug 24, 2021 at 6:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > > This patch series adds generic support for parsing DT properties related
> > > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > > cleanups. It is an evolution of the combination of [1] and [2].
> > > >
> > > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > > happy to take it if arch maintainers can ack it.
> > >
> > > I had hoped you could take the series...
> >
> > My current thought is I'll take 2-5, 7 and 8 given that's what I have
> > acks for and the others can be applied independently.
>
> Note that Palmer did ack patch 6, so you can include it.
Right, but Palmer should have taken it if it's for 5.14.
Anyways, I've now applied patches 2-8. If we want to improve the
handling over what arm64 code did as discussed, I think that's a
separate patch anyways.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH v5 0/9] Add generic support for kdump DT properties
@ 2021-08-24 22:43 ` Rob Herring
0 siblings, 0 replies; 95+ messages in thread
From: Rob Herring @ 2021-08-24 22:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Nicolas Pitre, Ard Biesheuvel, Linus Walleij,
Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Nick Kossifidis, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Frank Rowand, Dave Young, Baoquan He, Vivek Goyal, Mike Rapoport,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, open list:BROADCOM NVRAM DRIVER, linux-riscv, kexec,
Linux-Renesas, Linux Kernel Mailing List
On Tue, Aug 24, 2021 at 6:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Mon, Aug 23, 2021 at 4:52 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Aug 23, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Sun, Aug 15, 2021 at 5:25 PM Rob Herring <robh@kernel.org> wrote:
> > > > On Wed, Aug 11, 2021 at 10:50:58AM +0200, Geert Uytterhoeven wrote:
> > > > > This patch series adds generic support for parsing DT properties related
> > > > > to crash dump kernels ("linux,elfcorehdr" and "linux,elfcorehdr" under
> > > > > the "/chosen" node), makes use of it on arm32, and performs a few
> > > > > cleanups. It is an evolution of the combination of [1] and [2].
> > > >
> > > > The DT bits look fine to me. How do you expect this to be merged? I'm
> > > > happy to take it if arch maintainers can ack it.
> > >
> > > I had hoped you could take the series...
> >
> > My current thought is I'll take 2-5, 7 and 8 given that's what I have
> > acks for and the others can be applied independently.
>
> Note that Palmer did ack patch 6, so you can include it.
Right, but Palmer should have taken it if it's for 5.14.
Anyways, I've now applied patches 2-8. If we want to improve the
handling over what arm64 code did as discussed, I think that's a
separate patch anyways.
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 95+ messages in thread