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 F2F47C433EF for ; Wed, 9 Mar 2022 11:12:24 +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:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=roFuWFY1N5FgKasDXo1iqEE/WaIqkixIp1BzLjbirH0=; b=YRh2e1Iv+AGNIE LcNaxqM5YfKHy9pDoovVNZMV/M49B9N+Ioh0k1JNlDSqOw/gfa4wvQlIcAo20QqApR7xMEYQ1iMI3 wF4MtHXWt829eJfeTG84m49CTRVT5ngKx2P41CoBN8IKUckTzxBWggKVsad07MvRI1B7/vp3xh/ku T3d4QHy5H/nlRy07kuCW6uBN4XkUr1UzZbpvOuXQZtKDsitn24t6BljAk5kNzEeKAgtzhM+awJQcQ py+wEicVEMHmeSDcwUi+8DZegFzYNuWwPDDWyiSMqsV/LkxOWb4YZa3GAMesoteUFyPEG2dxdvJfs PSsWT1JYG76KWGKTatlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuDe-008ExQ-NM; Wed, 09 Mar 2022 11:11:02 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuDa-008Evb-81 for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 11:11:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1646824258; x=1678360258; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=dxI4nXP7eM1KVmcUxjIZ4iLcGWg/tOi5lpYWVmRNw8c=; b=V1+xexJWheWu80qseGe9LT53VEM9StLxm57zee5QmGmgYcUj1YSLoooV hehXKXYoNsLe3YIcGBwwNqDU/XIE3zgQ1z4texe2WscbzC5omD8qIY3VD ej4wWWJsNau3eZ1intls8O3p0Poly8Pr1++mbLdk1WXLauxIGlMQX3Usc uCY4FJ48LD2ijAJWhEGUKXG2tNh9a4Zb2RIKRr06XTfAS0Zu5eGWGhAyB 9nTZx8/AouYtWZ5XFVfkUrlmWG9X/kcVjLEWCCMG8geftdmFNeY9Eb1G1 l++9c4YkgKh5JbWgeBNnDSjFUhpiJe5o7/atf6hsubXo7SH/HLHwPDseR Q==; X-IronPort-AV: E=Sophos;i="5.90,167,1643670000"; d="scan'208";a="22552465" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 09 Mar 2022 12:10:52 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Wed, 09 Mar 2022 12:10:52 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Wed, 09 Mar 2022 12:10:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1646824252; x=1678360252; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=dxI4nXP7eM1KVmcUxjIZ4iLcGWg/tOi5lpYWVmRNw8c=; b=EGizE3/6voXt8P5WzuiMrx+1raQrzAtvbdyzvQzDkc1e+Am+qA9uvpH+ Du9caJqQgix6b4p6XpLVNC7OaF6/Iz6jx7k8wbC2qx5YcaQ1+3UZBp/QI xChbDLvEqMbZeyuG6+gUbu6F6c+oBlfuO2MzCL/b4JnoZ8aa9yhSdje/6 787oyRdPNm7rLs1/B6gq2sObS8OjVnzTW6B0uh8K9vBtzBCqqxsk9PcDC C0Z8bmHr3d2LbxVhGuFGQ1obHtDKhS47qaiUjmOqNamPBjXPvaqKctowo va8zabHam8vbvHcwxuQl+VB9kqbJuuE77yqPkCE/TzKriji5kPv/WW2Dr A==; X-IronPort-AV: E=Sophos;i="5.90,167,1643670000"; d="scan'208";a="22552464" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 09 Mar 2022 12:10:52 +0100 Received: from schifferm-ubuntu (SCHIFFERM-M2.tq-net.de [10.121.201.138]) by vtuxmail01.tq-net.de (Postfix) with ESMTPA id 6E6CD280065; Wed, 9 Mar 2022 12:10:52 +0100 (CET) Message-ID: <5058591a3e0f0cb82b26cffe888d87b4d1bdd713.camel@ew.tq-group.com> Subject: Re: [PATCH v2 1/2] arm64: dts: ti: k3-am65: disable optional peripherals by default From: Matthias Schiffer To: Tony Lindgren 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 Date: Wed, 09 Mar 2022 12:10:50 +0100 In-Reply-To: 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> User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_031058_632913_89DCE8AA X-CRM114-Status: GOOD ( 29.45 ) 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 On Wed, 2022-03-09 at 11:11 +0200, Tony Lindgren wrote: > 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 Hi Tony, while I agree that it would be great if drivers could just detect when hardware is not available, this is simply not how most drivers work - when you instantiate the driver via a non-disabled(/reserved/...) DT node, the driver expects a usable device. Especially for busses like I2C, there is no way for a driver to reliably detect whether the bus is usable or not. (There are several states that can't really be distinguished: Is pinmuxing missing, or does the device not need any muxing? Is a line low because it is not actually connected to anything, or is there another master currently using the bus, or is the bus stuck due to a faulty device?) Which is why it is the convention for SoC DTSI files disable nodes for devices that may be unusable. Taking UARTs as an example, a quick grep for "serial@" nodes in arch/arm/boot/dts/*.dtsi and arch/arm64/boot/dts/*/*.dtsi shows that the vast majority of these nodes is disabled by default. Regards, Matthias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel