linux-kernel - [PATCH V3 1/5] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level

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:   Thu, 12 Nov 2020 12:35:34 -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 V3 1/5] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level

The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.

In general, after a few rounds of discussions [1] 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).

Lets cleanup defaults of am654 SoC dtsi before this gets more harder
to cleanup later on and new SoCs are added.

The dtb generated is identical with the patch and it is just cleanup to
ensure we have a clean usage model

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 that
may not anticipate an incomplete node (example: missing appropriate
board properties) being in an "okay" state. These cases are considered
bugs and need to be fixed in the drivers as and when identified.

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

Fixes: 9bcb631e9953 ("arm64: dts: ti: k3-am654-main: Add McASP nodes")
Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: Nishanth Menon <nm@...com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@...com>
Reviewed-by: Tony Lindgren <tony@...mide.com>
Cc: Jyri Sarha <jsarha@...com>
Cc: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>
Cc: Tony Lindgren <tony@...mide.com>
---
Changes since v2:
- rebase to resolve dss conflict.
- no functional change, just reviewed-by picked up

V2: https://lore.kernel.org/linux-arm-kernel/20201112014929.25227-2-nm@ti.com/
V1: https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-2-nm@ti.com/

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi       |  8 --------
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 16 ++++++++++++++++
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index a664c91675de..c842b9803f2d 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -769,8 +769,6 @@ mcasp0: mcasp@...0000 {
 		clocks = <&k3_clks 104 0>;
 		clock-names = "fck";
 		power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
-
-		status = "disabled";
 	};

 	mcasp1: mcasp@...0000 {
@@ -788,8 +786,6 @@ mcasp1: mcasp@...0000 {
 		clocks = <&k3_clks 105 0>;
 		clock-names = "fck";
 		power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
-
-		status = "disabled";
 	};

 	mcasp2: mcasp@...0000 {
@@ -807,8 +803,6 @@ mcasp2: mcasp@...0000 {
 		clocks = <&k3_clks 106 0>;
 		clock-names = "fck";
 		power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
-
-		status = "disabled";
 	};

 	cal: cal@...3000 {
@@ -864,8 +858,6 @@ dss: dss@...0000 {

 		interrupts = <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>;

-		status = "disabled";
-
 		dma-coherent;

 		dss_ports: ports {
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 17f3a85360e6..0dec781982b1 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -529,3 +529,19 @@ &cpsw_port1 {
 	phy-mode = "rgmii-rxid";
 	phy-handle = <&phy0>;
 };
+
+&mcasp0 {
+	status = "disabled";
+};
+
+&mcasp1 {
+	status = "disabled";
+};
+
+&mcasp2 {
+	status = "disabled";
+};
+
+&dss {
+	status = "disabled";
+};
-- 
2.29.2