All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Simon Horman" <horms@verge.net.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Lukasz Stelmach" <l.stelmach@samsung.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"open list:MEDIA DRIVERS FOR RENESAS - FCP"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kexec@lists.infradead.org
Subject: Re: [PATCH v3] ARM: Parse kdump DT properties
Date: Tue, 15 Jun 2021 16:51:33 +0200	[thread overview]
Message-ID: <CAMuHMdUdB-Ux9UpeaN3H0_UWDH7_9r3s72ZP01++XzOvrwavHg@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqL3NRDpzPbOxwvP6N+K76UXmrxs=e9-1rK-PbAKUx7f6w@mail.gmail.com>

Hi Rob,

On Mon, Mar 22, 2021 at 5:59 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven
> <geert+renesas@glider.be> 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 <geert+renesas@glider.be>

> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -4,6 +4,7 @@
> >   *
> >   *  Copyright (C) 1995-2005 Russell King
> >   */
> > +#include <linux/crash_dump.h>
> >  #include <linux/kernel.h>
> >  #include <linux/errno.h>
> >  #include <linux/swap.h>
> > @@ -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, &reg);
> > +       usablemem->size = dt_mem_next_cell(dt_root_size_cells, &reg);
> > +       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, &reg);
> > +
> > +       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

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Simon Horman" <horms@verge.net.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Lukasz Stelmach" <l.stelmach@samsung.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"open list:MEDIA DRIVERS FOR RENESAS - FCP"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kexec@lists.infradead.org
Subject: Re: [PATCH v3] ARM: Parse kdump DT properties
Date: Tue, 15 Jun 2021 16:51:33 +0200	[thread overview]
Message-ID: <CAMuHMdUdB-Ux9UpeaN3H0_UWDH7_9r3s72ZP01++XzOvrwavHg@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqL3NRDpzPbOxwvP6N+K76UXmrxs=e9-1rK-PbAKUx7f6w@mail.gmail.com>

Hi Rob,

On Mon, Mar 22, 2021 at 5:59 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven
> <geert+renesas@glider.be> 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 <geert+renesas@glider.be>

> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -4,6 +4,7 @@
> >   *
> >   *  Copyright (C) 1995-2005 Russell King
> >   */
> > +#include <linux/crash_dump.h>
> >  #include <linux/kernel.h>
> >  #include <linux/errno.h>
> >  #include <linux/swap.h>
> > @@ -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, &reg);
> > +       usablemem->size = dt_mem_next_cell(dt_root_size_cells, &reg);
> > +       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, &reg);
> > +
> > +       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

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Simon Horman" <horms@verge.net.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Lukasz Stelmach" <l.stelmach@samsung.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"open list:MEDIA DRIVERS FOR RENESAS - FCP"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kexec@lists.infradead.org
Subject: Re: [PATCH v3] ARM: Parse kdump DT properties
Date: Tue, 15 Jun 2021 16:51:33 +0200	[thread overview]
Message-ID: <CAMuHMdUdB-Ux9UpeaN3H0_UWDH7_9r3s72ZP01++XzOvrwavHg@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqL3NRDpzPbOxwvP6N+K76UXmrxs=e9-1rK-PbAKUx7f6w@mail.gmail.com>

Hi Rob,

On Mon, Mar 22, 2021 at 5:59 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven
> <geert+renesas@glider.be> 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 <geert+renesas@glider.be>

> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -4,6 +4,7 @@
> >   *
> >   *  Copyright (C) 1995-2005 Russell King
> >   */
> > +#include <linux/crash_dump.h>
> >  #include <linux/kernel.h>
> >  #include <linux/errno.h>
> >  #include <linux/swap.h>
> > @@ -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, &reg);
> > +       usablemem->size = dt_mem_next_cell(dt_root_size_cells, &reg);
> > +       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, &reg);
> > +
> > +       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

  reply	other threads:[~2021-06-15 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 11:31 [PATCH v3] ARM: Parse kdump DT properties Geert Uytterhoeven
2021-03-17 11:31 ` Geert Uytterhoeven
2021-03-17 11:31 ` Geert Uytterhoeven
2021-03-22 16:58 ` Rob Herring
2021-03-22 16:58   ` Rob Herring
2021-03-22 16:58   ` Rob Herring
2021-06-15 14:51   ` Geert Uytterhoeven [this message]
2021-06-15 14:51     ` Geert Uytterhoeven
2021-06-15 14:51     ` Geert Uytterhoeven
2021-05-06 12:43 ` Linus Walleij
2021-05-06 12:43   ` Linus Walleij
2021-05-06 12:43   ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdUdB-Ux9UpeaN3H0_UWDH7_9r3s72ZP01++XzOvrwavHg@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=l.stelmach@samsung.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=nico@fluxnic.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.