| Message ID | cover.1628670468.git.geert+renesas@glider.be (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add generic support for kdump DT properties | expand |
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
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
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
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
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
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(-)