From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B40DC43334 for ; Thu, 7 Jul 2022 15:01:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236082AbiGGPBt (ORCPT ); Thu, 7 Jul 2022 11:01:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236118AbiGGPBi (ORCPT ); Thu, 7 Jul 2022 11:01:38 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A665017068; Thu, 7 Jul 2022 08:01:37 -0700 (PDT) Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 267F1V9o066777; Thu, 7 Jul 2022 10:01:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1657206091; bh=XOH9YNTfoGbrNEDgBlKe0BZK5m9Ciqon/unFihTQeyc=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=XSObTcqMqCA8aQ6Y4lTIxPb3yvtPGkbq78LY8lUiqK/K5FV0vt5dLtmjXwGYOT444 bghT9SwGBC3G9tX9m5J/J/FaY1GHvz9SKMzTIKVKeJI36PQgS2/92jGUQJUA11TmC5 u0purN4QsfoTTLLUko+/qDLsrfwE4hhk+XMO9YvI= Received: from DFLE106.ent.ti.com (dfle106.ent.ti.com [10.64.6.27]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 267F1Vdr052741 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Jul 2022 10:01:31 -0500 Received: from DFLE101.ent.ti.com (10.64.6.22) by DFLE106.ent.ti.com (10.64.6.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Thu, 7 Jul 2022 10:01:31 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE101.ent.ti.com (10.64.6.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Thu, 7 Jul 2022 10:01:31 -0500 Received: from [10.250.33.129] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 267F1UX6061311; Thu, 7 Jul 2022 10:01:30 -0500 Message-ID: Date: Thu, 7 Jul 2022 10:01:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 1/4] arm64: dts: ti: k3-am65-main: Disable RNG node Content-Language: en-US To: Bryan Brattlof CC: Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , , , References: <20220706190838.26074-1-afd@ti.com> <20220707144400.tk3wmpeijdhuxpzv@bryanbrattlof.com> From: Andrew Davis In-Reply-To: <20220707144400.tk3wmpeijdhuxpzv@bryanbrattlof.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/7/22 9:44 AM, Bryan Brattlof wrote: > Hi Andrew > > On July 6, 2022 thus sayeth Andrew Davis: >> The hardware random number generator is used by OP-TEE and is access is >> denied to other users with SoC level bus firewalls. Any access to this >> device from Linux will result in firewall errors. Disable this node. >> >> Signed-off-by: Andrew Davis >> --- >> >> Changes from v1: >> - Added comment in dtsi file >> >> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> index e749343accedd..9de5a8294acd6 100644 >> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> @@ -127,6 +127,7 @@ rng: rng@4e10000 { >> reg = <0x0 0x4e10000 0x0 0x7d>; >> interrupts = ; >> clocks = <&k3_clks 136 1>; >> + status = "disabled"; /* Used by OP-TEE */ > > Just curious about how we should document disabling nodes. I was > assuming the reasoning should be described in the bindings? > > I would like to start disabling nodes by default in our dtsi files and > enabling them in our top dts file, making it easier for others to use > our device tree for a more focused purpose than our dev boards. I just > didn't know where I should document why I disabled the nodes :) > This got push-back last time this was suggested, I'll have to lookup the history. IIRC we landed on the other way around, all things should be described by default, then the specific board can enable/disable what is not used as needed. I was worried this topic would come up with this patch series and was almost just going to delete the whole RNG node instead of disabling it to avoid that. My reasoning for disabling here anyway is that this device *cannot* be used by *any* board, it is not just a board level configuration decision like disabling I2C nodes by default or similar that was proposed last time we had the "nodes disabled by default" discussion. Andrew > ~Bryan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55ACAC433EF for ; Thu, 7 Jul 2022 15:02:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=msrw1nLHmOg9AxJYogXpJl4bDr7+e35yhhU4XHq3wz0=; b=VPAtC03CAudVt9 tonNCsKvjUmRVYp93gESITWoaDPehs242dMwjoJKuufc+CPEjl81plp5AyG9rGb3bsS4Pe9AADBFz /nTqvYvQiTPxU5GP7+GmhtTxfzyMnzEu6OuvIGmgNHayk6lSqRVO92aen1PGRbQPAgXHpotl1tmnC 9jdQeuKI4xknIMC3FsET1Sb/WzGFdUdKssVlPN2ioSmXlFQ10h9zkkH4OhuYsmZPpXtsdVKeFasEM qK8BF1jGkUL8s+2tuiFGOMYb1B0+1loOEo5TGVE2EjWtLhxW9OeTZY9+ivw8UHlb1McrCUDZakSOh VFP+O7pwd/L/kJWXNvqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9T0d-00GfsS-8y; Thu, 07 Jul 2022 15:01:39 +0000 Received: from lelv0142.ext.ti.com ([198.47.23.249]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9T0Y-00Gfr3-RX for linux-arm-kernel@lists.infradead.org; Thu, 07 Jul 2022 15:01:36 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 267F1V9o066777; Thu, 7 Jul 2022 10:01:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1657206091; bh=XOH9YNTfoGbrNEDgBlKe0BZK5m9Ciqon/unFihTQeyc=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=XSObTcqMqCA8aQ6Y4lTIxPb3yvtPGkbq78LY8lUiqK/K5FV0vt5dLtmjXwGYOT444 bghT9SwGBC3G9tX9m5J/J/FaY1GHvz9SKMzTIKVKeJI36PQgS2/92jGUQJUA11TmC5 u0purN4QsfoTTLLUko+/qDLsrfwE4hhk+XMO9YvI= Received: from DFLE106.ent.ti.com (dfle106.ent.ti.com [10.64.6.27]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 267F1Vdr052741 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Jul 2022 10:01:31 -0500 Received: from DFLE101.ent.ti.com (10.64.6.22) by DFLE106.ent.ti.com (10.64.6.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Thu, 7 Jul 2022 10:01:31 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE101.ent.ti.com (10.64.6.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Thu, 7 Jul 2022 10:01:31 -0500 Received: from [10.250.33.129] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 267F1UX6061311; Thu, 7 Jul 2022 10:01:30 -0500 Message-ID: Date: Thu, 7 Jul 2022 10:01:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 1/4] arm64: dts: ti: k3-am65-main: Disable RNG node Content-Language: en-US To: Bryan Brattlof CC: Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , , , References: <20220706190838.26074-1-afd@ti.com> <20220707144400.tk3wmpeijdhuxpzv@bryanbrattlof.com> From: Andrew Davis In-Reply-To: <20220707144400.tk3wmpeijdhuxpzv@bryanbrattlof.com> 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-20220707_080135_024489_C5691556 X-CRM114-Status: GOOD ( 22.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/7/22 9:44 AM, Bryan Brattlof wrote: > Hi Andrew > > On July 6, 2022 thus sayeth Andrew Davis: >> The hardware random number generator is used by OP-TEE and is access is >> denied to other users with SoC level bus firewalls. Any access to this >> device from Linux will result in firewall errors. Disable this node. >> >> Signed-off-by: Andrew Davis >> --- >> >> Changes from v1: >> - Added comment in dtsi file >> >> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> index e749343accedd..9de5a8294acd6 100644 >> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> @@ -127,6 +127,7 @@ rng: rng@4e10000 { >> reg = <0x0 0x4e10000 0x0 0x7d>; >> interrupts = ; >> clocks = <&k3_clks 136 1>; >> + status = "disabled"; /* Used by OP-TEE */ > > Just curious about how we should document disabling nodes. I was > assuming the reasoning should be described in the bindings? > > I would like to start disabling nodes by default in our dtsi files and > enabling them in our top dts file, making it easier for others to use > our device tree for a more focused purpose than our dev boards. I just > didn't know where I should document why I disabled the nodes :) > This got push-back last time this was suggested, I'll have to lookup the history. IIRC we landed on the other way around, all things should be described by default, then the specific board can enable/disable what is not used as needed. I was worried this topic would come up with this patch series and was almost just going to delete the whole RNG node instead of disabling it to avoid that. My reasoning for disabling here anyway is that this device *cannot* be used by *any* board, it is not just a board level configuration decision like disabling I2C nodes by default or similar that was proposed last time we had the "nodes disabled by default" discussion. Andrew > ~Bryan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel