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

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: <20201113211826.13087-1-nm@ti.com>
Date:   Fri, 13 Nov 2020 15:18:21 -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:     <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, Nishanth Menon <nm@...com>
Subject: [PATCH V4 0/5] arm64: dts: ti: Cleanup mix of "okay" and "disabled"

Hi,

V4 changes:
- drops the fixes tags (as this is not strictly a stable fix)

Repost. older versions v3[3] v2[2] v1[1]

Summarising the blurb of the discussion[4] we have had, 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.

While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).

NOTE: There is a known risk of "omission" that new board dts
developers might miss reviewing both the board schematics in addition
to all the dt nodes of the SoC when setting appropriate nodes status
to "disable" or "reserved" in the board dts. This can expose issues in
drivers which may not anticipate an incomplete node(example: missing
appropriate board properties) being in "okay" state. These cases are
considered as bugs and need to be fixed in the drivers as and when
identified.

Nishanth Menon (5):
  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
  arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as
    "reserved"

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  9 ----
 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 26 ++++++----
 .../dts/ti/k3-j7200-common-proc-board.dts     |  4 +-
 .../dts/ti/k3-j721e-common-proc-board.dts     | 50 ++++++++++++++++++-
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi     | 28 -----------
 5 files changed, 67 insertions(+), 50 deletions(-)

[1] https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-1-nm@ti.com/
[2] https://lore.kernel.org/linux-arm-kernel/20201112014929.25227-1-nm@ti.com/
[3] https://lore.kernel.org/linux-arm-kernel/20201112183538.6805-1-nm@ti.com/
[4] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/
-- 
2.29.2