linux-kernel - Re: [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock

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]

Message-Id: <20220115080213.0CCAFC36AE3@smtp.kernel.org>
Date:   Sat, 15 Jan 2022 00:02:11 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Vladimir Vid <vladimir.vid@...tura.hr>,
        Marek Behún <kabel@...nel.org>,
        linux-clk@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock

Quoting Pali Rohár (2021-10-15 23:42:10)
> 
> If I was designing this driver and DTS bindings I would have choose
> something like this:
> 
> uart@...2000 {

Drop the 0x

>     reg = <0x12000 0x18>, <0x12200 0x30>;
>     clock-controller {
>         ...
>     };

Drop this node and put whatever properties are inside into the parent
node.

>     serial1 {
>         ...
>         status = "disabled";
>     };
>     serial2 {
>         ...
>         status = "disabled";
>     };
> };
> 
> Meaning that 0x12000 node would be 3 subnodes and all registers would be
> defined in top level nodes and would be handled by one driver.
> 
> This is really how hardware block looks like. But it is not backward
> compatible...

Sounds good to me. I presume we need the serial child nodes so we can
reference them from the stdout-path?