From: Greg KH <gregkh@linuxfoundation.org>
To: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: robh+dt@kernel.org, mcoquelin.stm32@gmail.com,
alexandre.torgue@st.com, loic.pallardy@st.com,
linus.walleij@linaro.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] bus: stm32: Introduce firewall controller helpers
Date: Tue, 5 May 2020 16:40:13 +0200 [thread overview]
Message-ID: <20200505144013.GB838641@kroah.com> (raw)
In-Reply-To: <20200505073308.22914-3-benjamin.gaignard@st.com>
On Tue, May 05, 2020 at 09:33:05AM +0200, Benjamin Gaignard wrote:
> The goal of these helpers are to offer an interface for the
> hardware blocks controlling bus accesses rights.
>
> Bus firewall controllers are typically used to control if a
> hardware block can perform read or write operations on bus.
>
> Smarter firewall controllers could be able to define accesses
> rights per hardware blocks to control where they can read
> or write.
>
> Firewall controller configurations are provided in device node,
> parsed by the helpers and send to the driver to apply them.
> Each controller may need different number and type of inputs
> to configure the firewall so device-tree properties size have to
> be define by using "#firewall-cells".
> Firewall configurations properties have to be named "firewall-X"
> on device node.
> "firewall-names" keyword can also be used to give a name to
> a specific configuration.
>
> Example of device-tree:
> ctrl0: firewall@0 {
> #firewall-cells = <2>;
> };
>
> foo: foo@0 {
> firewall-names = "default", "setting1";
> firewall-0 = <&ctrl0 1 2>;
> firewall-1 = <&ctrl0 3 4>;
> };
>
> Configurations could be applied with functions like
> firewall_set_config_by_index() or firewall_set_config_by_name().
>
> firewall_set_default_config() function will apply the
> configuration named "default" (if existing) or the configuration
> with index 0 (i.e. firewall-0).
>
> Drivers could register/unregister themselves be calling
> firewall_register/firewall_unregister functions.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/bus/Kconfig | 2 +
> drivers/bus/Makefile | 2 +
> drivers/bus/stm32/Kconfig | 3 +
> drivers/bus/stm32/Makefile | 1 +
> drivers/bus/stm32/firewall.c | 266 +++++++++++++++++++++++++++++++++++++++++++
> drivers/bus/stm32/firewall.h | 75 ++++++++++++
> 6 files changed, 349 insertions(+)
> create mode 100644 drivers/bus/stm32/Kconfig
> create mode 100644 drivers/bus/stm32/Makefile
> create mode 100644 drivers/bus/stm32/firewall.c
> create mode 100644 drivers/bus/stm32/firewall.h
>
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 6d4e4497b59b..843b356322d9 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -203,4 +203,6 @@ config DA8XX_MSTPRI
> source "drivers/bus/fsl-mc/Kconfig"
> source "drivers/bus/mhi/Kconfig"
>
> +source "drivers/bus/stm32/Kconfig"
> +
> endmenu
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 05f32cd694a4..5e0e34b10235 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -37,3 +37,5 @@ obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
>
> # MHI
> obj-$(CONFIG_MHI_BUS) += mhi/
> +
> +obj-$(CONFIG_MACH_STM32MP157) += stm32/
> \ No newline at end of file
> diff --git a/drivers/bus/stm32/Kconfig b/drivers/bus/stm32/Kconfig
> new file mode 100644
> index 000000000000..57221e833e2d
> --- /dev/null
> +++ b/drivers/bus/stm32/Kconfig
> @@ -0,0 +1,3 @@
> +config FIREWALL_CONTROLLERS
> + bool "Support of bus firewall controllers"
> + depends on OF
> diff --git a/drivers/bus/stm32/Makefile b/drivers/bus/stm32/Makefile
> new file mode 100644
> index 000000000000..eb6b978d6450
> --- /dev/null
> +++ b/drivers/bus/stm32/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_FIREWALL_CONTROLLERS) += firewall.o
> diff --git a/drivers/bus/stm32/firewall.c b/drivers/bus/stm32/firewall.c
> new file mode 100644
> index 000000000000..95f716cf926f
> --- /dev/null
> +++ b/drivers/bus/stm32/firewall.c
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +
> +#include "firewall.h"
> +
> +/* Mutex taken to protect firewall_list */
> +static DEFINE_MUTEX(firewall_list_mutex);
> +
> +/* Global list of firewall control devices */
> +static LIST_HEAD(firewall_list);
Why is that needed? Why can't you just walk the list of devices on this
"bus/class" if you really wanted to?
Along those lines, why is this going around the driver model and
ignoring it? Shouldn't this be a bus and you have devices attached to
it of the specific type?
greg k-h
next prev parent reply other threads:[~2020-05-05 14:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 7:33 [PATCH v3 0/5] STM32 ETZPC bus controller Benjamin Gaignard
2020-05-05 7:33 ` [PATCH v3 1/5] dt-bindings: bus: Add firewall bindings Benjamin Gaignard
2020-05-05 7:33 ` [PATCH v3 2/5] bus: stm32: Introduce firewall controller helpers Benjamin Gaignard
2020-05-05 14:40 ` Greg KH [this message]
2020-05-05 15:00 ` Benjamin GAIGNARD
2020-05-05 18:20 ` Greg KH
2020-05-05 7:33 ` [PATCH v3 3/5] dt-bindings: bus: Add STM32 ETZPC firewall controller Benjamin Gaignard
2020-05-05 7:33 ` [PATCH v3 4/5] bus: stm32: Add stm32 ETZPC firewall bus controller Benjamin Gaignard
2020-05-05 7:33 ` [PATCH v3 5/5] ARM: dts: stm32: Use ETZPC firewall bus Benjamin Gaignard
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=20200505144013.GB838641@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@st.com \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=loic.pallardy@st.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox