From: "Andreas Färber" <afaerber@suse.de>
To: Neil Armstrong <narmstrong@baylibre.com>,
xypron.glpk@gmx.de, khilman@baylibre.com, carlo@caione.org
Cc: linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
Date: Thu, 19 Jan 2017 02:18:27 +0100 [thread overview]
Message-ID: <eca803d3-1a67-cda5-554d-4313ae56635e@suse.de> (raw)
In-Reply-To: <2bdb6818-4620-53b1-112d-2d6a29e484d9@suse.de>
Am 19.01.2017 um 01:20 schrieb Andreas Färber:
> Hi,
>
> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>> this patch adds these reserved zones.
>>
>> Without such reserved memory zones, running the following stress command :
>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>> multiple times:
>>
>> Could lead to the following kernel crashes :
>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>> ...
>> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>> ...
>> Instead of the OOM killer.
>>
>
> I miss a Fixes: or Cc: here for the backport you desired. To have it
> fixed back to my very introduction:
>
> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>
> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
> transition for 4.9 down to 4.6, which seems fairly straightforward.
>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> Changes since v4 at [5]:
>> - Move start of ddr memory to reserved-memory node
>> - Drop memory node move
>> - Fix typo in sizes
>>
>> Changes since resent v2 at [4]:
>> - Fix invalid comment of useable memory attributes
>>
>> Changes since original v2 at [3]:
>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>
>> Changes since v2 at [2]:
>> - Moved all memory node out of dtsi
>> - Added comment about useable memory
>> - Fixed comment about secmon reserved zone
>>
>> Changes since v1 at [1] :
>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>> - only kept secmon memory zone
>>
>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong@baylibre.com
>> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
>> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
>> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com
>> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong@baylibre.com
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index eada0b5..63d52b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -55,6 +55,24 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* 16 MiB reserved for Hardware ROM Firmware */
>> + hwrom: hwrom {
>
> Both sub-nodes get a label that is unused, but reserved-memory itself
> does not (my v4 remark). Intentional?
>
>> + reg = <0x0 0x0 0x0 0x1000000>;
>> + no-map;
>> + };
>> +
>> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>> + secmon: secmon {
>
> I note that this .dtsi further down has a node /firmware/secure-monitor
> with label sm.
> a) Is there any naming convention such as secmon_mem to adopt here to
> avoid mixups with sm?
> b) Should this secmon node be referenced in the secure-monitor node via
> memory-node = <&secmon>; to model their connection, thereby giving the
> label a use? Or should we maybe merge the two nodes by moving the
> compatible string here?
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Answering my own question: the example labels use _reserved suffix.
>> + reg = <0x0 0x10000000 0x0 0x200000>;
And since we use a reg property here, the node name should get a unit
address to avoid future dtc warnings/errors. Ditto for hwrom.
>> + no-map;
>> + };
>> + };
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>
> Anyway, objection resolved,
>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
>
> I don't expect breakage from these more confined additions, but I can
> try to test tomorrow.
>
> Thanks,
> Andreas
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2017-01-19 1:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 16:50 [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones Neil Armstrong
2017-01-18 23:04 ` Kevin Hilman
2017-01-19 0:20 ` Andreas Färber
2017-01-19 1:18 ` Andreas Färber [this message]
2017-01-19 4:36 ` Kevin Hilman
2017-01-20 9:14 ` Andreas Färber
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=eca803d3-1a67-cda5-554d-4313ae56635e@suse.de \
--to=afaerber@suse.de \
--cc=carlo@caione.org \
--cc=devicetree@vger.kernel.org \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=narmstrong@baylibre.com \
--cc=xypron.glpk@gmx.de \
/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).