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 84C22C433EF for ; Wed, 9 Mar 2022 09:13:15 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dMY54AOHgKxnfUFoA42pmdvgLRIwHMdiUHmspknExdU=; b=DhUEuONL+haC9C uSG/MkqASlTJ7L7OjaLPvKL222nULAmShgZzlEaK6Rg6ZKt0CEGZnbNzVtqsdrGG3lz5lIDJyKe6F P9OkAyS757kukVTEf6EUDOra8+lMQJcftludB/evTJQ31GPIWj5zmRgsdLS84l9mE29MLCXRd6H6L VzrPOGXK8rt12rHG3Ezt6/pvuSAfrStcFhVyb6TmwZHN5FluIExbGa7inNRXtONBHWbhJ5UqBRIXy n6F29U+JN1TiB9r0dmUJazcsWMvpvFnOngepe2FCvaQYh5Tv9DI/bBndFTaD8XXm5EDXtSvEU7qDX j4RYhfhTmPLKQu3jeU/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRsMV-007rbE-EM; Wed, 09 Mar 2022 09:12:03 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRsMQ-007rac-Vh for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 09:12:01 +0000 Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 5E87280C1; Wed, 9 Mar 2022 09:10:30 +0000 (UTC) Date: Wed, 9 Mar 2022 11:11:52 +0200 From: Tony Lindgren To: Matthias Schiffer Cc: Rob Herring , Arnd Bergmann , Olof Johansson , soc@kernel.org, Vignesh Raghavendra , Tero Kristo , jan.kiszka@siemens.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Nishanth Menon Subject: Re: [PATCH v2 1/2] arm64: dts: ti: k3-am65: disable optional peripherals by default Message-ID: References: <20220203140240.973690-1-matthias.schiffer@ew.tq-group.com> <20220204143108.653qk2ihnlhsr5aa@prior> <5944ba0ce568eaf507917799b1dfd89a3d0ca492.camel@ew.tq-group.com> <9923df6525212389b86cb635624bcfb5c27a8bc5.camel@ew.tq-group.com> <1356e93cd5b101c3d896e35250c66959ed631544.camel@ew.tq-group.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1356e93cd5b101c3d896e35250c66959ed631544.camel@ew.tq-group.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_011200_698627_22F54FEC X-CRM114-Status: GOOD ( 14.88 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, * Matthias Schiffer [220228 10:29]: > AFAICT, disabling non-operatational devices in the board DTS instead of > the SoC DTSI is worse than the alternatives in every way: > > - Verbose board DTS: You have to think about all the devices that exist > in the SoC, not just the ones you want to use > - Adding new nodes without `status = "disabled" to SoC DTSI can > potentially cause issues on dependent boards > - It doesn't solve the issues that not having `status = "disabled"` in > the DTSI is supposed to solve My preference is the least amount of tinkering in the dts files naturally :) It really does not matter if the extra dts churn is to enable or disable devices, it should not be needed at all. To summarize, my main point really is the following: There should not be any need to tag the SoC internal devices with anything in the dts files. The device drivers should be able to just deal with the situation. IMO devices should be tagged with disabled or reserved when they are not accessible for example because of being used by secure mode for example. If the the status needs to be set to anything, it really is a symptom of incomplete handling somewhere. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel