linux-kernel - Re: [PATCH] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards

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] [day] [month] [year] [list]

Date:   Tue, 11 Dec 2018 13:46:30 +0000
From:   Vokáč Michal <Michal.Vokac@...ft.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Rob Herring <robh@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        NXP Linux Team <linux-imx@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa
 boards

On 11.12.2018 13:36, Andrew Lunn wrote:
>>> Hi Rob, gentle ping on this.
>>>
>>> I would like to be sure how to proceed with this. Do you really want me
>>> to move *all* nodes that are disabled in this common dtsi into the per
>>> board dts?
>>>
>>> All the boards use identical PCB. Anything that is disabled here is not
>>> present on at least one of the boards. It means it is routed on the
>>> board and the SoC has the capability but the parts are not populated.
>>>
>>> So it is not only about the LED controller. What about the LCD, OLED,
>>> backlight, USB..?
>>
>> Can anybody advice how to split these dts/dtsi files, please?
>> I am not sure what should reside in the common dtsi and what should
>> be moved into the per board dts in case my current solution is not
>> appropriate.
> 
> The kirkwood-synology.dtsi might be of interest? There are a lot of
> Synology NAS boxes which share a lot in common. So all the common
> parts are in that .dtsi. The .dbs file for each individual model then
> enables the parts its needs.

That is a great example Andrew, thank you! That is exactly what I am
doing. Everything that is supported by the PCB/platform is specified
in the common file. Only parts that are populated on all products are
enabled there, the other stuff is disabled. The .dts files then enable
additional stuff they need.

To me it seems reasonable to do it that way and maybe I only
misunderstood what Rob actually meant by his comment? I still do not
have his reply to that though.

> Although you have one PCB, or the different population options
> considered different products, each with there own name?

Yes, each of the three population options can be considered a different
product with different name. That is still the same as the Synology
NAS boxes, right?

Michal