From patchwork Thu Nov 12 01:49:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nishanth Menon X-Patchwork-Id: 11898851 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AADDC388F9 for ; Thu, 12 Nov 2020 01:51:22 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 07238206B5 for ; Thu, 12 Nov 2020 01:51:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bqupJ8/e"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="x5BkalG8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07238206B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=y61LV2DJkLPlS8S4APbuS4HBAstaOOo+R9FgIxeI60E=; b=bqupJ8/eEt9bgJ46zA+hnl5p25 wIkeAEByv0wIHCxP4zXQzNSespbPZZwYvtg2PorFos8heyFS8lA35tV8sjfYQRdtqnPY6pUvc1j6R aSRBY1R7LO3riujNCMPAx68ue98XqM2krhqD7W4c6F0+5hmi/5mDp2h1uGe8ermJpNwrQBqztPP2p ejcTBjPIrMOFuXRtY73ZWdyhJ3SC/l7DeR/FJ61kcquBihRRTZG5iJz3nKGvLCJ7KQOwbOhShSXBg oi8P5WyMjKNB/njA6q4qpJdcg1kLm9Bi9HE27DiBM2ptRDcjixV8JkkwgJe5Wjshb8B8mvLk3fTFa P4NokTyQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kd1kN-0001Xs-Me; Thu, 12 Nov 2020 01:50:01 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kd1kA-0001Td-1x for linux-arm-kernel@lists.infradead.org; Thu, 12 Nov 2020 01:49:48 +0000 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0AC1ncR5087191; Wed, 11 Nov 2020 19:49:38 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1605145778; bh=lRqbBvd7Jzj28LeXSmW/JNQRPNjf90HOGlYgPPE1PEI=; h=From:To:CC:Subject:Date; b=x5BkalG81lgnKA+WO89TXoJWztLzdod7qIqGT+W0Wx1yuiG04Dx97W/9oZIzCQoQE Z5V1hi7O/2Uuve5fnJpnIe2mXwrFszlhmRgtryGopMSHLoLtlNjrwnaAkctCgY6Akn BuASwLDNO/RGn9YhX4JIT07S0KRzPUc1i3Lp9iGg= Received: from DFLE110.ent.ti.com (dfle110.ent.ti.com [10.64.6.31]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0AC1ncdF103271 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Nov 2020 19:49:38 -0600 Received: from DFLE110.ent.ti.com (10.64.6.31) by DFLE110.ent.ti.com (10.64.6.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Wed, 11 Nov 2020 19:49:38 -0600 Received: from fllv0039.itg.ti.com (10.64.41.19) by DFLE110.ent.ti.com (10.64.6.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Wed, 11 Nov 2020 19:49:38 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0AC1nc8w028660; Wed, 11 Nov 2020 19:49:38 -0600 From: Nishanth Menon To: Roger Quadros , Keerthy , Jyri Sarha , Tomi Valkeinen , Peter Ujfalusi , Lokesh Vutla , Rob Herring , Tony Lindgren , Tero Kristo Subject: [PATCH V2 0/5] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage Date: Wed, 11 Nov 2020 19:49:24 -0600 Message-ID: <20201112014929.25227-1-nm@ti.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201111_204946_459616_88AE0760 X-CRM114-Status: GOOD ( 13.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, 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. The dtb changes are limited to be functionaly equivalent similar to what was published with v1. dtb-> dts decompiled a) As of v5.10-rc1: am654: https://pastebin.ubuntu.com/p/G4P5vghpV3/ j721e: https://pastebin.ubuntu.com/p/HWXmTwD6m8/ j7200: https://pastebin.ubuntu.com/p/SsG6JtPzR9/ b) with this series applied: am654: https://pastebin.ubuntu.com/p/pGdpbPQvyd/ j721e: https://pastebin.ubuntu.com/p/PWcNMdtj5J/ j7200: https://pastebin.ubuntu.com/p/NFxpNtyNr9/ Boot test logs(base v5.10-rc1): am654: https://pastebin.ubuntu.com/p/pNngXcWy23/ j721e: https://pastebin.ubuntu.com/p/xjbXkHb7Gv/ j7200: https://pastebin.ubuntu.com/p/dn7MgfJJ2j/ 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/