From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: "AKASHI,
Takahiro"
<takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Jeffrey Hugo <jhugo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Sameer Goel <sgoel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb
Date: Wed, 8 Feb 2017 11:35:31 +0000 [thread overview]
Message-ID: <20170208113530.GC15459@leverpostej> (raw)
In-Reply-To: <20170208074301.GB18445-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Feb 08, 2017 at 04:43:04PM +0900, AKASHI, Takahiro wrote:
> On Tue, Feb 07, 2017 at 07:55:59PM +0000, Mark Rutland wrote:
> > (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?
>
> Yup, I will, but if this is the case,
> we might need to think about another case where /#address-cells and /#size-cells
> are <1> but the range of crash dump kernel can be still 64-bit wide since
> the system memory information comes from ACPI table (not DT).
That should only happen on an ACPI system for which the vendor has also
provided a DT in the FW, and also chose to use /#address-cells = <1>
and/or /#size-cells = <1>. We could log a warning and give up in this
case.
In the Purely DT case it shouldn't be a problem, since that would imply
all memory is within 32 bits.
... the other option Ard suggested was that we make these properties
always take 64-bit address and size values, and don't use #address-cells
or #size-cells at all when parsing them. I wasn't keen on this since the
properties would be reg-like, but potentially different in size. Maybe
that is the better option, though. :/
> Therefore, the properties in this case should look like:
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> chosen {
> ...
> linux,usable-memory-range {
> #address-cells = <2>;
> #size-cells = <2>; may be omitted if possible
> reg = < ... >;
> }
> linux,elfcorehdr {
> #address-cells = <2>;
> #size-cells = <2>; may be omitted if possible
> reg = < ... >;
> }
> ...
> }
> }
>
> Is this what you meant?
> (Obviously, I will have to modify the kernel patches as well.)
No; I was assuming we'd only change the userspace code, not the binding
or the kernel parsing.
If nothing else, the root /#address-cells and /#size-cells would have to
be widened to handle the translation, so the above alone is not
sufficient.
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb
Date: Wed, 8 Feb 2017 11:35:31 +0000 [thread overview]
Message-ID: <20170208113530.GC15459@leverpostej> (raw)
In-Reply-To: <20170208074301.GB18445@linaro.org>
On Wed, Feb 08, 2017 at 04:43:04PM +0900, AKASHI, Takahiro wrote:
> On Tue, Feb 07, 2017 at 07:55:59PM +0000, Mark Rutland wrote:
> > (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?
>
> Yup, I will, but if this is the case,
> we might need to think about another case where /#address-cells and /#size-cells
> are <1> but the range of crash dump kernel can be still 64-bit wide since
> the system memory information comes from ACPI table (not DT).
That should only happen on an ACPI system for which the vendor has also
provided a DT in the FW, and also chose to use /#address-cells = <1>
and/or /#size-cells = <1>. We could log a warning and give up in this
case.
In the Purely DT case it shouldn't be a problem, since that would imply
all memory is within 32 bits.
... the other option Ard suggested was that we make these properties
always take 64-bit address and size values, and don't use #address-cells
or #size-cells at all when parsing them. I wasn't keen on this since the
properties would be reg-like, but potentially different in size. Maybe
that is the better option, though. :/
> Therefore, the properties in this case should look like:
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> chosen {
> ...
> linux,usable-memory-range {
> #address-cells = <2>;
> #size-cells = <2>; may be omitted if possible
> reg = < ... >;
> }
> linux,elfcorehdr {
> #address-cells = <2>;
> #size-cells = <2>; may be omitted if possible
> reg = < ... >;
> }
> ...
> }
> }
>
> Is this what you meant?
> (Obviously, I will have to modify the kernel patches as well.)
No; I was assuming we'd only change the userspace code, not the binding
or the kernel parsing.
If nothing else, the root /#address-cells and /#size-cells would have to
be widened to handle the translation, so the above alone is not
sufficient.
Thanks,
Mark.
next prev parent reply other threads:[~2017-02-08 11:35 UTC|newest]
Thread overview: 40+ 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
2017-02-07 17:59 ` 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:12 ` Ard Biesheuvel
2017-02-07 18:54 ` Jeffrey Hugo
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:01 ` Mark Rutland
2017-02-07 19:06 ` Mark Rutland
2017-02-07 19:06 ` Mark Rutland
2017-02-07 19:07 ` Jeffrey Hugo
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:12 ` Ard Biesheuvel
2017-02-07 19:13 ` Mark Rutland
2017-02-07 19:13 ` Mark Rutland
2017-02-07 19:29 ` Jeffrey Hugo
2017-02-07 19:29 ` Jeffrey Hugo
2017-02-07 19:55 ` Mark Rutland
2017-02-07 19:55 ` Mark Rutland
2017-02-08 7:43 ` AKASHI, Takahiro
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-08 10:40 ` Ard Biesheuvel
2017-02-09 8:27 ` AKASHI, Takahiro
2017-02-09 8:27 ` AKASHI, Takahiro
[not found] ` <20170209082702.GC18445-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-13 20:55 ` Timur Tabi
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-13 20:51 ` Timur Tabi
2017-02-08 11:35 ` Mark Rutland [this message]
2017-02-08 11:35 ` Mark Rutland
2017-02-07 18:15 ` Mark Rutland
2017-02-07 18:15 ` Mark Rutland
2017-02-07 18:41 ` Jeffrey Hugo
2017-02-07 18:41 ` Jeffrey Hugo
2017-02-07 19:24 ` Timur Tabi
2017-02-07 19:24 ` Timur Tabi
2017-02-07 19:37 ` Mark Rutland
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=20170208113530.GC15459@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=jhugo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sgoel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.