linux-kernel - Re: [PATCH v1 16/19] arm: dts: mt7623: fixup available memory size on bananapi-r2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Mar 2018 08:16:37 -0600
From:   Rob Herring <robh@...nel.org>
To:     Sean Wang <sean.wang@...iatek.com>
Cc:     Matthias Brugger <matthias.bgg@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 16/19] arm: dts: mt7623: fixup available memory size on bananapi-r2

On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang <sean.wang@...iatek.com> wrote:
> On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:
>> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.wang@...iatek.com wrote:
>> > From: Sean Wang <sean.wang@...iatek.com>
>> >
>> > There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
>> >
>> > [1] http://www.banana-pi.org/r2.html
>> >
>> > Signed-off-by: Sean Wang <sean.wang@...iatek.com>
>> > ---
>> >  arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 5 +++++
>> >  1 file changed, 5 insertions(+)
>> >
>> > diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> > index 140ff78..3e8d02c 100644
>> > --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> > +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
>> > @@ -38,6 +38,11 @@
>> >                     default-state = "off";
>> >             };
>> >     };
>> > +
>> > +   memory {
>>
>> Unit address?
>>
>
> If I did it with adding unit address
>
> -       memory {
> +       memory@...00000 {
>                 device_type = "memory";
>                 reg = <0 0x80000000 0 0x80000000>;
>         };
>
>
> bad dtc blob is being generated and contains two memory nodes, one is
> memory and the other is memory@...00000 whose blob disassembly detail is
> as the following.
>
>       memory {
>                 device_type = "memory";
>                 reg = <0x0 0x0 0x0 0x0>;
>         };
>
>
>
>       memory@...00000 {
>                 device_type = "memory";
>                 reg = <0x0 0x80000000 0x0 0x80000000>;
>         };
>
>
> and bad memory node with size 0 would cause the boot fails.
>
>
> is it a dtc compiler problem ?

No, you are declaring "memory" node somewhere else. Perhaps using
skeleton.dtsi which we are trying to remove or you have some default.

Using just 'memory' is fine if the base address is variable and
determined at boot time or you have a bootloader that expects just
'memory'. Otherwise, this should be fixed, but you can do that after
this patch if you want.

Rob