| Message ID | 20201113211826.13087-1-nm@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: ti: Cleanup mix of "okay" and "disabled" | expand |
On Fri, 13 Nov 2020 15:18:21 -0600, Nishanth Menon wrote: > 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: > > [...] I have applied this revision to branch ti-k3-dts-next on [1]. Thank you! [1/5] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level commit: af03de2b9b908e776c233744b84ce9dbb70dcafb [2/5] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level commit: 5d1bedf252db3ec2becb9f43c55e0f33af1fd7fc [3/5] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto commit: bfbf9be725d8effdbb60eb2ece44c06ae87a54de [4/5] arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB commit: 90e6c38848f8e86047e0e758c0725b155e2e349b [5/5] arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved" commit: 4cc34aa8a208665aa0362a615deefc3db6a5d7bd [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
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/