From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3739C49361 for ; Tue, 15 Jun 2021 14:51:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B11A66141D for ; Tue, 15 Jun 2021 14:51:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231303AbhFOOxu (ORCPT ); Tue, 15 Jun 2021 10:53:50 -0400 Received: from mail-ua1-f46.google.com ([209.85.222.46]:39629 "EHLO mail-ua1-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230208AbhFOOxt (ORCPT ); Tue, 15 Jun 2021 10:53:49 -0400 Received: by mail-ua1-f46.google.com with SMTP id c10so6771849uan.6; Tue, 15 Jun 2021 07:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VRuDeOUfZ6B0u10ffnqTPMqKC8c9Vta/YzdAIyumZr4=; b=nGB42WUcJGGEgEnVnicySd1EuOPCyqkDJV8+S+d92WWQ7l7SiNuPBP7N9xhEPEEmmX /vHQMglWoQGDe2VhugJ48FZJhoi59uVo9ORF84Bxo89ottxpehC8q6SgWI2Vv5JU2AfY G+IItPP71cFmZgaiyw3QRnq50elnJr2TYjYHUctkRdBM3GSFY2Q7ASauNCgOwx1AlKFa otO3LHnUctOVGUn5YRsVtIjaISJ0pJ8yyeIQOB90KnOAp/S+PprOXEW0HsQ3729tLEva yofPimzYDKXZhrZCN19lJ2CIkhpVkPH2n16I87w43W12n9i3NMokeT/7wRwQzGAHfluu qQJw== X-Gm-Message-State: AOAM533ageoz5zc/SqzIhKtHkHb4nWdAhnMvSCKF/1yq9WGpx0rr6P32 njQGmpMyYy9BkEHXMWrwup1/UboIRIafWKg6NEU= X-Google-Smtp-Source: ABdhPJyMlEwcIPhRuOKgllmjsxF0JpzWIGKXY3MQGgAhU31dK3Mc0jsRrYJl2Yc0tBi6Y8M6CDuHe5zvmJbjZnwnuDg= X-Received: by 2002:ab0:63d9:: with SMTP id i25mr18418485uap.106.1623768704802; Tue, 15 Jun 2021 07:51:44 -0700 (PDT) MIME-Version: 1.0 References: <20210317113130.2554368-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 15 Jun 2021 16:51:33 +0200 Message-ID: Subject: Re: [PATCH v3] ARM: Parse kdump DT properties To: Rob Herring Cc: Russell King , Ard Biesheuvel , Nicolas Pitre , Marek Szyprowski , Dmitry Osipenko , Linus Walleij , Simon Horman , Arnd Bergmann , Stephen Boyd , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Lukasz Stelmach , linux-arm-kernel , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , "linux-kernel@vger.kernel.org" , kexec@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On Mon, Mar 22, 2021 at 5:59 PM Rob Herring wrote: > On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven > wrote: > > Parse the following DT properties in the crash dump kernel, to provide a > > modern interface between kexec and the crash dump kernel: > > - linux,elfcorehdr: ELF core header segment, similar to the > > "elfcorehdr=" kernel parameter. > > - linux,usable-memory-range: Usable memory reserved for the crash dump > > kernel. > > This 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, and > > the "elfcorehdr=" and "mem=" kernel parameters are still parsed. > > > > Loosely based on the ARM64 version by Akashi Takahiro. > > > > Signed-off-by: Geert Uytterhoeven > > --- a/arch/arm/mm/init.c > > +++ b/arch/arm/mm/init.c > > @@ -4,6 +4,7 @@ > > * > > * Copyright (C) 1995-2005 Russell King > > */ > > +#include > > #include > > #include > > #include > > @@ -210,8 +211,95 @@ void check_cpu_icache_size(int cpuid) > > } > > #endif > > > > +#ifdef CONFIG_OF_EARLY_FLATTREE > > +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; > > We have libfdt now, just get the '/chosen' node rather than using > of_scan_flat_dt(). > > > > + > > + 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); > > We should be able to do this in the DT core code. It doesn't matter > that these properties are arm* only. Other arches won't find the > properties. > > Also, note that there is now a drivers/of/kexec.c (in -next) though > not sure if all this would go there or stay in fdt.c with the rest of > the memory parsing. It's gonna be the latter, as that file handles the FDT during early kernel startup, for both normal and kdump kernels. Despite the name, drivers/of/kexec.c is not for kexec, but for kexec_file. This is the "new" fancy syscall that prepares the DTB for the new kernel itself, unlike the classic kexec syscall, where userspace is responsible for preparing the DTB for the new kernel. > > +#if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_OF_EARLY_FLATTREE) > > +static int __init early_init_dt_scan_elfcorehdr(unsigned long node, > > + const char *uname, int depth, void *data) > > Same comments as above. This one can indeed be handled easily by drivers/of/fdt.c. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8433C48BDF for ; Tue, 15 Jun 2021 17:55:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 945A56115B for ; Tue, 15 Jun 2021 17:55:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 945A56115B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2KBtW1R3g/NbhFPKVp12Ao49Nkq5/05Ea8FZQG7IHhA=; b=FDo8TLX1aoqSTG o8t3Xq0m6x8x4o5GsVA6RBo+ZBFgILJNaanIfd4Re6NY+ycpOBpEemRrh2+5r1Rx9/4bfKLnROAnX QpVvDkp6WnIKZytMCvuCQQ6DMgoVeS2MgaJgrIpxNK7TFv90U99b60hvLWyo+oUCrvs20cCAbOyUV M2GHABNRInbkYEJneQ1eQdnOOOQp9ZGWz/ImVIhRrxhn6eKRTCZQf0iphNxsx3nRhNpTVKM/vsJ76 rJh1hIihfMSQn5bMLNTiYHuI7oLMLNHt4lyn7330ytoVZa3krsUv4v5A71QhTtA/h68Hv605q/RbS bBzIwjwchsPsNhaxR7pA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltDFr-001tX7-Ai; Tue, 15 Jun 2021 17:53:39 +0000 Received: from mail-ua1-f47.google.com ([209.85.222.47]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltAPs-000ifM-U6; Tue, 15 Jun 2021 14:51:50 +0000 Received: by mail-ua1-f47.google.com with SMTP id p1so6743452uam.13; Tue, 15 Jun 2021 07:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VRuDeOUfZ6B0u10ffnqTPMqKC8c9Vta/YzdAIyumZr4=; b=SdBc0PJsi53WC3m0btE6EpI8Dck7JwTiZPDefAhqqnH0DEpxa3ZafSOLTd+J7zbnWT mAUmJNsZGFpy51YvkupFSPznq7DyvssHlT/ttFjhwnbEssGwiEnNHVDIjlurptqAWOu9 NlxgRhazI7hK3RLsbvH8UjE8IIATTpwDSIwrwuvqy7cI0iFFQ/DoNiy+A7sbIqr2LKpX FCQXlGm+JEZGCzgBBX9tSSkcz9p0XIB7aZqgk/MUkIwlrbcaBGpWfQZpbwFB33058D8y 7yYHrHxVHhQuYsveaoxDnALgmvlw+iAQgMQ+0d6sHzmruDyKtU0rR4JmqyjKlEb6cR4U ojcw== X-Gm-Message-State: AOAM531zOe4k6SI0JjwC5xtJXUyLo3lSoMgvJ3Gxp2JUcHZLujxZq44C ikx6TzHJxna4o68PGa+0RNi77gL0mLf0hAnSwHw= X-Google-Smtp-Source: ABdhPJyMlEwcIPhRuOKgllmjsxF0JpzWIGKXY3MQGgAhU31dK3Mc0jsRrYJl2Yc0tBi6Y8M6CDuHe5zvmJbjZnwnuDg= X-Received: by 2002:ab0:63d9:: with SMTP id i25mr18418485uap.106.1623768704802; Tue, 15 Jun 2021 07:51:44 -0700 (PDT) MIME-Version: 1.0 References: <20210317113130.2554368-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 15 Jun 2021 16:51:33 +0200 Message-ID: Subject: Re: [PATCH v3] ARM: Parse kdump DT properties To: Rob Herring Cc: Russell King , Ard Biesheuvel , Nicolas Pitre , Marek Szyprowski , Dmitry Osipenko , Linus Walleij , Simon Horman , Arnd Bergmann , Stephen Boyd , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Lukasz Stelmach , linux-arm-kernel , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , "linux-kernel@vger.kernel.org" , kexec@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210615_075149_035772_AAA94B06 X-CRM114-Status: GOOD ( 40.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Rob, On Mon, Mar 22, 2021 at 5:59 PM Rob Herring wrote: > On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven > wrote: > > Parse the following DT properties in the crash dump kernel, to provide a > > modern interface between kexec and the crash dump kernel: > > - linux,elfcorehdr: ELF core header segment, similar to the > > "elfcorehdr=" kernel parameter. > > - linux,usable-memory-range: Usable memory reserved for the crash dump > > kernel. > > This 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, and > > the "elfcorehdr=" and "mem=" kernel parameters are still parsed. > > > > Loosely based on the ARM64 version by Akashi Takahiro. > > > > Signed-off-by: Geert Uytterhoeven > > --- a/arch/arm/mm/init.c > > +++ b/arch/arm/mm/init.c > > @@ -4,6 +4,7 @@ > > * > > * Copyright (C) 1995-2005 Russell King > > */ > > +#include > > #include > > #include > > #include > > @@ -210,8 +211,95 @@ void check_cpu_icache_size(int cpuid) > > } > > #endif > > > > +#ifdef CONFIG_OF_EARLY_FLATTREE > > +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; > > We have libfdt now, just get the '/chosen' node rather than using > of_scan_flat_dt(). > > > > + > > + 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); > > We should be able to do this in the DT core code. It doesn't matter > that these properties are arm* only. Other arches won't find the > properties. > > Also, note that there is now a drivers/of/kexec.c (in -next) though > not sure if all this would go there or stay in fdt.c with the rest of > the memory parsing. It's gonna be the latter, as that file handles the FDT during early kernel startup, for both normal and kdump kernels. Despite the name, drivers/of/kexec.c is not for kexec, but for kexec_file. This is the "new" fancy syscall that prepares the DTB for the new kernel itself, unlike the classic kexec syscall, where userspace is responsible for preparing the DTB for the new kernel. > > +#if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_OF_EARLY_FLATTREE) > > +static int __init early_init_dt_scan_elfcorehdr(unsigned long node, > > + const char *uname, int depth, void *data) > > Same comments as above. This one can indeed be handled easily by drivers/of/fdt.c. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: MIME-Version: 1.0 References: <20210317113130.2554368-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 15 Jun 2021 16:51:33 +0200 Message-ID: Subject: Re: [PATCH v3] ARM: Parse kdump DT properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Rob Herring Cc: Russell King , Ard Biesheuvel , Nicolas Pitre , Marek Szyprowski , Dmitry Osipenko , Linus Walleij , Simon Horman , Arnd Bergmann , Stephen Boyd , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Lukasz Stelmach , linux-arm-kernel , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , "linux-kernel@vger.kernel.org" , kexec@lists.infradead.org Hi Rob, On Mon, Mar 22, 2021 at 5:59 PM Rob Herring wrote: > On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven > wrote: > > Parse the following DT properties in the crash dump kernel, to provide a > > modern interface between kexec and the crash dump kernel: > > - linux,elfcorehdr: ELF core header segment, similar to the > > "elfcorehdr=" kernel parameter. > > - linux,usable-memory-range: Usable memory reserved for the crash dump > > kernel. > > This 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, and > > the "elfcorehdr=" and "mem=" kernel parameters are still parsed. > > > > Loosely based on the ARM64 version by Akashi Takahiro. > > > > Signed-off-by: Geert Uytterhoeven > > --- a/arch/arm/mm/init.c > > +++ b/arch/arm/mm/init.c > > @@ -4,6 +4,7 @@ > > * > > * Copyright (C) 1995-2005 Russell King > > */ > > +#include > > #include > > #include > > #include > > @@ -210,8 +211,95 @@ void check_cpu_icache_size(int cpuid) > > } > > #endif > > > > +#ifdef CONFIG_OF_EARLY_FLATTREE > > +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; > > We have libfdt now, just get the '/chosen' node rather than using > of_scan_flat_dt(). > > > > + > > + 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); > > We should be able to do this in the DT core code. It doesn't matter > that these properties are arm* only. Other arches won't find the > properties. > > Also, note that there is now a drivers/of/kexec.c (in -next) though > not sure if all this would go there or stay in fdt.c with the rest of > the memory parsing. It's gonna be the latter, as that file handles the FDT during early kernel startup, for both normal and kdump kernels. Despite the name, drivers/of/kexec.c is not for kexec, but for kexec_file. This is the "new" fancy syscall that prepares the DTB for the new kernel itself, unlike the classic kexec syscall, where userspace is responsible for preparing the DTB for the new kernel. > > +#if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_OF_EARLY_FLATTREE) > > +static int __init early_init_dt_scan_elfcorehdr(unsigned long node, > > + const char *uname, int depth, void *data) > > Same comments as above. This one can indeed be handled easily by drivers/of/fdt.c. 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