From: Mike Rapoport <rppt@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <robh@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>,
Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Frank Rowand <frowand.list@gmail.com>,
Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
kexec@lists.infradead.org, Linux MM <linux-mm@kvack.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation
Date: Tue, 20 Jul 2021 08:41:16 +0300 [thread overview]
Message-ID: <YPZh/IawtmwaYccQ@kernel.org> (raw)
In-Reply-To: <CAMuHMdXfFhzm48U2Hvjz8yrjPsQbagW4aC_L-QE_Q6yx1Lo=tA@mail.gmail.com>
Hi Geert,
On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:
> > > > Add two global variables (cap_mem_addr and cap_mem_size) for storing a
> > > > base address and size, describing a limited region in which memory may
> > > > be considered available for use by the kernel. If enabled, memory
> > > > outside of this range is not available for use.
> > > >
> > > > These variables can by filled by firmware-specific code, and used in
> > > > calls to memblock_cap_memory_range() by architecture-specific code.
> > > > An example user is the parser of the "linux,usable-memory-range"
> > > > property in the DT "/chosen" node.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > This is similar to how the initial ramdisk (phys_initrd_{start,size})
> > > > and ELF core headers (elfcorehdr_{addr,size})) are handled.
> > > >
> > > > Does there exist a suitable place in the common memblock code to call
> > > > "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this
> > > > have to be done in architecture-specific code?
> > >
> > > Can't you just call it from early_init_dt_scan_usablemem? If the
> > > property is present, you want to call it. If the property is not
> > > present, nothing happens.
>
> I will have a look...
>
> > For memblock_cap_memory_range() to work properly it should be called after
> > memory is detected and added to memblock with memblock_add[_node]()
> >
> > I'm not huge fan of adding more globals to memblock so if such ordering can
> > be implemented on the DT side it would be great.
>
> Me neither ;-)
>
> > I don't see a way to actually enforce this ordering, so maybe we'd want to
> > add warning in memblock_cap_memory_range() if memblock.memory is empty.
>
> "linux,usable-memory-range" is optional, and typically used only in
> crashdump kernels, so it would be a bad idea to add such a warning.
If I remember correctly, memblock_cap_memory_range() was added to support
"linux,usable-memory-range" for crasdump kernels on arm64 and if it would
be called before memory is registered we may silently corrupt the memory
because the crash kernel will see all the memory as available.
So while WARN() maybe too much a pr_warn() seems to me quite appropriate.
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <robh@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>,
Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Frank Rowand <frowand.list@gmail.com>,
Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
kexec@lists.infradead.org, Linux MM <linux-mm@kvack.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation
Date: Tue, 20 Jul 2021 08:41:16 +0300 [thread overview]
Message-ID: <YPZh/IawtmwaYccQ@kernel.org> (raw)
In-Reply-To: <CAMuHMdXfFhzm48U2Hvjz8yrjPsQbagW4aC_L-QE_Q6yx1Lo=tA@mail.gmail.com>
Hi Geert,
On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:
> > > > Add two global variables (cap_mem_addr and cap_mem_size) for storing a
> > > > base address and size, describing a limited region in which memory may
> > > > be considered available for use by the kernel. If enabled, memory
> > > > outside of this range is not available for use.
> > > >
> > > > These variables can by filled by firmware-specific code, and used in
> > > > calls to memblock_cap_memory_range() by architecture-specific code.
> > > > An example user is the parser of the "linux,usable-memory-range"
> > > > property in the DT "/chosen" node.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > This is similar to how the initial ramdisk (phys_initrd_{start,size})
> > > > and ELF core headers (elfcorehdr_{addr,size})) are handled.
> > > >
> > > > Does there exist a suitable place in the common memblock code to call
> > > > "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this
> > > > have to be done in architecture-specific code?
> > >
> > > Can't you just call it from early_init_dt_scan_usablemem? If the
> > > property is present, you want to call it. If the property is not
> > > present, nothing happens.
>
> I will have a look...
>
> > For memblock_cap_memory_range() to work properly it should be called after
> > memory is detected and added to memblock with memblock_add[_node]()
> >
> > I'm not huge fan of adding more globals to memblock so if such ordering can
> > be implemented on the DT side it would be great.
>
> Me neither ;-)
>
> > I don't see a way to actually enforce this ordering, so maybe we'd want to
> > add warning in memblock_cap_memory_range() if memblock.memory is empty.
>
> "linux,usable-memory-range" is optional, and typically used only in
> crashdump kernels, so it would be a bad idea to add such a warning.
If I remember correctly, memblock_cap_memory_range() was added to support
"linux,usable-memory-range" for crasdump kernels on arm64 and if it would
be called before memory is registered we may silently corrupt the memory
because the crash kernel will see all the memory as available.
So while WARN() maybe too much a pr_warn() seems to me quite appropriate.
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <robh@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>,
Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Frank Rowand <frowand.list@gmail.com>,
Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
kexec@lists.infradead.org, Linux MM <linux-mm@kvack.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation
Date: Tue, 20 Jul 2021 08:41:16 +0300 [thread overview]
Message-ID: <YPZh/IawtmwaYccQ@kernel.org> (raw)
In-Reply-To: <CAMuHMdXfFhzm48U2Hvjz8yrjPsQbagW4aC_L-QE_Q6yx1Lo=tA@mail.gmail.com>
Hi Geert,
On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:
> > > > Add two global variables (cap_mem_addr and cap_mem_size) for storing a
> > > > base address and size, describing a limited region in which memory may
> > > > be considered available for use by the kernel. If enabled, memory
> > > > outside of this range is not available for use.
> > > >
> > > > These variables can by filled by firmware-specific code, and used in
> > > > calls to memblock_cap_memory_range() by architecture-specific code.
> > > > An example user is the parser of the "linux,usable-memory-range"
> > > > property in the DT "/chosen" node.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > This is similar to how the initial ramdisk (phys_initrd_{start,size})
> > > > and ELF core headers (elfcorehdr_{addr,size})) are handled.
> > > >
> > > > Does there exist a suitable place in the common memblock code to call
> > > > "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this
> > > > have to be done in architecture-specific code?
> > >
> > > Can't you just call it from early_init_dt_scan_usablemem? If the
> > > property is present, you want to call it. If the property is not
> > > present, nothing happens.
>
> I will have a look...
>
> > For memblock_cap_memory_range() to work properly it should be called after
> > memory is detected and added to memblock with memblock_add[_node]()
> >
> > I'm not huge fan of adding more globals to memblock so if such ordering can
> > be implemented on the DT side it would be great.
>
> Me neither ;-)
>
> > I don't see a way to actually enforce this ordering, so maybe we'd want to
> > add warning in memblock_cap_memory_range() if memblock.memory is empty.
>
> "linux,usable-memory-range" is optional, and typically used only in
> crashdump kernels, so it would be a bad idea to add such a warning.
If I remember correctly, memblock_cap_memory_range() was added to support
"linux,usable-memory-range" for crasdump kernels on arm64 and if it would
be called before memory is registered we may silently corrupt the memory
because the crash kernel will see all the memory as available.
So while WARN() maybe too much a pr_warn() seems to me quite appropriate.
--
Sincerely yours,
Mike.
_______________________________________________
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: Mike Rapoport <rppt@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <robh@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>,
Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Frank Rowand <frowand.list@gmail.com>,
Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
kexec@lists.infradead.org, Linux MM <linux-mm@kvack.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation
Date: Tue, 20 Jul 2021 08:41:16 +0300 [thread overview]
Message-ID: <YPZh/IawtmwaYccQ@kernel.org> (raw)
In-Reply-To: <CAMuHMdXfFhzm48U2Hvjz8yrjPsQbagW4aC_L-QE_Q6yx1Lo=tA@mail.gmail.com>
Hi Geert,
On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote:
> > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:
> > > > Add two global variables (cap_mem_addr and cap_mem_size) for storing a
> > > > base address and size, describing a limited region in which memory may
> > > > be considered available for use by the kernel. If enabled, memory
> > > > outside of this range is not available for use.
> > > >
> > > > These variables can by filled by firmware-specific code, and used in
> > > > calls to memblock_cap_memory_range() by architecture-specific code.
> > > > An example user is the parser of the "linux,usable-memory-range"
> > > > property in the DT "/chosen" node.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > This is similar to how the initial ramdisk (phys_initrd_{start,size})
> > > > and ELF core headers (elfcorehdr_{addr,size})) are handled.
> > > >
> > > > Does there exist a suitable place in the common memblock code to call
> > > > "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this
> > > > have to be done in architecture-specific code?
> > >
> > > Can't you just call it from early_init_dt_scan_usablemem? If the
> > > property is present, you want to call it. If the property is not
> > > present, nothing happens.
>
> I will have a look...
>
> > For memblock_cap_memory_range() to work properly it should be called after
> > memory is detected and added to memblock with memblock_add[_node]()
> >
> > I'm not huge fan of adding more globals to memblock so if such ordering can
> > be implemented on the DT side it would be great.
>
> Me neither ;-)
>
> > I don't see a way to actually enforce this ordering, so maybe we'd want to
> > add warning in memblock_cap_memory_range() if memblock.memory is empty.
>
> "linux,usable-memory-range" is optional, and typically used only in
> crashdump kernels, so it would be a bad idea to add such a warning.
If I remember correctly, memblock_cap_memory_range() was added to support
"linux,usable-memory-range" for crasdump kernels on arm64 and if it would
be called before memory is registered we may silently corrupt the memory
because the crash kernel will see all the memory as available.
So while WARN() maybe too much a pr_warn() seems to me quite appropriate.
--
Sincerely yours,
Mike.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-07-20 5:41 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 12:50 [PATCH v4 00/10] Add generic support for kdump DT properties Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 01/10] crash_dump: Make elfcorehdr_{addr,size} always visible Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 01/10] crash_dump: Make elfcorehdr_{addr, size} " Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 13:46 ` [PATCH v4 01/10] crash_dump: Make elfcorehdr_{addr,size} " Rob Herring
2021-07-14 13:46 ` Rob Herring
2021-07-14 13:46 ` Rob Herring
2021-07-14 13:46 ` Rob Herring
2021-07-14 12:50 ` [PATCH v4 02/10] memblock: Add variables for usable memory limitation Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 13:51 ` Rob Herring
2021-07-14 13:51 ` Rob Herring
2021-07-14 13:51 ` Rob Herring
2021-07-14 13:51 ` Rob Herring
2021-07-18 9:31 ` Mike Rapoport
2021-07-18 9:31 ` Mike Rapoport
2021-07-18 9:31 ` Mike Rapoport
2021-07-18 9:31 ` Mike Rapoport
2021-07-19 6:59 ` Geert Uytterhoeven
2021-07-19 6:59 ` Geert Uytterhoeven
2021-07-19 6:59 ` Geert Uytterhoeven
2021-07-19 6:59 ` Geert Uytterhoeven
2021-07-19 6:59 ` Geert Uytterhoeven
2021-07-20 5:41 ` Mike Rapoport [this message]
2021-07-20 5:41 ` Mike Rapoport
2021-07-20 5:41 ` Mike Rapoport
2021-07-20 5:41 ` Mike Rapoport
2021-07-20 5:41 ` Mike Rapoport
2021-07-20 7:23 ` Geert Uytterhoeven
2021-07-20 7:23 ` Geert Uytterhoeven
2021-07-20 7:23 ` Geert Uytterhoeven
2021-07-20 7:23 ` Geert Uytterhoeven
2021-07-20 7:23 ` Geert Uytterhoeven
2021-08-11 8:11 ` Geert Uytterhoeven
2021-08-11 8:11 ` Geert Uytterhoeven
2021-08-11 8:11 ` Geert Uytterhoeven
2021-08-11 8:11 ` Geert Uytterhoeven
2021-08-11 8:11 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 03/10] of: fdt: Add generic support for parsing elf core headers property Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 04/10] of: fdt: Add generic support for parsing usable memory range property Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 05/10] of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 06/10] riscv: Remove non-standard linux,elfcorehdr handling Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 06/10] riscv: Remove non-standard linux, elfcorehdr handling Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-20 15:43 ` [PATCH v4 06/10] riscv: Remove non-standard linux,elfcorehdr handling Palmer Dabbelt
2021-07-20 15:43 ` [PATCH v4 06/10] riscv: Remove non-standard linux, elfcorehdr handling Palmer Dabbelt
2021-07-20 15:43 ` Palmer Dabbelt
2021-07-20 15:43 ` Palmer Dabbelt
2021-07-23 15:17 ` [PATCH v4 06/10] riscv: Remove non-standard linux,elfcorehdr handling Geert Uytterhoeven
2021-07-23 15:17 ` [PATCH v4 06/10] riscv: Remove non-standard linux, elfcorehdr handling Geert Uytterhoeven
2021-07-23 15:17 ` Geert Uytterhoeven
2021-07-23 15:17 ` [PATCH v4 06/10] riscv: Remove non-standard linux,elfcorehdr handling Geert Uytterhoeven
2021-07-23 15:17 ` [PATCH v4 06/10] riscv: Remove non-standard linux, elfcorehdr handling Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 07/10] arm64: kdump: Remove custom linux,elfcorehdr parsing Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 07/10] arm64: kdump: Remove custom linux, elfcorehdr parsing Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 08/10] arm64: kdump: Remove custom linux,usable-memory-range parsing Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 08/10] arm64: kdump: Remove custom linux, usable-memory-range parsing Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 09/10] arm64: kdump: Use IS_ENABLED(CONFIG_CRASH_DUMP) instead of #ifdef Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` [PATCH v4 10/10] ARM: Parse kdump DT properties Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 12:50 ` Geert Uytterhoeven
2021-07-14 14:53 ` Rob Herring
2021-07-14 14:53 ` Rob Herring
2021-07-14 14:53 ` Rob Herring
2021-07-14 14:53 ` Rob Herring
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=YPZh/IawtmwaYccQ@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=dyoung@redhat.com \
--cc=frowand.list@gmail.com \
--cc=geert@linux-m68k.org \
--cc=kexec@lists.infradead.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mick@ics.forth.gr \
--cc=nico@fluxnic.net \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=vgoyal@redhat.com \
--cc=will@kernel.org \
/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.