From: Simon Horman <simon.horman@corigine.com>
To: Gatien CHEVALLIER <gatien.chevallier@foss.st.com>
Cc: Oleksii_Moisieiev@epam.com, gregkh@linuxfoundation.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
robh+dt@kernel.org, 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>,
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-phy@lists.infradead.org, linux-serial@vger.kernel.org,
linux-spi@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 05/11] firewall: introduce stm32_firewall framework
Date: Wed, 26 Jul 2023 13:39:42 +0200 [thread overview]
Message-ID: <ZMEF/gR6fmmC7jhF@corigine.com> (raw)
In-Reply-To: <d228e17b-4f5f-d5e0-1c59-d247cbc0693e@foss.st.com>
On Wed, Jul 26, 2023 at 12:38:00PM +0200, Gatien CHEVALLIER wrote:
>
>
> On 7/26/23 12:19, Simon Horman wrote:
> > On Tue, Jul 25, 2023 at 06:40:58PM +0200, Gatien Chevallier wrote:
> > > Introduce a STM32 firewall framework that offers to firewall consumers
> > > different firewall services such as the ability to check their access
> > > rights against their firewall controller(s).
> > >
> > > The STM32 firewall framework offers a generic API for STM32 firewall
> > > controllers that is defined in their drivers to best fit the
> > > specificity of each firewall.
> > >
> > > There are various types of firewalls:
> > > -Peripheral firewalls that filter accesses to peripherals
> > > -Memory firewalls that filter accesses to memories or memory regions
> > > -No type for undefined type of firewall
> > >
> > > Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> >
> > ...
> >
> > > diff --git a/drivers/bus/stm32_firewall.c b/drivers/bus/stm32_firewall.c
> >
> > ...
> >
> > > +int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller)
> > > +{
> > > + struct stm32_firewall *firewalls;
> > > + struct device_node *child;
> > > + struct device *parent;
> > > + unsigned int i;
> > > + int len;
> > > + int err;
> > > +
> > > + parent = firewall_controller->dev;
> > > +
> > > + dev_dbg(parent, "Populating %s system bus\n", dev_name(firewall_controller->dev));
> > > +
> > > + for_each_available_child_of_node(dev_of_node(parent), child) {
> > > + /* The feature-domains property is mandatory for firewall bus devices */
> > > + len = of_count_phandle_with_args(child, "feature-domains", "#feature-domain-cells");
> > > + if (len <= 0)
> >
> > Coccinelle says that, due to breaking out of a
> > for_each_available_child_of_node() loop, a call to of_node_put()
> > is needed here
> >
>
> Hi Simon,
>
> Thank you, I already sent a V3 correcting the patch ordering issue. I
> will implement this for V4.
Hi Gatien,
Thanks and sorry for not noticing v3 - I think it arrived while
I was in the middle of reviewing v2.
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <simon.horman@corigine.com>
To: Gatien CHEVALLIER <gatien.chevallier@foss.st.com>
Cc: Oleksii_Moisieiev@epam.com, gregkh@linuxfoundation.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
robh+dt@kernel.org, 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>,
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-phy@lists.infradead.org, linux-serial@vger.kernel.org,
linux-spi@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 05/11] firewall: introduce stm32_firewall framework
Date: Wed, 26 Jul 2023 13:39:42 +0200 [thread overview]
Message-ID: <ZMEF/gR6fmmC7jhF@corigine.com> (raw)
In-Reply-To: <d228e17b-4f5f-d5e0-1c59-d247cbc0693e@foss.st.com>
On Wed, Jul 26, 2023 at 12:38:00PM +0200, Gatien CHEVALLIER wrote:
>
>
> On 7/26/23 12:19, Simon Horman wrote:
> > On Tue, Jul 25, 2023 at 06:40:58PM +0200, Gatien Chevallier wrote:
> > > Introduce a STM32 firewall framework that offers to firewall consumers
> > > different firewall services such as the ability to check their access
> > > rights against their firewall controller(s).
> > >
> > > The STM32 firewall framework offers a generic API for STM32 firewall
> > > controllers that is defined in their drivers to best fit the
> > > specificity of each firewall.
> > >
> > > There are various types of firewalls:
> > > -Peripheral firewalls that filter accesses to peripherals
> > > -Memory firewalls that filter accesses to memories or memory regions
> > > -No type for undefined type of firewall
> > >
> > > Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> >
> > ...
> >
> > > diff --git a/drivers/bus/stm32_firewall.c b/drivers/bus/stm32_firewall.c
> >
> > ...
> >
> > > +int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller)
> > > +{
> > > + struct stm32_firewall *firewalls;
> > > + struct device_node *child;
> > > + struct device *parent;
> > > + unsigned int i;
> > > + int len;
> > > + int err;
> > > +
> > > + parent = firewall_controller->dev;
> > > +
> > > + dev_dbg(parent, "Populating %s system bus\n", dev_name(firewall_controller->dev));
> > > +
> > > + for_each_available_child_of_node(dev_of_node(parent), child) {
> > > + /* The feature-domains property is mandatory for firewall bus devices */
> > > + len = of_count_phandle_with_args(child, "feature-domains", "#feature-domain-cells");
> > > + if (len <= 0)
> >
> > Coccinelle says that, due to breaking out of a
> > for_each_available_child_of_node() loop, a call to of_node_put()
> > is needed here
> >
>
> Hi Simon,
>
> Thank you, I already sent a V3 correcting the patch ordering issue. I
> will implement this for V4.
Hi Gatien,
Thanks and sorry for not noticing v3 - I think it arrived while
I was in the middle of reviewing v2.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2023-07-27 7:40 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 16:40 [PATCH v2 00/11] Introduce STM32 Firewall framework Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 16:40 ` [IGNORE][PATCH v2 01/11] dt-bindings: Document common device controller bindings Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 17:49 ` Rob Herring
2023-07-25 17:49 ` Rob Herring
2023-07-25 17:49 ` Rob Herring
2023-07-26 10:29 ` Simon Horman
2023-07-26 10:29 ` Simon Horman
2023-07-25 16:40 ` [PATCH v2 02/11] dt-bindings: bus: document RIFSC Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 17:49 ` Rob Herring
2023-07-25 17:49 ` Rob Herring
2023-07-25 16:40 ` [PATCH v2 03/11] dt-bindings: bus: document ETZPC Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 17:49 ` Rob Herring
2023-07-25 17:49 ` Rob Herring
2023-07-25 16:40 ` [PATCH v2 04/11] dt-bindings: treewide: add feature-domains description Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 16:40 ` [PATCH v2 05/11] firewall: introduce stm32_firewall framework Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-26 10:19 ` Simon Horman
2023-07-26 10:19 ` Simon Horman
2023-07-26 10:38 ` Gatien CHEVALLIER
2023-07-26 10:38 ` Gatien CHEVALLIER
2023-07-26 11:39 ` Simon Horman [this message]
2023-07-26 11:39 ` Simon Horman
2023-07-26 10:22 ` Simon Horman
2023-07-26 10:22 ` Simon Horman
2023-07-26 10:39 ` Gatien CHEVALLIER
2023-07-26 10:39 ` Gatien CHEVALLIER
2023-07-25 16:40 ` [PATCH v2 06/11] of: property: fw_devlink: Add support for "feature-domains" Gatien Chevallier
2023-07-25 16:40 ` Gatien Chevallier
2023-07-25 16:41 ` [PATCH v2 07/11] bus: rifsc: introduce RIFSC firewall controller driver Gatien Chevallier
2023-07-25 16:41 ` Gatien Chevallier
2023-07-26 10:26 ` Simon Horman
2023-07-26 10:26 ` Simon Horman
2023-07-26 10:32 ` Gatien CHEVALLIER
2023-07-26 10:32 ` Gatien CHEVALLIER
2023-07-25 16:41 ` [PATCH v2 08/11] arm64: dts: st: add RIFSC as a domain controller for STM32MP25x boards Gatien Chevallier
2023-07-25 16:41 ` Gatien Chevallier
2023-07-25 16:41 ` [PATCH v2 09/11] bus: etzpc: introduce ETZPC firewall controller driver Gatien Chevallier
2023-07-25 16:41 ` Gatien Chevallier
2023-07-25 16:41 ` [PATCH v2 10/11] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards Gatien Chevallier
2023-07-25 16:41 ` Gatien Chevallier
2023-07-25 16:41 ` [PATCH v2 11/11] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards Gatien Chevallier
2023-07-25 16:41 ` 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=ZMEF/gR6fmmC7jhF@corigine.com \
--to=simon.horman@corigine.com \
--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-phy@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=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
--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: link
Be 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.