From: daniel.thompson@linaro.org (Daniel Thompson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
Date: Thu, 27 Aug 2015 16:54:49 +0100 [thread overview]
Message-ID: <55DF32C9.8040302@linaro.org> (raw)
In-Reply-To: <1440552341.10987.53.camel@linaro.org>
On 26/08/15 02:25, Haojian Zhuang wrote:
>> Option 1:
>>
>> memory at 0 {
>> device_type = "memory";
>> reg = <0x00000000 0x00000000 0x00000000 0x05e00000>,
>> <0x00000000 0x05f00000 0x00000000 0x00eff000>,
>> <0x00000000 0x06e00000 0x00000000 0x0060f000>,
>> <0x00000000 0x07410000 0x00000000 0x38bf0000>;
>> };
>>
>> [snip]
>>
>> Option 2:
>>
>> memory at 0 {
>> device_type = "memory";
>> reg = <0x0 0x0 0x0 0x40000000>;
>> };
>>
>> [snip]
>>
>
> I prefer the second one. From my view, memory node should only describe
> the hardware information of memory.
Haven't we already established that, to avoid the risk of UEFI
applications accessing inappropriate memory locations, a (correct) UEFI
implementation must use, and pass to the kernel, a memory map that looks
like option 1?
That being the case why would we want u-boot (or any other similar
bootloader) to pass a memory map that is gratuitously different to the
one supplied by UEFI?
Daniel.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Haojian Zhuang <haojian.zhuang@linaro.org>, Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Jassi Brar <jassisinghbrar@gmail.com>,
Bintian Wang <bintian.wang@huawei.com>,
Yiping Xu <xuyiping@hisilicon.com>, Wei Xu <xuwei5@hisilicon.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"guodong.xu@linaro.org" <guodong.xu@linaro.org>,
Jian Zhang <zhangjian001@hisilicon.com>,
Zhenwei Wang <Zhenwei.wang@hisilicon.com>,
Haoju Mo <mohaoju@hisilicon.com>,
Dan Zhao <dan.zhao@hisilicon.com>,
kongfei@hisilicon.c
Subject: Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
Date: Thu, 27 Aug 2015 16:54:49 +0100 [thread overview]
Message-ID: <55DF32C9.8040302@linaro.org> (raw)
In-Reply-To: <1440552341.10987.53.camel@linaro.org>
On 26/08/15 02:25, Haojian Zhuang wrote:
>> Option 1:
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x00000000 0x00000000 0x00000000 0x05e00000>,
>> <0x00000000 0x05f00000 0x00000000 0x00eff000>,
>> <0x00000000 0x06e00000 0x00000000 0x0060f000>,
>> <0x00000000 0x07410000 0x00000000 0x38bf0000>;
>> };
>>
>> [snip]
>>
>> Option 2:
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x0 0x0 0x0 0x40000000>;
>> };
>>
>> [snip]
>>
>
> I prefer the second one. From my view, memory node should only describe
> the hardware information of memory.
Haven't we already established that, to avoid the risk of UEFI
applications accessing inappropriate memory locations, a (correct) UEFI
implementation must use, and pass to the kernel, a memory map that looks
like option 1?
That being the case why would we want u-boot (or any other similar
bootloader) to pass a memory map that is gratuitously different to the
one supplied by UEFI?
Daniel.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Haojian Zhuang <haojian.zhuang@linaro.org>, Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Jassi Brar <jassisinghbrar@gmail.com>,
Bintian Wang <bintian.wang@huawei.com>,
Yiping Xu <xuyiping@hisilicon.com>, Wei Xu <xuwei5@hisilicon.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"guodong.xu@linaro.org" <guodong.xu@linaro.org>,
Jian Zhang <zhangjian001@hisilicon.com>,
Zhenwei Wang <Zhenwei.wang@hisilicon.com>,
Haoju Mo <mohaoju@hisilicon.com>,
Dan Zhao <dan.zhao@hisilicon.com>,
"kongfei@hisilicon.com" <kongfei@hisilicon.com>,
Guangyue Zeng <zengguangyue@hisilicon.com>
Subject: Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
Date: Thu, 27 Aug 2015 16:54:49 +0100 [thread overview]
Message-ID: <55DF32C9.8040302@linaro.org> (raw)
In-Reply-To: <1440552341.10987.53.camel@linaro.org>
On 26/08/15 02:25, Haojian Zhuang wrote:
>> Option 1:
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x00000000 0x00000000 0x00000000 0x05e00000>,
>> <0x00000000 0x05f00000 0x00000000 0x00eff000>,
>> <0x00000000 0x06e00000 0x00000000 0x0060f000>,
>> <0x00000000 0x07410000 0x00000000 0x38bf0000>;
>> };
>>
>> [snip]
>>
>> Option 2:
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x0 0x0 0x0 0x40000000>;
>> };
>>
>> [snip]
>>
>
> I prefer the second one. From my view, memory node should only describe
> the hardware information of memory.
Haven't we already established that, to avoid the risk of UEFI
applications accessing inappropriate memory locations, a (correct) UEFI
implementation must use, and pass to the kernel, a memory map that looks
like option 1?
That being the case why would we want u-boot (or any other similar
bootloader) to pass a memory map that is gratuitously different to the
one supplied by UEFI?
Daniel.
next prev parent reply other threads:[~2015-08-27 15:54 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 9:37 [PATCH v1 0/3] mailbox: hisilicon: add Hi6220 mailbox driver Leo Yan
2015-08-19 9:37 ` Leo Yan
2015-08-19 9:37 ` Leo Yan
2015-08-19 9:37 ` [PATCH v1 1/3] dt-bindings: mailbox: Document " Leo Yan
2015-08-19 9:37 ` Leo Yan
2015-08-25 11:17 ` Sudeep Holla
2015-08-25 11:17 ` Sudeep Holla
2015-08-25 11:17 ` Sudeep Holla
2015-08-25 13:01 ` Leo Yan
2015-08-25 13:01 ` Leo Yan
2015-08-25 13:01 ` Leo Yan
2015-08-19 9:37 ` [PATCH v1 2/3] mailbox: Hi6220: add " Leo Yan
2015-08-19 9:37 ` Leo Yan
2015-08-19 9:37 ` [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node Leo Yan
2015-08-19 9:37 ` Leo Yan
2015-08-21 18:40 ` Mark Rutland
2015-08-21 18:40 ` Mark Rutland
2015-08-21 18:40 ` Mark Rutland
2015-08-22 13:30 ` Leo Yan
2015-08-22 13:30 ` Leo Yan
2015-08-22 13:30 ` Leo Yan
2015-08-24 3:27 ` Leo Yan
2015-08-24 3:27 ` Leo Yan
2015-08-24 3:27 ` Leo Yan
2015-08-24 9:18 ` Leo Yan
2015-08-24 9:18 ` Leo Yan
2015-08-24 9:18 ` Leo Yan
2015-08-24 9:51 ` Mark Rutland
2015-08-24 9:51 ` Mark Rutland
2015-08-24 9:51 ` Mark Rutland
2015-08-24 10:19 ` Haojian Zhuang
2015-08-24 10:19 ` Haojian Zhuang
2015-08-24 10:19 ` Haojian Zhuang
2015-08-24 11:49 ` Leif Lindholm
2015-08-24 11:49 ` Leif Lindholm
2015-08-24 11:49 ` Leif Lindholm
2015-08-25 8:13 ` Haojian Zhuang
2015-08-25 8:13 ` Haojian Zhuang
2015-08-25 8:13 ` Haojian Zhuang
2015-08-25 9:46 ` Leif Lindholm
2015-08-25 9:46 ` Leif Lindholm
2015-08-25 9:46 ` Leif Lindholm
2015-08-25 10:15 ` Haojian Zhuang
2015-08-25 10:15 ` Haojian Zhuang
2015-08-25 10:15 ` Haojian Zhuang
2015-08-25 10:40 ` Leif Lindholm
2015-08-25 10:40 ` Leif Lindholm
2015-08-25 10:40 ` Leif Lindholm
2015-08-25 10:42 ` Mark Rutland
2015-08-25 10:42 ` Mark Rutland
2015-08-25 10:42 ` Mark Rutland
2015-08-25 13:43 ` Haojian Zhuang
2015-08-25 13:43 ` Haojian Zhuang
2015-08-25 13:43 ` Haojian Zhuang
2015-08-25 14:24 ` Leif Lindholm
2015-08-25 14:24 ` Leif Lindholm
2015-08-25 14:24 ` Leif Lindholm
2015-08-25 14:51 ` Ard Biesheuvel
2015-08-25 14:51 ` Ard Biesheuvel
2015-08-25 14:51 ` Ard Biesheuvel
2015-08-25 15:37 ` Leif Lindholm
2015-08-25 15:37 ` Leif Lindholm
2015-08-25 15:37 ` Leif Lindholm
2015-08-25 15:45 ` Ard Biesheuvel
2015-08-25 15:45 ` Ard Biesheuvel
2015-08-25 15:45 ` Ard Biesheuvel
2015-08-26 2:41 ` Haojian Zhuang
2015-08-26 2:41 ` Haojian Zhuang
2015-08-26 2:41 ` Haojian Zhuang
2015-08-25 16:00 ` Leo Yan
2015-08-25 16:00 ` Leo Yan
2015-08-25 16:00 ` Leo Yan
2015-08-26 1:25 ` Haojian Zhuang
2015-08-26 1:25 ` Haojian Zhuang
2015-08-26 1:25 ` Haojian Zhuang
2015-08-26 6:59 ` Leo Yan
2015-08-26 6:59 ` Leo Yan
2015-08-26 6:59 ` Leo Yan
2015-08-27 16:31 ` Mark Rutland
2015-08-27 16:31 ` Mark Rutland
2015-08-27 16:31 ` Mark Rutland
2015-08-28 6:37 ` Leo Yan
2015-08-28 6:37 ` Leo Yan
2015-08-28 6:37 ` Leo Yan
2015-08-27 15:54 ` Daniel Thompson [this message]
2015-08-27 15:54 ` Daniel Thompson
2015-08-27 15:54 ` Daniel Thompson
2015-08-27 16:46 ` Mark Rutland
2015-08-27 16:46 ` Mark Rutland
2015-08-27 16:46 ` Mark Rutland
2015-08-24 12:48 ` Mark Rutland
2015-08-24 12:48 ` Mark Rutland
2015-08-24 12:48 ` Mark Rutland
2015-08-25 8:04 ` Haojian Zhuang
2015-08-25 8:04 ` Haojian Zhuang
2015-08-25 8:04 ` Haojian Zhuang
2015-08-25 11:09 ` Mark Rutland
2015-08-25 11:09 ` Mark Rutland
2015-08-25 11:09 ` Mark Rutland
2015-08-25 11:36 ` Sudeep Holla
2015-08-25 11:36 ` Sudeep Holla
2015-08-25 11:36 ` Sudeep Holla
2015-08-25 14:04 ` Leo Yan
2015-08-25 14:04 ` Leo Yan
2015-08-25 14:04 ` Leo Yan
2015-08-25 14:13 ` Sudeep Holla
2015-08-25 14:13 ` Sudeep Holla
2015-08-25 14:13 ` Sudeep Holla
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=55DF32C9.8040302@linaro.org \
--to=daniel.thompson@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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.