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 E3B7BC00A8F for ; Tue, 24 Oct 2023 16:40:35 +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=F1L+w3MOAw+OqrstO9eWC+dNqMzOqPOgz6UpN7hz0KU=; b=26mepPOxtFyTca hjMoWiAp1wuQ1zqp9zbEo8CcBYGh+qYmdPd/WzB1jDpjP3pLXZk+tvHkKTxQJ9h71361qfwzILczj nlrhSQQ8L3dOMLNQAiuP5M+Okh9AYdhgf3Y/EeEW8Tuhpk+8O/duZM667Ojh4RdTmNVKq+T+JMEVe PuANO1uHvyjYY8x0Y1FOZUlbo9HONjQtToqSDc1dLtokfcsyLAGVe4nu4vKsZCtnit6rpcvwi6tIm B3aU2XWYVVuX9b9wXsOi5BPuMG4FNjAC0h9RdEVm1OdEbgupvdVBBNI1byUw60o6Ljg5CePh4Jhm/ wAIeygdicP9L5NKiSMgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qvKRu-00AWgI-2K; Tue, 24 Oct 2023 16:40:10 +0000 Received: from mail-oo1-f45.google.com ([209.85.161.45]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qvKRl-00AWbN-28 for linux-arm-kernel@lists.infradead.org; Tue, 24 Oct 2023 16:40:03 +0000 Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-581de3e691dso2712303eaf.3; Tue, 24 Oct 2023 09:40:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698165599; x=1698770399; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4dgLAi1M/nR9fJIQpQVSn3gxY5AOxSN1+8PQWp2ZK3E=; b=Xq4eCdFokjgiCUSSwcV1CmchUfXnPiTcah1ALL8+Njum7pG095qMy30awxKM3cjIsZ KbtX922UxgCmSRfYPKc8zWSr1XI6VKnYWmnLPlWliXPZO/pZVkslm46Zv0i3EO2yxvy3 DD3pp7qjoPPmJu8c9aIB7QrbGezFJ0zIrNbPXZLHHDKzJ7TRy6OwamQdmDvIXslvvZg6 bQtx+NF91RIxuiAW+oRaJot3D2notzMndZE1PbMDPVAnAAHYgXpiwooyLBYBPOCR4D3h /Ryik+56a6g0T4EEa/dXmAcTfkWhjaxAaUGmwIQnr3d1nstZ0vnXEXQnmRHXiQmQ3EAc wKrw== X-Gm-Message-State: AOJu0YyA2Ww9/ivNwIL+Zsi7CO6KseZm0QURE2meWL1CkK8hg1IU2r5G +wSHOU3wZQGySZp8mpUKKA== X-Google-Smtp-Source: AGHT+IH7r1RypTRYYRKdrh1wNi7leTTNBWI9FBY2oTxpLiREvX3LYW7p4YgROHwYcoRP/a6v+9+WQw== X-Received: by 2002:a4a:df11:0:b0:582:28e:93a8 with SMTP id i17-20020a4adf11000000b00582028e93a8mr12468463oou.3.1698165599325; Tue, 24 Oct 2023 09:39:59 -0700 (PDT) Received: from herring.priv (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id f22-20020a4ad816000000b0057aef3cab33sm2002659oov.21.2023.10.24.09.39.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 09:39:58 -0700 (PDT) Received: (nullmailer pid 4062523 invoked by uid 1000); Tue, 24 Oct 2023 16:39:56 -0000 Date: Tue, 24 Oct 2023 11:39:56 -0500 From: Rob Herring To: Gatien CHEVALLIER Cc: Oleksii_Moisieiev@epam.com, gregkh@linuxfoundation.org, herbert@gondor.apana.org.au, davem@davemloft.net, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, alexandre.torgue@foss.st.com, vkoul@kernel.org, jic23@kernel.org, olivier.moysan@foss.st.com, arnaud.pouliquen@foss.st.com, mchehab@kernel.org, fabrice.gasnier@foss.st.com, andi.shyti@kernel.org, ulf.hansson@linaro.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, hugues.fruchet@foss.st.com, lee@kernel.org, will@kernel.org, catalin.marinas@arm.com, arnd@kernel.org, richardcochran@gmail.com, Frank Rowand , peng.fan@oss.nxp.com, linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-i2c@vger.kernel.org, linux-iio@vger.kernel.org, alsa-devel@alsa-project.org, linux-media@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-p.hy@lists.infradead.org, linux-serial@vger.kernel.org, linux-spi@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v6 10/11] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards Message-ID: <20231024163956.GA4049342-robh@kernel.org> References: <20231010125719.784627-1-gatien.chevallier@foss.st.com> <20231010125719.784627-11-gatien.chevallier@foss.st.com> <20231010184212.GA1221641-robh@kernel.org> <8f1b6915-68be-a525-c5d5-37f0983c14de@foss.st.com> <20231012153012.GA698406-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231024_094001_701245_91292E15 X-CRM114-Status: GOOD ( 42.61 ) 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, Oct 16, 2023 at 02:02:39PM +0200, Gatien CHEVALLIER wrote: > Hi Rob, > > On 10/12/23 17:30, Rob Herring wrote: > > On Wed, Oct 11, 2023 at 10:49:58AM +0200, Gatien CHEVALLIER wrote: > > > Hi Rob, > > > > > > On 10/10/23 20:42, Rob Herring wrote: > > > > On Tue, Oct 10, 2023 at 02:57:18PM +0200, Gatien Chevallier wrote: > > > > > ETZPC is a firewall controller. Put all peripherals filtered by the > > > > > ETZPC as ETZPC subnodes and reference ETZPC as an > > > > > access-control-provider. > > > > > > > > > > For more information on which peripheral is securable or supports MCU > > > > > isolation, please read the STM32MP15 reference manual. > > > > > > > > > > Signed-off-by: Gatien Chevallier > > > > > --- > > > > > > > > > > Changes in V6: > > > > > - Renamed access-controller to access-controllers > > > > > - Removal of access-control-provider property > > > > > > > > > > Changes in V5: > > > > > - Renamed feature-domain* to access-control* > > > > > > > > > > arch/arm/boot/dts/st/stm32mp151.dtsi | 2756 +++++++++++++------------ > > > > > arch/arm/boot/dts/st/stm32mp153.dtsi | 52 +- > > > > > arch/arm/boot/dts/st/stm32mp15xc.dtsi | 19 +- > > > > > 3 files changed, 1450 insertions(+), 1377 deletions(-) > > > > > > > > This is not reviewable. Change the indentation and any non-functional > > > > change in one patch and then actual changes in another. > > > > > > Ok, I'll make it easier to read. > > > > > > > > > > > This is also an ABI break. Though I'm not sure it's avoidable. All the > > > > devices below the ETZPC node won't probe on existing kernel. A > > > > simple-bus fallback for ETZPC node should solve that. > > > > > > > > > > I had one issue when trying with a simple-bus fallback that was the > > > drivers were probing even though the access rights aren't correct. > > > Hence the removal of the simple-bus compatible in the STM32MP25 patch. > > > > But it worked before, right? So the difference is you have either added > > new devices which need setup or your firmware changed how devices are > > setup (or not setup). Certainly can't fix the latter case. You just need > > to be explicit about what you are doing to users. > > > > I should've specified it was during a test where I deliberately set > incorrect rights on a peripheral and enabled its node to see if the > firewall would allow the creation of the device. > > > > > > Even though a node is tagged with the OF_POPULATED flag when checking > > > the access rights with the firewall controller, it seems that when > > > simple-bus is probing, there's no check of this flag. > > > > It shouldn't. Those flags are for creating the devices (or not) and > > removing only devices of_platform_populate() created. > > > > About the "simple-bus" being a fallback, I think I understood why I saw > that the devices were created. > > All devices under a node whose compatible is "simple-bus" are created > in of_platform_device_create_pdata(), called by > of_platform_default_populate_init() at arch_initcall level. This > before the firewall-controller has a chance to populate it's bus. > > Therefore, when I flag nodes when populating the firewall-bus, the > devices are already created. The "simple-bus" mechanism is not a > fallback here as it precedes the driver probe. > > Is there a safe way to safely remove/disable a device created this way? There's 2 ways to handle this. Either controlling creating the device or controlling probing the device. The latter should just work with fw_devlink dependency. The former probably needs some adjustment to simple-pm-bus driver if you have 'simple-bus' compatible. You want it to probe on old kernels and not probe on new kernels with your firewall driver. Look at the commit history for simple-pm-bus. There was some discussion on it as well. > Devices that are under the firewall controller (simple-bus) node > should not be probed before it as they're child of it. fw_devlink should take care of parent/child dependencies without any explicit handling of the access ctrl binding. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel