From: Mark Rutland <mark.rutland@arm.com>
To: Jeffrey Hugo <jhugo@codeaurora.org>,
"AKASHI, Takahiro" <takahiro.akashi@linaro.org>
Cc: Sameer Goel <sgoel@codeaurora.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb
Date: Tue, 7 Feb 2017 19:55:59 +0000 [thread overview]
Message-ID: <20170207195558.GK26173@leverpostej> (raw)
In-Reply-To: <252539a6-72f6-1afa-6ed5-3cf6a1aa24c2@codeaurora.org>
On Tue, Feb 07, 2017 at 12:29:38PM -0700, Jeffrey Hugo wrote:
> On 2/7/2017 12:13 PM, Mark Rutland wrote:
> >On Tue, Feb 07, 2017 at 12:07:56PM -0700, Jeffrey Hugo wrote:
> >>On 2/7/2017 12:01 PM, Mark Rutland wrote:
> >>>I take it this is specific to the kdump properties?
> >>>
> >>>I can't immediately see what would matter for the !kdump case.
> >>>properties inserted under /chosen are not truncated?
> >>
> >>The kexec/kdump properties are added under /chosen, therefore yes,
> >>properties added under /chosen are truncated, per our observations.
> >
> >Sorry for the dodgy (and confusing) reply above.
> >
> >What I was trying to ask was does this *only* affect kdump properties?
> >I note that kdump is not yet upstream for arm64.
> >
> >Or are there regular kexec properties that this affects?
> >
> >Or !kdump && !kexec properties?
> >
> >Can you please enumerate the set of properties for which this matters?
>
> "linux,elfcorehdr" and "linux,usable-memory-range"
>
> We are not aware of !kdump && !kexec properties where this is an issue.
Ok, I understand the problem now. Thanks for clarifying the !kdump
situation.
As per my reply to Timur, given this only affects kdump, this is all
happening in code that is not upstream, and therefore this is not
*currently* an issue.
In future, please report this kind of issue in reply to relevant
postings (e.g. [1]). At the very least, refer to these, with relevant
people Cc'd (e.g. Takahiro-san in this case).
I think there are three things which should happen:
(a) The userspace kexec-tools kdump code should take /#address-cells and
/#size-cells into account when inserting the linux,elfcorehdr and
linux,usable-memory-range properties. There can be DTs for 64 bit
platforms where these are not 2.
Takahiro-san, from looking at your kexec-tools repo, this is not
currently the case. Could you address that?
(b) The kdump documentation should updated to explicitly state that
these properties are #address-cells + #size-cells tuples, since this
is clearly going to be confusing either way. I'll try to come up
with wording for that, and I'll reply on the current [1] kdump
thread.
(c) Regardless, when creating the empty DT the EFI stub should insert
/#address-cells = <2> and /#size-cells = <2>. That better aligns
with the usual requirements for an otherwise empty DTB, and avoids a
tonne of fragility when the DTB is passed on or altered by other
agents.
So, please respin this patch, stating explicitly what this matters for.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486234.html
next prev parent reply other threads:[~2017-02-07 19:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 17:59 [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb Jeffrey Hugo
[not found] ` <1486490390-25251-1-git-send-email-jhugo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-07 18:12 ` Ard Biesheuvel
2017-02-07 18:54 ` Jeffrey Hugo
[not found] ` <1f47fcdd-c5d8-4082-70a3-ca9b1746d7ca-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-07 19:01 ` Mark Rutland
2017-02-07 19:06 ` Mark Rutland
2017-02-07 19:07 ` Jeffrey Hugo
[not found] ` <c49cc64e-4ca1-8d82-5faf-74c0355c35ef-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-07 19:12 ` Ard Biesheuvel
2017-02-07 19:13 ` Mark Rutland
2017-02-07 19:29 ` Jeffrey Hugo
2017-02-07 19:55 ` Mark Rutland [this message]
2017-02-08 7:43 ` AKASHI, Takahiro
[not found] ` <20170208074301.GB18445-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-08 10:40 ` Ard Biesheuvel
2017-02-09 8:27 ` AKASHI, Takahiro
[not found] ` <20170209082702.GC18445-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-13 20:55 ` Timur Tabi
[not found] ` <CAKv+Gu8OXn20JvtFkE_bS=cbWV3XZ5b7a+XaG7tvea+4BqrHfw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-13 20:51 ` Timur Tabi
2017-02-08 11:35 ` Mark Rutland
2017-02-07 18:15 ` Mark Rutland
2017-02-07 18:41 ` Jeffrey Hugo
2017-02-07 19:24 ` Timur Tabi
2017-02-07 19:37 ` Mark Rutland
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=20170207195558.GK26173@leverpostej \
--to=mark.rutland@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=jhugo@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=sgoel@codeaurora.org \
--cc=takahiro.akashi@linaro.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