linux-kernel - [PATCH 0/4] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage

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

Message-ID: <20201104224356.18040-1-nm@ti.com>
Date:   Wed, 4 Nov 2020 16:43:52 -0600
From:   Nishanth Menon <nm@...com>
To:     Roger Quadros <rogerq@...com>, Keerthy <j-keerthy@...com>,
        Jyri Sarha <jsarha@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Lokesh Vutla <lokeshvutla@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>, Tero Kristo <t-kristo@...com>
CC:     <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, Nishanth Menon <nm@...com>
Subject: [PATCH 0/4] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage

Hi,

This is hopefully a conclusion of the thread we had (online[1] and
offline). There are few options one could take when dealing with SoC
dtsi and board dts:

a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
   to prevent messy board files, when more boards are added per SoC, we
   optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
   dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
   in SoC dtsi and over the years we can optimize things and change
   default state depending on the need.

What we have today is a bit of a mix of seemingly random set of
choices, however, predominantly following (a) and a few intermittent
cases of (b) and (c). While there are pros and cons on each of these
approaches, the right thing to do will be to stick with device tree
default (aka device tree standards) and work within those established
rules. So, lets cleanup and follow what the vast majority of SoC
platforms are doing and which also happens to be the path of least churn
for TI dts nodes as well.

Functionally the dtb output is same ->
a) As of v5.10-rc1:
   am654: https://pastebin.ubuntu.com/p/G4P5vghpV3/
   j7200: https://pastebin.ubuntu.com/p/SsG6JtPzR9/
   j721e: https://pastebin.ubuntu.com/p/HWXmTwD6m8/

b) with this series applied:
   am654: https://pastebin.ubuntu.com/p/h7MmHPQpRx/
   j7200: https://pastebin.ubuntu.com/p/VXjQHhQNgn/
   j721e: https://pastebin.ubuntu.com/p/2JMgftd4Xx/

The actual diff between the two versions being: https://pastebin.ubuntu.com/p/4rwy5qRY84/
Which is equivalent as per device tree standards, but uses lesser
redundant strings.

Thanks Tony, for sticking to the guns and providing us clear guidance
on this topic.

[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/

Nishanth Menon (4):
  arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level
  arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
  arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay"
    for crypto
  arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to
    "okay" for USB

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  9 ----
 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 24 ++++++----
 .../dts/ti/k3-j721e-common-proc-board.dts     | 48 ++++++++++++++++++-
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi     | 28 -----------
 4 files changed, 63 insertions(+), 46 deletions(-)

-- 
2.29.2