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 12:19:33 +0200 [thread overview]
Message-ID: <ZMDzNSkRvvVsxUto@corigine.com> (raw)
In-Reply-To: <20230725164104.273965-6-gatien.chevallier@foss.st.com>
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
> + return -EINVAL;
> +
> + firewalls = kcalloc(len, sizeof(*firewalls), GFP_KERNEL);
> + if (!firewalls)
And here.
> + return -ENOMEM;
> +
> + err = stm32_firewall_get_firewall(child, firewalls, (unsigned int)len);
> + if (err) {
> + kfree(firewalls);
And here.
> + return err;
> + }
> +
> + for (i = 0; i < len; i++) {
> + if (firewall_controller->grant_access(firewall_controller,
> + firewalls[i].firewall_id)) {
> + /*
> + * Peripheral access not allowed or not defined.
> + * Mark the node as populated so platform bus won't probe it
> + */
> + of_node_set_flag(child, OF_POPULATED);
> + dev_err(parent, "%s: Device driver will not be probed\n",
> + child->full_name);
> + }
> + }
> +
> + kfree(firewalls);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_firewall_populate_bus);
> diff --git a/drivers/bus/stm32_firewall.h b/drivers/bus/stm32_firewall.h
...
> +/**
> + * struct stm32_firewall_controller - Information on firewall controller supplying services
> + *
> + * @name Name of the firewall controller
kernel-doc complains that name and the other fields of
struct stm32_firewall_controller are not documented.
I believe this is because a ':' is needed after the name of
the parameter (in this case 'name').
* @name: Name of the firewall controller
Likewise, elsewhere.
> + * @dev Device reference of the firewall controller
> + * @mmio Base address of the firewall controller
> + * @entry List entry of the firewall controller list
> + * @type Type of firewall
> + * @max_entries Number of entries covered by the firewall
> + * @grant_access Callback used to grant access for a device access against a
> + * firewall controller
> + * @release_access Callback used to release resources taken by a device when access was
> + * granted
> + * @grant_memory_range_access Callback used to grant access for a device to a given memory region
> + */
> +struct stm32_firewall_controller {
> + const char *name;
> + struct device *dev;
> + void __iomem *mmio;
> + struct list_head entry;
> + unsigned int type;
> + unsigned int max_entries;
> +
> + int (*grant_access)(struct stm32_firewall_controller *ctrl, u32 id);
> + void (*release_access)(struct stm32_firewall_controller *ctrl, u32 id);
> + int (*grant_memory_range_access)(struct stm32_firewall_controller *ctrl, phys_addr_t paddr,
> + size_t size);
> +};
> +
> +/**
> + * int stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
kernel-doc seems unhappy about the presence of 'int' on this line.
* stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
Likewise, elsewhere.
> + * framework
> + * @firewall_controller Firewall controller to register
> + *
> + * Returns 0 in case of success or -ENODEV if no controller was given.
> + */
> +int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller);
...
> diff --git a/include/linux/bus/stm32_firewall_device.h b/include/linux/bus/stm32_firewall_device.h
> new file mode 100644
> index 000000000000..9bdc4060154c
> --- /dev/null
> +++ b/include/linux/bus/stm32_firewall_device.h
> @@ -0,0 +1,140 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
> + */
> +
> +#ifndef STM32_FIREWALL_DEVICE_H
> +#define STM32_FIREWALL_DEVICE_H
> +
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +
> +#define STM32_FIREWALL_MAX_EXTRA_ARGS 5
> +
> +/* Opaque reference to stm32_firewall_controller */
> +struct stm32_firewall_controller;
> +
> +/**
> + * stm32_firewall - Information on a device's firewall. Each device can have more than one firewall.
kernel-doc seems unhappy about the absence of struct on this line.
* struct stm32_firewall - Information on a device's firewall. Each device can have more than one firewall.
> + *
> + * @firewall_ctrl Pointer referencing a firewall controller of the device. It is
> + * opaque so a device cannot manipulate the controller's ops or access
> + * the controller's data
> + * @extra_args Extra arguments that are implementation dependent
> + * @entry Name of the firewall entry
> + * @extra_args_size Number of extra arguments
> + * @firewall_id Firewall ID associated the device for this firewall controller
> + */
> +struct stm32_firewall {
> + struct stm32_firewall_controller *firewall_ctrl;
> + u32 extra_args[STM32_FIREWALL_MAX_EXTRA_ARGS];
> + const char *entry;
> + size_t extra_args_size;
> + u32 firewall_id;
> +};
...
--
pw-bot: changes-requested
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 12:19:33 +0200 [thread overview]
Message-ID: <ZMDzNSkRvvVsxUto@corigine.com> (raw)
In-Reply-To: <20230725164104.273965-6-gatien.chevallier@foss.st.com>
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
> + return -EINVAL;
> +
> + firewalls = kcalloc(len, sizeof(*firewalls), GFP_KERNEL);
> + if (!firewalls)
And here.
> + return -ENOMEM;
> +
> + err = stm32_firewall_get_firewall(child, firewalls, (unsigned int)len);
> + if (err) {
> + kfree(firewalls);
And here.
> + return err;
> + }
> +
> + for (i = 0; i < len; i++) {
> + if (firewall_controller->grant_access(firewall_controller,
> + firewalls[i].firewall_id)) {
> + /*
> + * Peripheral access not allowed or not defined.
> + * Mark the node as populated so platform bus won't probe it
> + */
> + of_node_set_flag(child, OF_POPULATED);
> + dev_err(parent, "%s: Device driver will not be probed\n",
> + child->full_name);
> + }
> + }
> +
> + kfree(firewalls);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_firewall_populate_bus);
> diff --git a/drivers/bus/stm32_firewall.h b/drivers/bus/stm32_firewall.h
...
> +/**
> + * struct stm32_firewall_controller - Information on firewall controller supplying services
> + *
> + * @name Name of the firewall controller
kernel-doc complains that name and the other fields of
struct stm32_firewall_controller are not documented.
I believe this is because a ':' is needed after the name of
the parameter (in this case 'name').
* @name: Name of the firewall controller
Likewise, elsewhere.
> + * @dev Device reference of the firewall controller
> + * @mmio Base address of the firewall controller
> + * @entry List entry of the firewall controller list
> + * @type Type of firewall
> + * @max_entries Number of entries covered by the firewall
> + * @grant_access Callback used to grant access for a device access against a
> + * firewall controller
> + * @release_access Callback used to release resources taken by a device when access was
> + * granted
> + * @grant_memory_range_access Callback used to grant access for a device to a given memory region
> + */
> +struct stm32_firewall_controller {
> + const char *name;
> + struct device *dev;
> + void __iomem *mmio;
> + struct list_head entry;
> + unsigned int type;
> + unsigned int max_entries;
> +
> + int (*grant_access)(struct stm32_firewall_controller *ctrl, u32 id);
> + void (*release_access)(struct stm32_firewall_controller *ctrl, u32 id);
> + int (*grant_memory_range_access)(struct stm32_firewall_controller *ctrl, phys_addr_t paddr,
> + size_t size);
> +};
> +
> +/**
> + * int stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
kernel-doc seems unhappy about the presence of 'int' on this line.
* stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
Likewise, elsewhere.
> + * framework
> + * @firewall_controller Firewall controller to register
> + *
> + * Returns 0 in case of success or -ENODEV if no controller was given.
> + */
> +int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller);
...
> diff --git a/include/linux/bus/stm32_firewall_device.h b/include/linux/bus/stm32_firewall_device.h
> new file mode 100644
> index 000000000000..9bdc4060154c
> --- /dev/null
> +++ b/include/linux/bus/stm32_firewall_device.h
> @@ -0,0 +1,140 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
> + */
> +
> +#ifndef STM32_FIREWALL_DEVICE_H
> +#define STM32_FIREWALL_DEVICE_H
> +
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +
> +#define STM32_FIREWALL_MAX_EXTRA_ARGS 5
> +
> +/* Opaque reference to stm32_firewall_controller */
> +struct stm32_firewall_controller;
> +
> +/**
> + * stm32_firewall - Information on a device's firewall. Each device can have more than one firewall.
kernel-doc seems unhappy about the absence of struct on this line.
* struct stm32_firewall - Information on a device's firewall. Each device can have more than one firewall.
> + *
> + * @firewall_ctrl Pointer referencing a firewall controller of the device. It is
> + * opaque so a device cannot manipulate the controller's ops or access
> + * the controller's data
> + * @extra_args Extra arguments that are implementation dependent
> + * @entry Name of the firewall entry
> + * @extra_args_size Number of extra arguments
> + * @firewall_id Firewall ID associated the device for this firewall controller
> + */
> +struct stm32_firewall {
> + struct stm32_firewall_controller *firewall_ctrl;
> + u32 extra_args[STM32_FIREWALL_MAX_EXTRA_ARGS];
> + const char *entry;
> + size_t extra_args_size;
> + u32 firewall_id;
> +};
...
--
pw-bot: changes-requested
--
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:39 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 [this message]
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
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=ZMDzNSkRvvVsxUto@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.