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:   Wed, 23 May 2018 10:34:39 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Stefan Agner <stefan@...er.ch>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Lucas Stach <dev@...xeye.de>
Subject: Re: [PATCH v5 1/3] ARM: dts: tegra: Remove skeleton.dtsi and fix DTC
 warnings for /memory

On Wed, May 23, 2018 at 10:22 AM, Stefan Agner <stefan@...er.ch> wrote:
> On 23.05.2018 09:05, Krzysztof Kozlowski wrote:
>> On Thu, May 17, 2018 at 1:39 PM, Stefan Agner <stefan@...er.ch> wrote:
>>> On 17.05.2018 09:45, Krzysztof Kozlowski wrote:
>>> Could we not add
>>>
>>>         memory { device_type = "memory"; };
>>>
>>> in the SoC level device trees?
>>>
>>> This would save device_type in all other instances.
>>>
>>> That is also how it is done in other places, e.g.
>>> arch/arm/boot/dts/imx6qdl.dtsi
>>
>> Not really because the unit address will not match between different
>> boards. The imx6qdl, as I see, has the same issue:
>>  - imx6qdl.dtsi defines "memory" node
>>  - imx6dl-apf6dev.dts includes the previous and defines "memory@...00000"
>>
>> This is wrong - two memory nodes.
>>
>
> Hm I see. We could add
>
> memory@0 { device_type = "memory"; };
>
> Since the reg property is specified in the board level device tree it
> would be still fine?
>
> Or probably better to provide a complete spec with length zero:
>
> memory@0 {
>         device_type = "memory";
>         reg = <0x0 0x0>;
> };
>
> Even some boards do that and assume that boot loader will fill it
> correctly, so that should be fine.

That could be the solution although tegra30-apalis.dtsi is a problem
here. For Tegra 114, 124 and 20 it would work fine - all boards from
given SoC have the same address of memory (0x0 or 0x80000000). However
for Tegra30 the Apalis did not have any memory reg before so I am not
sure what should be used. I added 0x0. The other Tegra30 boards have
memory@...00000.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ