linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: chenzhou <chenzhou10@huawei.com>, James Morse <james.morse@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	dyoung@redhat.com, Baoquan He <bhe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	John.p.donnelly@oracle.com, pkushwaha@marvell.com,
	Simon Horman <horms@verge.net.au>,
	Hanjun Guo <guohanjun@huawei.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kexec@lists.infradead.org
Subject: Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
Date: Tue, 26 May 2020 15:18:00 -0600	[thread overview]
Message-ID: <20200526211800.GA352001@bogus> (raw)
In-Reply-To: <a419602e-6a85-ca35-39de-b3c26d433199@huawei.com>

On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
> Hi Rob,

+James M (It's nice to Cc folks if you mention/quote them)


> On 2020/5/21 21:29, Rob Herring wrote:
> > On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
> >> Add documentation for DT property used by arm64 kdump:
> >> linux,low-memory-range.
> >> "linux,low-memory-range" is an another memory region used for crash
> >> dump kernel devices.
> >>
> >> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> >> ---
> >>  Documentation/devicetree/bindings/chosen.txt | 25 ++++++++++++++++++++
> >>  1 file changed, 25 insertions(+)
> > chosen is now a schema documented here[1].
> Ok, that is, i don't need to modify the doc in kernel, just create a pull request in github [1]?
> 
> >
> >> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> >> index 45e79172a646..bfe6fb6976e6 100644
> >> --- a/Documentation/devicetree/bindings/chosen.txt
> >> +++ b/Documentation/devicetree/bindings/chosen.txt
> >> @@ -103,6 +103,31 @@ While this property does not represent a real hardware, the address
> >>  and the size are expressed in #address-cells and #size-cells,
> >>  respectively, of the root node.
> >>
> >> +linux,low-memory-range
> >> +----------------------
> >> +This property (arm64 only) holds a base address and size, describing a
> >> +limited region below 4G. Similar to "linux,usable-memory-range", it is
> >> +an another memory range which may be considered available for use by the
> >> +kernel.
> > Why can't you just add a range to "linux,usable-memory-range"? It
> > shouldn't be hard to figure out which part is below 4G.
> I did like this in my previous version, such as v5. After discussed with James, i modified it to the current way.
> 
> We think the existing behavior should be unchanged, which helps with keeping compatibility with existing
> user-space and older kdump kernels.
> 
> The comments from James:
> > linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>.
> Won't this break if your kdump kernel doesn't know what the extra parameters are?
> Or if it expects two ranges, but only gets one? These DT properties should be treated as
> ABI between kernel versions, we can't really change it like this.
> 
> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
> think the simplest thing to do is to add an 'linux,low-memory-range' that we
> memblock_add() after memblock_cap_memory_range() has been called.
> If its missing, or the new kernel doesn't know what its for, everything keeps working.


I don't think there's a compatibility issue here though. The current 
kernel doesn't care if the property is longer than 1 base+size. It only 
checks if the size is less than 1 base+size. And yes, we can rely on 
that implementation detail. It's only an ABI if an existing user 
notices.

Now, if the low memory is listed first, then an older kdump kernel 
would get a different memory range. If that's a problem, then define 
that low memory goes last. 

Rob

  reply	other threads:[~2020-05-26 21:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21  9:38 [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2020-05-21  9:38 ` [PATCH v8 1/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c Chen Zhou
2020-05-26  0:56   ` Baoquan He
2020-05-21  9:38 ` [PATCH v8 2/5] arm64: kdump: reserve crashkenel above 4G for crash dump kernel Chen Zhou
2020-05-26  0:59   ` Baoquan He
2020-05-21  9:38 ` [PATCH v8 3/5] arm64: kdump: add memory for devices by DT property, low-memory-range Chen Zhou
2020-05-21  9:38 ` [PATCH v8 4/5] kdump: update Documentation about crashkernel on arm64 Chen Zhou
2020-05-21  9:38 ` [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump Chen Zhou
2020-05-21 13:29   ` Rob Herring
2020-05-22  3:24     ` chenzhou
2020-05-26 21:18       ` Rob Herring [this message]
2020-05-29 16:11         ` James Morse
2020-06-20  3:54           ` chenzhou
2020-05-26  1:42 ` [PATCH v8 0/5] support reserving crashkernel above 4G on " Baoquan He
2020-05-26  2:28   ` chenzhou
2020-05-28 22:20   ` John Donnelly
2020-05-29  8:05     ` Will Deacon
2020-06-01 12:02 ` Prabhakar Kushwaha
2020-06-01 19:30   ` John Donnelly
2020-06-01 21:02     ` Bhupesh Sharma
2020-06-01 21:59       ` John Donnelly
2020-06-02  5:38         ` Prabhakar Kushwaha
2020-06-02 14:41           ` John Donnelly
2020-06-03 11:47             ` Prabhakar Kushwaha
2020-06-03 13:20               ` chenzhou
2020-06-03 15:30                 ` John Donnelly
2020-06-03 19:47                   ` Bhupesh Sharma
2020-06-04  7:14                     ` Will Deacon
2020-06-04 17:01                     ` Nicolas Saenz Julienne
2020-06-05  2:26                       ` John Donnelly
2020-06-05  8:21                         ` Nicolas Saenz Julienne
2020-06-19  2:32                       ` John Donnelly
2020-06-19  8:21                         ` chenzhou
2020-06-20  0:01                           ` John Donnelly

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=20200526211800.GA352001@bogus \
    --to=robh@kernel.org \
    --cc=John.p.donnelly@oracle.com \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenzhou10@huawei.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dyoung@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=horms@verge.net.au \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pkushwaha@marvell.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).