| Message ID | 20201112183538.6805-1-nm@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: ti: Cleanup mix of "okay" and "disabled" | expand |
On Thu, 12 Nov 2020 12:35:33 -0600, Nishanth Menon wrote: > Changes since v2[3]: > - Rebase on top of ti-k3-dts-next (no functional changes) > - picked up reviewed-by and acks from folks. > > Since we have all the required acks and reviews, I will apply this > series tomorrow morning since this can cause churn for other folks. > > [...] Hi, I have applied the following 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: 957c8a49d2ed0d9ed710c8643d43912b64a3708a [2/5] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level commit: f388cb320905e0908429ce5ce8b14b5fadb6a1ea [3/5] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto commit: 2fcb0ff200d0c9b0c5cab541cc8f8444d937e9ca [4/5] arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB commit: 399e08d521a34ca8180c8eaeaf181176ace85b47 [5/5] arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved" commit: cf2e8c96b52984319c27f1e0b68fbef712df9bb9 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
On 07:07-20201113, Nishanth Menon wrote: > On Thu, 12 Nov 2020 12:35:33 -0600, Nishanth Menon wrote: > > Changes since v2[3]: > > - Rebase on top of ti-k3-dts-next (no functional changes) > > - picked up reviewed-by and acks from folks. > > > > Since we have all the required acks and reviews, I will apply this > > series tomorrow morning since this can cause churn for other folks. > > > > [...] > > Hi, > > I have applied the following 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: 957c8a49d2ed0d9ed710c8643d43912b64a3708a > [2/5] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level > commit: f388cb320905e0908429ce5ce8b14b5fadb6a1ea > [3/5] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto > commit: 2fcb0ff200d0c9b0c5cab541cc8f8444d937e9ca > [4/5] arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB > commit: 399e08d521a34ca8180c8eaeaf181176ace85b47 > [5/5] arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved" > commit: cf2e8c96b52984319c27f1e0b68fbef712df9bb9 > > > All being well this means that it will be integrated into the linux-next > tree (usually sometime in the next 24 hours) and sent up the chain during > the next merge window (or sooner if it is a relevant bug fix), however if > problems are discovered then the patch may be dropped or reverted. > > You may get further e-mails resulting from automated or manual testing > and review of the tree, please engage with people reporting problems and > send followup patches addressing any issues that are reported if needed. > > If any updates are required or you are submitting further changes they > should be sent as incremental updates against current git, existing > patches will not be replaced. > > Please add any relevant lists and maintainers to the CCs when replying > to this mail. > I will drop this series from my tree - Fixes: tags on the patches should be dropped as it is not strictly to the stable tree rules and can potentially cause conflicts when backported. I will repost the next version dropping the same and pick the new series up instead. Apologies on the churn (and thanks Peter, Sekhar for the offline feedback - better safe than sorry).
Changes since v2[3]: - Rebase on top of ti-k3-dts-next (no functional changes) - picked up reviewed-by and acks from folks. Since we have all the required acks and reviews, I will apply this series tomorrow morning since this can cause churn for other folks. Changes since v1[1]: - Picked up Reviews from Tomi - Added patch #5 for moving uart used by firmware to 'reserved' state (thanks Peter for pointing it out) - Updated commit message of #1, #2 to add information about the limitation as well (thanks Peter for your inputs). This is hopefully a conclusion of the thread we had (online[2] 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. 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/20201027130701.GE5639@atomide.com/ [3] https://lore.kernel.org/linux-arm-kernel/20201112014929.25227-1-nm@ti.com/