From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: kexec@lists.infradead.org, catalin.marinas@arm.com,
will.deacon@arm.com, geoff@infradead.org, james.morse@arm.com,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v21 8/8] Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec
Date: Thu, 07 Jul 2016 15:46:35 -0300 [thread overview]
Message-ID: <1629887.9vk1SlhCGj@hactar> (raw)
In-Reply-To: <20160707020025.GY20774@linaro.org>
Am Donnerstag, 07 Juli 2016, 11:00:25 schrieb AKASHI Takahiro:
> On Wed, Jul 06, 2016 at 04:29:18PM -0300, Thiago Jung Bauermann wrote:
> > Hi,
> >
> > Am Mittwoch, 06 Juli 2016, 16:52:26 schrieb AKASHI Takahiro:
> > > +linux,usable-memory
> > > +-------------------
> > > +
> > > +This property is set on PowerPC and arm64 by kexec-tools during kdump
> > > +to tell the crash kernel the base address of its reserved area of
> > > memory, and +the size. e.g.
> > > +
> > > +/ {
> > > + chosen {
> > > + linux,usable-memory = <0x9 0xf0000000 0x0 0x10000000>;
> > > + };
> > > +};
> >
> > Again, this description is wrong for PowerPC. See messages from myself
> > and Michael Ellerman:
> >
> > https://lists.infradead.org/pipermail/kexec/2016-June/016250.html
> >
> > https://lists.infradead.org/pipermail/kexec/2016-June/016253.html
>
> Oops, I must have missed your previous comments. Apologies.
No problem.
> Yes, I know that, and I used to implement the same functionality before.
> It did work for dtb-based systems, but not for UEFI(ACPI)-based systems
> because UEFI doesn't export memory regions information via a device tree,
> but rather via ACPI table. So "/memory" node won't appear.
> So I went back with "mem=" command line approach, and later this
> "/chosen/" approach.
Ah, I didn't realize there could be dtb and UEFI systems.
> > IMHO, it would be simpler if ARM used linux,usable-memory in the same
> > way
> > that PowerPC does, for consistency.
>
> Well, this property won't conflict with per-"/memory" ones
> if we take it that the former, if present, supersedes the latter.
> Sophistic?
> What about changing the name to usable-memory-limit?
> (I know that you have another one, "memory-limit" though.)
>
> Again, I would like to defer to arm64 maintainers.
My personal opinion is that having a property with a different name would be
less confusing, but it's not a strong opinion.
I would suggest calling it usable-memory-range, but I'm fine with whatever
is decided by the maintainers.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
prev parent reply other threads:[~2016-07-07 18:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160706075226.27609-1-takahiro.akashi@linaro.org>
[not found] ` <20160706075226.27609-9-takahiro.akashi@linaro.org>
2016-07-06 19:29 ` [PATCH v21 8/8] Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec Thiago Jung Bauermann
2016-07-07 2:00 ` AKASHI Takahiro
2016-07-07 18:46 ` Thiago Jung Bauermann [this message]
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=1629887.9vk1SlhCGj@hactar \
--to=bauerman@linux.vnet.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=geoff@infradead.org \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=takahiro.akashi@linaro.org \
--cc=will.deacon@arm.com \
/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).