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 B1A66C433F5 for ; Tue, 8 Feb 2022 10:55:01 +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=Rrf6lsjZAlgEnN8s8kHnDgjEIzbOGhWfhRRs8HFfgDM=; b=mAmMtYFu2+bx+2 qr7BJBp0aMCtqhW2P6C5eAEWavmx6njRYMA1N9EJnp+Jhhr5PZ79tSHJeHAxsLvt6HJRmXwnPWHHu yjctVWDpINipqnLbKYEREV6I7w1FTvhOFxDXgv+ZdgT+i1RgGFmrC8397opRrKhHgP0/26X3SEaIz byG4ps9rt2Sj/M8Wa6LPNQXaxkcgwC6TpwW3OyFnzo+WZM+SQijpEN62Ir3irw/7Qlbs9F3nHxISq yPh6cUlIU9zyRQAQFfH6jlh4McTYeDZkb8pYxdnQtOVVA2l/oUejC6L8ppr9uCRddECjhmgupVBbc xq8ll4gjgzAniTQVnP6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHO7w-00DTVT-Vg; Tue, 08 Feb 2022 10:53:41 +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 1nHO7q-00DTSK-W2 for linux-arm-kernel@lists.infradead.org; Tue, 08 Feb 2022 10:53:38 +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=1644317615; x=1675853615; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=UbrGQyvULXin7BBC8wqdS8uqSO3Rl+MipBC4/fpyAFA=; b=cDCLFqFd6MFjsVk/dWBPFPb3Z6zjZJQxt6X9sscgAGT3YY6Qz1ZARNjG iaEIuJl2aMtLrvY6qq+xCjen8EeMjkZwCqGLLM/ZazofYr52xUqgJYyxf TwKQo5m/yn+DWKfbAMEjMLpfzbCEYTzcDLzP2GR73713JP1aefaDS8cJ2 0MXK2IeQn8CyoihnMYyeoLodhHLfve7D73WDVdsuGIhTsBo5m5bc4Cr7i leuSZ2aGFOKnfbs7wGAvZqf3+UzXkdWUSmYsSc0SCfwRWcjidnHeC0VOi g/Xhe3LYpPQjT9ZtOrmdZDQ1hqzKx4dNVOzXbjx2DtJFa18sfvmddaN5b Q==; X-IronPort-AV: E=Sophos;i="5.88,352,1635199200"; d="scan'208";a="21957534" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 08 Feb 2022 11:53:29 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Tue, 08 Feb 2022 11:53:29 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Tue, 08 Feb 2022 11:53:29 +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=1644317609; x=1675853609; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=UbrGQyvULXin7BBC8wqdS8uqSO3Rl+MipBC4/fpyAFA=; b=VWnvEgqtDGvLWpFibWP78PUxgQe4FS9HDx/QNP3mgMele6QiMfx+TOYn WkoDBxcdmrChiv28+5qECk6WOShr8EBEiPiDAxgB8FEY+JNyuD1C279JE oTAac32IfRRg1AFGZE5pcLbT9thlMFtvb4uHPVB3wB6EdbDdfWp5jnjfx SBa8eo5NFRVDC2wSbEmWtFvMLn9xXghyL+KYLcGmfUOY3JOcNHuoIz/30 Ap9danfx8+pIpDiK2VyIo3puV44kUkzyGG4drWcxVtrFtB40sYM5zKXdp hOHeKy7XtK628/97U7w9Z9THRGrW4zXI+t3XFMUJvsuHjfwrMFrSn2RVz Q==; X-IronPort-AV: E=Sophos;i="5.88,352,1635199200"; d="scan'208";a="21957533" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 08 Feb 2022 11:53:29 +0100 Received: from schifferm-ubuntu (SCHIFFERM-M2.tq-net.de [10.121.201.138]) by vtuxmail01.tq-net.de (Postfix) with ESMTPA id 3B223280065; Tue, 8 Feb 2022 11:53:29 +0100 (CET) Message-ID: <9923df6525212389b86cb635624bcfb5c27a8bc5.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: Tue, 08 Feb 2022 11:53:27 +0100 In-Reply-To: References: <20220203140240.973690-1-matthias.schiffer@ew.tq-group.com> <20220204143108.653qk2ihnlhsr5aa@prior> <5944ba0ce568eaf507917799b1dfd89a3d0ca492.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-20220208_025335_471973_8AE651A8 X-CRM114-Status: GOOD ( 31.56 ) 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 Mon, 2022-02-07 at 13:25 +0200, Tony Lindgren wrote: > * Matthias Schiffer [220207 > 08:45]: > > Generally I think that it's a bootloader's responsiblity to disable > > unneeded devices - the kernel may not even have a driver for some > > peripherals, leading to the same behaviour as a "disabled" status. > > For > > this reason I believe that it should always be okay to set unneeded > > devices to "disabled", and it should be considered a safe default. > > Not possible, think kexec for example :) How would the previous > kernel > even know what to disable if Linux has no idea about the devices? Well, optimally, bootloader and all kernels would agree on the devices that are actually available, but I get your point. > > If there are issues you're seeing, it's likely a bug in some of the > device drivers for not checking for the necessary resources like > pinctrl for i2c lines. I don't think it's common for individual drivers to care about pinctrl unless switching between different pin settings is required at runtime. Many drivers can be used on different hardware, some of which may require pinmuxing, while others don't. Also, what is the expected behavior of a driver that is probed for an unusable device? Wouldn't this require some as-of-yet nonexisting status between "okay" and "disabled" that conveys something like "probe this device, initialize (and disable) PM, but don't register anything", so no unusable devices become visible to userspace (and possibly other kernel drivers)? > > > I'm not sure what the consensus on these issues is. I'm more > > familiar > > with NXP's i.MX and Layerscape SoCs, where it's common to have all > > muxable peripherals set to "disabled" in the base DTSI, and a quick > > grep through a few dts directories gives me the impression that > > this is > > the case for most other vendors as well. > > This approach only works for SoCs that don't need the kernel to idle > devices for runtime PM. I'm pretty sure that most modern SoCs I looked at have runtime PM, and it is simply expected that unusable devices are never enabled in the first place, so there is no need for the kernel to know about them. Regards, Matthias > Regards, > > Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel