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]

Date:   Sat, 15 Jan 2022 12:50:18 +0100
From:   Pali Rohár <pali@...nel.org>
To:     Stephen Boyd <sboyd@...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

On Saturday 15 January 2022 00:02:11 Stephen Boyd wrote:
> 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?

Yes, exactly, separate nodes for serial1 and serial2 are still required.

But dropping clock controller is not possible as for higher baudrates we
need to use and configure uart clock controller. Without it we just get
comparable feature support which is already present in driver.

But, I do not fully understand now, why to change this DTS bindings in
this incompatible way? What it brings? Because for me now it looks like
that this change does not bring anything useful, only breaks current DTS
bindings.

Driver changes would still look in the similar / same way like it is in
current patch series because bindings already contains separate nodes,
just they are children of top level node which represents in internal
registers.