Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Nishanth Menon <nm@ti.com>
To:     Roger Quadros <rogerq@ti.com>, Keerthy <j-keerthy@ti.com>,
        Jyri Sarha <jsarha@ti.com>,
        Tomi Valkeinen <tomi.valkeinen@ti.com>,
        Peter Ujfalusi <peter.ujfalusi@ti.com>,
        Lokesh Vutla <lokeshvutla@ti.com>,
        Rob Herring <robh+dt@kernel.org>,
        Tony Lindgren <tony@atomide.com>, Tero Kristo <t-kristo@ti.com>
CC:     <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, Nishanth Menon <nm@ti.com>
Subject: [PATCH 0/4] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage
Date:   Wed, 4 Nov 2020 16:43:52 -0600
Message-ID: <20201104224356.18040-1-nm@ti.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk

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