Messages in this thread | | | Date | Tue, 20 Jul 2021 08:43:43 -0700 (PDT) | Subject | Re: [PATCH v4 06/10] riscv: Remove non-standard linux,elfcorehdr handling | From | Palmer Dabbelt <> |
| |
On Wed, 14 Jul 2021 05:50:16 PDT (-0700), geert+renesas@glider.be wrote: > 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> > --- > 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 269fc648ef3d84b2..4aa4b6a034086df6 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -829,26 +829,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();
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
LMK if you wanted me to take this series, otherwise I'm going to assume it's going in via some other tree.
| |