From: Rob Herring <robh@kernel.org> To: Gatien CHEVALLIER <gatien.chevallier@foss.st.com> 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 <frowand.list@gmail.com>, 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 Date: Tue, 24 Oct 2023 11:39:56 -0500 [thread overview] Message-ID: <20231024163956.GA4049342-robh@kernel.org> (raw) In-Reply-To: <b16ed06f-66fd-457b-9610-a67ad07deb60@foss.st.com> 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 <gatien.chevallier@foss.st.com> > > > > > --- > > > > > > > > > > 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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Gatien CHEVALLIER <gatien.chevallier@foss.st.com> 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 <frowand.list@gmail.com>, 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 Date: Tue, 24 Oct 2023 11:39:56 -0500 [thread overview] Message-ID: <20231024163956.GA4049342-robh@kernel.org> (raw) In-Reply-To: <b16ed06f-66fd-457b-9610-a67ad07deb60@foss.st.com> 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 <gatien.chevallier@foss.st.com> > > > > > --- > > > > > > > > > > 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
next prev parent reply other threads:[~2023-10-24 16:40 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-10 12:57 [PATCH v6 00/11] Introduce STM32 Firewall framework Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 01/11] dt-bindings: document generic access controllers Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 02/11] dt-bindings: treewide: add access-controllers description Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 03/11] dt-bindings: bus: document RIFSC Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 04/11] dt-bindings: bus: document ETZPC Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 05/11] firewall: introduce stm32_firewall framework Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 06/11] of: property: fw_devlink: Add support for "access-controller" Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 07/11] bus: rifsc: introduce RIFSC firewall controller driver Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 08/11] arm64: dts: st: add RIFSC as an access controller for STM32MP25x boards Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 09/11] bus: etzpc: introduce ETZPC firewall controller driver Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` [PATCH v6 10/11] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 18:42 ` Rob Herring 2023-10-10 18:42 ` Rob Herring 2023-10-11 8:49 ` Gatien CHEVALLIER 2023-10-11 8:49 ` Gatien CHEVALLIER 2023-10-12 15:30 ` Rob Herring 2023-10-12 15:30 ` Rob Herring 2023-10-16 12:02 ` Gatien CHEVALLIER 2023-10-16 12:02 ` Gatien CHEVALLIER 2023-10-24 16:39 ` Rob Herring [this message] 2023-10-24 16:39 ` Rob Herring 2023-10-27 15:37 ` Gatien CHEVALLIER 2023-11-27 13:46 ` Gatien CHEVALLIER 2023-11-27 13:46 ` Gatien CHEVALLIER 2023-10-10 12:57 ` [PATCH v6 11/11] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier 2023-10-10 12:57 ` Gatien Chevallier
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20231024163956.GA4049342-robh@kernel.org \ --to=robh@kernel.org \ --cc=Oleksii_Moisieiev@epam.com \ --cc=alexandre.torgue@foss.st.com \ --cc=alsa-devel@alsa-project.org \ --cc=andi.shyti@kernel.org \ --cc=arnaud.pouliquen@foss.st.com \ --cc=arnd@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=conor+dt@kernel.org \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=dmaengine@vger.kernel.org \ --cc=edumazet@google.com \ --cc=fabrice.gasnier@foss.st.com \ --cc=frowand.list@gmail.com \ --cc=gatien.chevallier@foss.st.com \ --cc=gregkh@linuxfoundation.org \ --cc=herbert@gondor.apana.org.au \ --cc=hugues.fruchet@foss.st.com \ --cc=jic23@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kuba@kernel.org \ --cc=lee@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-iio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-p.hy@lists.infradead.org \ --cc=linux-serial@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=linux-usb@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=olivier.moysan@foss.st.com \ --cc=pabeni@redhat.com \ --cc=peng.fan@oss.nxp.com \ --cc=richardcochran@gmail.com \ --cc=ulf.hansson@linaro.org \ --cc=vkoul@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.