* [RESEND PATCH 1/7] devicetree: bindings: Document domains controller bindings
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
@ 2019-03-18 10:05 ` Benjamin Gaignard
2019-04-29 8:49 ` Benjamin GAIGNARD
2019-03-18 10:06 ` [RESEND PATCH 2/7] domainsctrl: Introduce domains controller framework Benjamin Gaignard
` (6 subsequent siblings)
7 siblings, 1 reply; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:05 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
Document commons domains controller bindings for controller
and client devices.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../bindings/bus/domains/domainsctrl.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
diff --git a/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt b/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
new file mode 100644
index 000000000000..f82e5e11ea64
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
@@ -0,0 +1,55 @@
+Common Domains Controller bindings properties
+
+Bus domains controllers allow to divided system on chip into multiple domains
+that can be used to select by who hardware blocks could be accessed.
+A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
+a group of hardware blocks.
+
+This device tree bindings can be used to bind bus domain consumer devices with
+their bus domains provided by bus domains controllers. A bus domain provider
+can be represented by any node in the device tree and can provide one or more
+bus domains. A consumer node can refer to the provider by a phandle and a set
+of phandle arguments of length specified by the #domainctrl-cells property in
+the bus domain provider node.
+
+==Bus domain provider==
+
+Required properties:
+- #domainctrl-cells : Number of cells in a bus domain specifier;
+ Can be any value as specified by device tree binding
+ documentation of a particular provider.
+
+==Bus domain consumer==
+
+Required properties:
+- domainsctrl-X : A list of bus domain specifiers, as defined by
+ bindings of the bus domain controller that is the
+ bus domain provider.
+
+Optional properties:
+- domainsctrl-names : A list of bus domain name string sorted in the same
+ order as the domainsctrl-X proprerties. Consumer
+ drivers will use domainsctrl-names to match bus
+ domains with bus domains specifiers.
+ Note that "default" and "unbind" are reserved names
+ used by the framework.
+
+Example of usage with:
+- a domains controller with a 2 parameters cell
+- a domains controller with a 3 parameters cell
+- a client device node using the both controllers and 2 configurations
+ named "default" and "unbind"
+
+ctrl0: ctrl@0 {
+ #domainctrl-cells = <2>;
+};
+
+ctrl1: ctrl@1 {
+ #domainctrl-cells = <3>;
+};
+
+foo@0 {
+ domains-names = "default", "unbind";
+ domainctrl-0 = <&ctrl0 1 2>, <&ctrl1 3 4 5>;
+ domainctrl-1 = <&ctrl0 6 7>, <&ctrl1 8 9 0>;
+};
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [RESEND PATCH 1/7] devicetree: bindings: Document domains controller bindings
2019-03-18 10:05 ` [RESEND PATCH 1/7] devicetree: bindings: Document domains controller bindings Benjamin Gaignard
@ 2019-04-29 8:49 ` Benjamin GAIGNARD
0 siblings, 0 replies; 18+ messages in thread
From: Benjamin GAIGNARD @ 2019-04-29 8:49 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, Loic PALLARDY, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh
On 3/18/19 11:05 AM, Benjamin Gaignard wrote:
> Document commons domains controller bindings for controller
> and client devices.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Hi Rob,
In the first version of this series you have asked me to rework the
framework description.
Does this v2 feel better for you ?
Benjamin
> ---
> .../bindings/bus/domains/domainsctrl.txt | 55 ++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt b/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
> new file mode 100644
> index 000000000000..f82e5e11ea64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
> @@ -0,0 +1,55 @@
> +Common Domains Controller bindings properties
> +
> +Bus domains controllers allow to divided system on chip into multiple domains
> +that can be used to select by who hardware blocks could be accessed.
> +A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> +a group of hardware blocks.
> +
> +This device tree bindings can be used to bind bus domain consumer devices with
> +their bus domains provided by bus domains controllers. A bus domain provider
> +can be represented by any node in the device tree and can provide one or more
> +bus domains. A consumer node can refer to the provider by a phandle and a set
> +of phandle arguments of length specified by the #domainctrl-cells property in
> +the bus domain provider node.
> +
> +==Bus domain provider==
> +
> +Required properties:
> +- #domainctrl-cells : Number of cells in a bus domain specifier;
> + Can be any value as specified by device tree binding
> + documentation of a particular provider.
> +
> +==Bus domain consumer==
> +
> +Required properties:
> +- domainsctrl-X : A list of bus domain specifiers, as defined by
> + bindings of the bus domain controller that is the
> + bus domain provider.
> +
> +Optional properties:
> +- domainsctrl-names : A list of bus domain name string sorted in the same
> + order as the domainsctrl-X proprerties. Consumer
> + drivers will use domainsctrl-names to match bus
> + domains with bus domains specifiers.
> + Note that "default" and "unbind" are reserved names
> + used by the framework.
> +
> +Example of usage with:
> +- a domains controller with a 2 parameters cell
> +- a domains controller with a 3 parameters cell
> +- a client device node using the both controllers and 2 configurations
> + named "default" and "unbind"
> +
> +ctrl0: ctrl@0 {
> + #domainctrl-cells = <2>;
> +};
> +
> +ctrl1: ctrl@1 {
> + #domainctrl-cells = <3>;
> +};
> +
> +foo@0 {
> + domains-names = "default", "unbind";
> + domainctrl-0 = <&ctrl0 1 2>, <&ctrl1 3 4 5>;
> + domainctrl-1 = <&ctrl0 6 7>, <&ctrl1 8 9 0>;
> +};
^ permalink raw reply [flat|nested] 18+ messages in thread
* [RESEND PATCH 2/7] domainsctrl: Introduce domains controller framework
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
2019-03-18 10:05 ` [RESEND PATCH 1/7] devicetree: bindings: Document domains controller bindings Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 3/7] base: Add calls to domains controller Benjamin Gaignard
` (5 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
The goal of this framework is to offer an interface for the
hardware blocks controlling bus accesses rights.
Bus domains controllers are typically used to control if a
hardware block can perform read or write operations on bus.
Smarter domains controllers could be able to define accesses
rights per hardware blocks to control where they can read
or write.
Domains controller configurations are provided in device node,
parsed by the framework and send to the driver to apply them.
Each controller may need different number and type of inputs
to configure a domain so device-tree properties size have to
be define by using "#domainctrl-cells".
Domains configurations properties have to be named "domainsctrl-X"
on device node.
"domainsctrl-names" keyword can also be used to give a name to
a specific configuration.
Example of device-tree:
ctrl0: domainsctrl@0 {
#domainctrl-cells = <2>;
};
foo: foo@0 {
domainsctrl-names = "default", "setting1";
domainsctrl-0 = <&ctrl0 1 2>;
domainsctrl-1 = <&ctrl0 3 4>;
};
Configurations could be applied with functions like
domainsctrl_set_config_by_index() or domainsctrl_set_config_by_name().
domainsctrl_set_default_config() function will apply the
configuration named "default" (if existing) or the configuration
with index 0 (i.e. domainsctrl-0).
Drivers could register/unregister themselves be calling
domainsctrl_register/domainsctrl_unregister functions.
When a configuration has to be applied the driver callback,
provided in the ops at registration time, set_config is called
by the framework.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 2 +
drivers/bus/domains/Kconfig | 7 ++
drivers/bus/domains/Makefile | 1 +
drivers/bus/domains/domainsctrl.c | 234 ++++++++++++++++++++++++++++++++++++++
include/linux/domainsctrl.h | 70 ++++++++++++
6 files changed, 316 insertions(+)
create mode 100644 drivers/bus/domains/Kconfig
create mode 100644 drivers/bus/domains/Makefile
create mode 100644 drivers/bus/domains/domainsctrl.c
create mode 100644 include/linux/domainsctrl.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112ccc29..a0f7a67c1296 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -183,4 +183,6 @@ config DA8XX_MSTPRI
source "drivers/bus/fsl-mc/Kconfig"
+source "drivers/bus/domains/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ca300b1914ce..d7e95edba33d 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -32,3 +32,5 @@ obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
+
+obj-$(CONFIG_DOMAINS_CONTROLLERS) += domains/
diff --git a/drivers/bus/domains/Kconfig b/drivers/bus/domains/Kconfig
new file mode 100644
index 000000000000..5ba15f750bee
--- /dev/null
+++ b/drivers/bus/domains/Kconfig
@@ -0,0 +1,7 @@
+menu "Bus Domains Controllers"
+
+config DOMAINS_CONTROLLERS
+ bool "Support of bus domains controllers"
+ depends on OF
+
+endmenu
diff --git a/drivers/bus/domains/Makefile b/drivers/bus/domains/Makefile
new file mode 100644
index 000000000000..262338b7cad5
--- /dev/null
+++ b/drivers/bus/domains/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DOMAINS_CONTROLLERS) += domainsctrl.o
diff --git a/drivers/bus/domains/domainsctrl.c b/drivers/bus/domains/domainsctrl.c
new file mode 100644
index 000000000000..bbadf8165bc8
--- /dev/null
+++ b/drivers/bus/domains/domainsctrl.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#include <linux/device.h>
+#include <linux/domainsctrl.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>
+
+/* Mutex taken to protect domainctrl_list */
+static DEFINE_MUTEX(domainctrl_list_mutex);
+
+/* Global list of domain control devices (struct domains_ctrl) */
+static LIST_HEAD(domainctrl_list);
+
+struct domains_ctrl {
+ struct list_head node;
+ struct device *dev;
+ struct domains_ctrl_ops *ops;
+};
+
+static struct domains_ctrl *get_domainctrl_from_node(struct device_node *np)
+{
+ struct domains_ctrl *ctrl;
+
+ mutex_lock(&domainctrl_list_mutex);
+
+ list_for_each_entry(ctrl, &domainctrl_list, node) {
+ if (ctrl->dev->of_node == np) {
+ mutex_unlock(&domainctrl_list_mutex);
+ return ctrl;
+ }
+ }
+
+ mutex_unlock(&domainctrl_list_mutex);
+
+ return NULL;
+}
+
+/**
+ * domainsctrl_set_config_by_index
+ *
+ * Set a domains controller configuration based on given index.
+ *
+ * @dev: device with domain configuration to apply.
+ * @index: the index of the configuration in device node.
+ *
+ * Returns 0 if OK, -EPROBE_DEFER if waiting for domains controller to be
+ * registered or negative value on other errors.
+ */
+int domainsctrl_set_config_by_index(struct device *dev, int index)
+{
+ struct device_node *np = dev->of_node;
+ char *propname;
+ int configs, i, err = 0;
+
+ if (!np)
+ return 0;
+
+ propname = kasprintf(GFP_KERNEL, "domainctrl-%d", index);
+ configs = of_count_phandle_with_args(np, propname, "#domainctrl-cells");
+ if (configs < 0) {
+ err = -EINVAL;
+ goto error;
+ }
+
+ for (i = 0; i < configs; i++) {
+ struct domains_ctrl *ctrl;
+ struct of_phandle_args args;
+
+ err = of_parse_phandle_with_args(np, propname,
+ "#domainctrl-cells",
+ i, &args);
+ if (err)
+ goto error;
+
+ /* Test if the controller is (or will be) available */
+ if (!of_device_is_available(args.np)) {
+ of_node_put(args.np);
+ continue;
+ }
+
+ ctrl = get_domainctrl_from_node(args.np);
+ of_node_put(args.np);
+
+ /* Controller is not yet registered */
+ if (!ctrl) {
+ err = -EPROBE_DEFER;
+ goto error;
+ }
+
+ err = ctrl->ops->set_config(ctrl->dev, &args);
+ if (err)
+ goto error;
+ }
+
+error:
+ kfree(propname);
+ return err;
+}
+EXPORT_SYMBOL_GPL(domainsctrl_set_config_by_index);
+
+/**
+ * domainsctrl_set_config_by_name
+ *
+ * Set a domains controller configuration based on given name.
+ *
+ * @dev: device with domain configuration to apply.
+ * @name: the name of the configuration in device node.
+ *
+ * Returns 0 if OK, -EPROBE_DEFER if waiting for domains controller to be
+ * registered or negative value on other errors.
+ */
+int domainsctrl_set_config_by_name(struct device *dev, char *name)
+{
+ const char *configname;
+ int count, i;
+
+ count = of_property_count_strings(dev->of_node, "domainctrl-names");
+ for (i = 0; i < count; i++) {
+ int err;
+
+ err = of_property_read_string_index(dev->of_node,
+ "domainctrl-names",
+ i, &configname);
+ if (err)
+ return err;
+
+ if (strcmp(name, configname))
+ continue;
+
+ return domainsctrl_set_config_by_index(dev, i);
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(domainsctrl_set_config_by_name);
+
+/**
+ * domainsctrl_set_default_config
+ *
+ * Set the default configuration for device.
+ * First try to apply configuration named "default", if it fails
+ * or doesn't exist, try to apply domainsctrl-0 configuration.
+ *
+ * @dev: device with domain configuration to apply.
+ *
+ * Returns 0 if OK, -EPROBE_DEFER if waiting for domains controller to be
+ * registered or negative value on other errors.
+ */
+int domainsctrl_set_default_config(struct device *dev)
+{
+ int ret;
+
+ ret = domainsctrl_set_config_by_name(dev, "default");
+ if (!ret || (ret == -EPROBE_DEFER))
+ return ret;
+
+ return domainsctrl_set_config_by_index(dev, 0);
+}
+EXPORT_SYMBOL_GPL(domainsctrl_set_default_config);
+
+/**
+ * domainsctrl_register
+ *
+ * Register a domains controller device.
+ *
+ * @dev: device implementing domains controller.
+ * @ops: domains controller operations.
+ *
+ * Returns 0 if OK or negative value on error.
+ */
+int domainsctrl_register(struct device *dev,
+ struct domains_ctrl_ops *ops)
+{
+ struct domains_ctrl *ctrl;
+
+ if (!dev || !ops || !ops->set_config)
+ return -EINVAL;
+
+ ctrl = kzalloc(sizeof(*ctrl), GFP_KERNEL);
+ if (!ctrl)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&ctrl->node);
+
+ ctrl->dev = dev;
+ ctrl->ops = ops;
+
+ mutex_lock(&domainctrl_list_mutex);
+ list_add_tail(&ctrl->node, &domainctrl_list);
+ mutex_unlock(&domainctrl_list_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(domainsctrl_register);
+
+/**
+ * domainsctrl_unregister
+ *
+ * Unregister a domains controller device.
+ *
+ * @dev: device implementing domains controller.
+ */
+void domainsctrl_unregister(struct device *dev)
+{
+ struct domains_ctrl *ctrl;
+
+ ctrl = get_domainctrl_from_node(dev->of_node);
+ if (!ctrl)
+ return;
+
+ mutex_lock(&domainctrl_list_mutex);
+ list_del(&ctrl->node);
+ mutex_unlock(&domainctrl_list_mutex);
+
+ kfree(ctrl);
+}
+EXPORT_SYMBOL_GPL(domainsctrl_unregister);
+
+static int __init domainsctrl_init(void)
+{
+ pr_info("initialized bus domain controller subsystem\n");
+ return 0;
+}
+
+/* Init early since drivers really need to configure domains early */
+core_initcall(domainsctrl_init);
diff --git a/include/linux/domainsctrl.h b/include/linux/domainsctrl.h
new file mode 100644
index 000000000000..1d1960175342
--- /dev/null
+++ b/include/linux/domainsctrl.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#ifndef _DOMAINSCTRL_H_
+#define _DOMAINSCTRL_H_
+
+#include <linux/device.h>
+#include <linux/of.h>
+
+/**
+ * struct domains_ctrl_ops
+ *
+ * Domains controller operations structure to be filled by drivers.
+ */
+struct domains_ctrl_ops {
+ /**
+ * @set_config:
+ *
+ * Driver callback to set a domain configuration on a domain controller.
+ * Configuration arguments are provided in out_args parameter.
+ *
+ * Returns 0 on success, a negative error code on failure.
+ */
+ int (*set_config)(struct device *dev, struct of_phandle_args *out_args);
+};
+
+#ifdef CONFIG_DOMAINS_CONTROLLERS
+
+int domainsctrl_set_config_by_index(struct device *dev, int index);
+int domainsctrl_set_config_by_name(struct device *dev, char *name);
+int domainsctrl_set_default_config(struct device *dev);
+
+int domainsctrl_register(struct device *dev, struct domains_ctrl_ops *ops);
+
+void domainsctrl_unregister(struct device *dev);
+
+#else
+
+static inline int domainsctrl_set_config_by_index(struct device *dev, int index)
+{
+ return 0;
+}
+
+static inline int domainsctrl_set_config_by_name(struct device *dev, char *name)
+{
+ return 0;
+}
+
+static inline int domainsctrl_set_default_config(struct device *dev)
+{
+ return 0;
+}
+
+static inline int domainsctrl_register(struct device *dev,
+ struct domains_ctrl_ops *ops)
+{
+ return 0;
+}
+
+static inline void domainsctrl_unregister(struct device *dev)
+{
+ /* Empty */
+}
+
+#endif
+
+#endif /* _DOMAINSCTRL_H_ */
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RESEND PATCH 3/7] base: Add calls to domains controller
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
2019-03-18 10:05 ` [RESEND PATCH 1/7] devicetree: bindings: Document domains controller bindings Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 2/7] domainsctrl: Introduce domains controller framework Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 4/7] devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings Benjamin Gaignard
` (4 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
To avoid modifying all the drivers call domainsctrl_set_default_config
before probe to apply the configuration define in device node (if any).
When unbinding the device try to apply configuration named "unbind".
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
drivers/base/dd.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a823f469e53f..d8378cd1a8cd 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -20,6 +20,7 @@
#include <linux/device.h>
#include <linux/delay.h>
#include <linux/dma-mapping.h>
+#include <linux/domainsctrl.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kthread.h>
@@ -482,6 +483,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
re_probe:
dev->driver = drv;
+ ret = domainsctrl_set_default_config(dev);
+ if (ret)
+ goto domainctrl_failed;
+
/* If using pinctrl, bind pins now before probing */
ret = pinctrl_bind_pins(dev);
if (ret)
@@ -552,6 +557,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
pinctrl_bind_failed:
+ domainsctrl_set_config_by_name(dev, "unbind");
+domainctrl_failed:
device_links_no_driver(dev);
devres_release_all(dev);
driver_sysfs_remove(dev);
@@ -1083,6 +1090,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
device_links_driver_cleanup(dev);
+ domainsctrl_set_config_by_name(dev, "unbind");
+
devres_release_all(dev);
arch_teardown_dma_ops(dev);
dev->driver = NULL;
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RESEND PATCH 4/7] devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
` (2 preceding siblings ...)
2019-03-18 10:06 ` [RESEND PATCH 3/7] base: Add calls to domains controller Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 5/7] bus: domainsctrl: Add driver for STM32 ETZPC controller Benjamin Gaignard
` (3 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
Describe STM32 Extended TrustZone Protection bindings.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../devicetree/bindings/bus/domains/st,stm32-etzpc.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/domains/st,stm32-etzpc.txt
diff --git a/Documentation/devicetree/bindings/bus/domains/st,stm32-etzpc.txt b/Documentation/devicetree/bindings/bus/domains/st,stm32-etzpc.txt
new file mode 100644
index 000000000000..8f0a990ab59c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/domains/st,stm32-etzpc.txt
@@ -0,0 +1,14 @@
+STMicroelectronics STM32 Extended TrustZone Protection driver
+
+Required properties:
+ - compatible : must be "st,stm32-etzpc"
+ - reg : physical base address of the IP registers and length of memory
+ mapped region.
+ - #domainctrl-cells : must be 2
+
+Example:
+ etzpc@5c007000 {
+ compatible = "st,stm32-etzpc";
+ reg = <0x5c007000 0x400>;
+ #domainctrl-cells = <2>;
+ };
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RESEND PATCH 5/7] bus: domainsctrl: Add driver for STM32 ETZPC controller
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
` (3 preceding siblings ...)
2019-03-18 10:06 ` [RESEND PATCH 4/7] devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 6/7] ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC Benjamin Gaignard
` (2 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
STM32 Extended TrustZone Protection Controller (ETZPC) got 3 domains:
- secure: hardware blocks are only accessible by software running on trust
zone.
- non-secure: hardware blocks are accessible by non-secure software (i.e.
linux kernel).
- coprocessor: hardware blocks are only accessible by the corpocessor.
Each hardware block status is defined by a 2 bits field and all of
them are packed into 32 bits registers. ETZPC can manage up to 94
hardware blocks.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/bus/domains/Kconfig | 7 ++
drivers/bus/domains/Makefile | 1 +
drivers/bus/domains/stm32-etzpc.c | 140 ++++++++++++++++++++++++++
include/dt-bindings/bus/domains/stm32-etzpc.h | 25 +++++
4 files changed, 173 insertions(+)
create mode 100644 drivers/bus/domains/stm32-etzpc.c
create mode 100644 include/dt-bindings/bus/domains/stm32-etzpc.h
diff --git a/drivers/bus/domains/Kconfig b/drivers/bus/domains/Kconfig
index 5ba15f750bee..7afd209e8c4f 100644
--- a/drivers/bus/domains/Kconfig
+++ b/drivers/bus/domains/Kconfig
@@ -4,4 +4,11 @@ config DOMAINS_CONTROLLERS
bool "Support of bus domains controllers"
depends on OF
+config STM32_ETZPC
+ bool "STM32 ETZPC Domain Controller"
+ depends on DOMAINS_CONTROLLERS && MACH_STM32MP157
+ help
+ Select y to enable STM32 Extended TrustZone Protection
+ Controller (ETZPC)
+
endmenu
diff --git a/drivers/bus/domains/Makefile b/drivers/bus/domains/Makefile
index 262338b7cad5..8000de6023a5 100644
--- a/drivers/bus/domains/Makefile
+++ b/drivers/bus/domains/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DOMAINS_CONTROLLERS) += domainsctrl.o
+obj-$(CONFIG_STM32_ETZPC) += stm32-etzpc.o
diff --git a/drivers/bus/domains/stm32-etzpc.c b/drivers/bus/domains/stm32-etzpc.c
new file mode 100644
index 000000000000..8a03128a8715
--- /dev/null
+++ b/drivers/bus/domains/stm32-etzpc.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#include <linux/device.h>
+#include <linux/domainsctrl.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/bus/domains/stm32-etzpc.h>
+
+#define ETZPC_DECPROT 0x010
+#define ETZPC_NUM_LOCKS 94
+
+struct stm32_etzpc {
+ struct regmap_field *fields[ETZPC_NUM_LOCKS];
+};
+
+static int stm32_etzpc_set_config(struct device *dev,
+ struct of_phandle_args *out_args)
+{
+ struct stm32_etzpc *etzpc = dev_get_drvdata(dev);
+ int index = out_args->args[0];
+ unsigned int value = out_args->args[1];
+ u32 status;
+
+ if (out_args->args_count != 2)
+ return -EINVAL;
+
+ if (index >= ETZPC_NUM_LOCKS)
+ return -EINVAL;
+
+ if (value > STM32_ETZPC_NON_SECURE)
+ return -EINVAL;
+
+ regmap_field_force_write(etzpc->fields[index], value);
+
+ /* Hardware could denied the new value, read it back to check it */
+ regmap_field_read(etzpc->fields[index], &status);
+
+ if (value != status) {
+ dev_info(dev, "failed to set configuration: index %d, value %d\n",
+ index, value);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct domains_ctrl_ops stm32_etzpc_ops = {
+ .set_config = stm32_etzpc_set_config,
+};
+
+static const struct regmap_config stm32_etzpc_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x3FF,
+ .fast_io = true,
+};
+
+static int stm32_etzpc_probe(struct platform_device *pdev)
+{
+ struct stm32_etzpc *etzpc;
+ struct resource *res;
+ void __iomem *mmio;
+ struct regmap *regmap;
+ int i;
+
+ etzpc = devm_kzalloc(&pdev->dev, sizeof(*etzpc), GFP_KERNEL);
+ if (!etzpc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mmio = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mmio))
+ return PTR_ERR(mmio);
+
+ regmap = devm_regmap_init_mmio(&pdev->dev, mmio,
+ &stm32_etzpc_regmap_cfg);
+
+ for (i = 0; i < ETZPC_NUM_LOCKS; i++) {
+ struct reg_field field;
+
+ /*
+ * Each hardware block status is defined by
+ * a 2 bits field and all of them are packed into
+ * 32 bits registers. Do some computation to get
+ * register offset and the shift.
+ */
+ field.reg = ETZPC_DECPROT + (i >> 4) * sizeof(u32);
+ field.lsb = (i % 0x10) << 1;
+ field.msb = field.lsb + 1;
+
+ etzpc->fields[i] = devm_regmap_field_alloc(&pdev->dev,
+ regmap, field);
+ }
+
+ platform_set_drvdata(pdev, etzpc);
+
+ return domainsctrl_register(&pdev->dev, &stm32_etzpc_ops);
+}
+
+static int stm32_etzpc_remove(struct platform_device *pdev)
+{
+ domainsctrl_unregister(&pdev->dev);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_etzpc_of_match[] = {
+ { .compatible = "st,stm32-etzpc" },
+ { /* end node */ }
+};
+MODULE_DEVICE_TABLE(of, stm32_etzpc_of_match);
+
+static struct platform_driver stm32_etzpc_driver = {
+ .probe = stm32_etzpc_probe,
+ .remove = stm32_etzpc_remove,
+ .driver = {
+ .name = "stm32-etzpc",
+ .of_match_table = stm32_etzpc_of_match,
+ },
+};
+
+static int __init stm32_etzpc_init(void)
+{
+ return platform_driver_register(&stm32_etzpc_driver);
+}
+arch_initcall(stm32_etzpc_init);
+
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Bus Dommains Controller");
diff --git a/include/dt-bindings/bus/domains/stm32-etzpc.h b/include/dt-bindings/bus/domains/stm32-etzpc.h
new file mode 100644
index 000000000000..93190fa29a9c
--- /dev/null
+++ b/include/dt-bindings/bus/domains/stm32-etzpc.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#ifndef _STM32_ETZPC_H_
+#define _STM32_ETZPC_H_
+
+/* ETZPC domains: secure, non-secure or coprocessor*/
+#define STM32_ETZPC_SECURE 1
+#define STM32_ETPCZ_COPRO 2
+#define STM32_ETZPC_NON_SECURE 3
+
+/* ETZPC hard blaokcs index */
+#define STM32_ETZPC_USART1 3
+#define STM32_ETZPC_SPI6 4
+#define STM32_ETZPC_I2C4 5
+#define STM32_ETZPC_RNG1 7
+#define STM32_ETZPC_HASH1 8
+#define STM32_ETZPC_CRYP1 9
+#define STM32_ETZPC_I2C6 12
+#define STM32_ETZPC_CEC 38
+
+#endif /* _STM32_ETZPC_H_ */
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RESEND PATCH 6/7] ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
` (4 preceding siblings ...)
2019-03-18 10:06 ` [RESEND PATCH 5/7] bus: domainsctrl: Add driver for STM32 ETZPC controller Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:06 ` [RESEND PATCH 7/7] ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1 Benjamin Gaignard
2019-03-18 10:43 ` [RESEND PATCH 0/7] Introduce bus domains controller framework Sudeep Holla
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
Declare ETZPC device as a domains controller node for stm32mp157 SoC
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index f8bbfff5950b..7b68e18ed2c8 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1199,6 +1199,13 @@
status = "disabled";
};
+ etzpc: etzpc@5c007000 {
+ compatible = "st,stm32-etzpc";
+ reg = <0x5c007000 0x400>;
+ #domainctrl-cells = <2>;
+ status = "okay";
+ };
+
i2c6: i2c@5c009000 {
compatible = "st,stm32f7-i2c";
reg = <0x5c009000 0x400>;
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [RESEND PATCH 7/7] ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
` (5 preceding siblings ...)
2019-03-18 10:06 ` [RESEND PATCH 6/7] ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC Benjamin Gaignard
@ 2019-03-18 10:06 ` Benjamin Gaignard
2019-03-18 10:43 ` [RESEND PATCH 0/7] Introduce bus domains controller framework Sudeep Holla
7 siblings, 0 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 10:06 UTC (permalink / raw)
To: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam
Cc: linux-kernel, loic.pallardy, benjamin.gaignard, kernel,
linux-imx, linux-arm-kernel, gregkh, Benjamin Gaignard
Enable ETZPC and set configuration for CEC node
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp157c-ev1.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index b6aca40b9b90..a69c171e6b69 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "stm32mp157c-ed1.dts"
+#include <dt-bindings/bus/domains/stm32-etzpc.h>
#include <dt-bindings/gpio/gpio.h>
/ {
@@ -32,6 +33,7 @@
&cec {
pinctrl-names = "default";
pinctrl-0 = <&cec_pins_a>;
+ domainctrl-0 = <&etzpc STM32_ETZPC_CEC STM32_ETZPC_NON_SECURE>;
status = "okay";
};
--
2.15.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-03-18 10:05 [RESEND PATCH 0/7] Introduce bus domains controller framework Benjamin Gaignard
` (6 preceding siblings ...)
2019-03-18 10:06 ` [RESEND PATCH 7/7] ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1 Benjamin Gaignard
@ 2019-03-18 10:43 ` Sudeep Holla
2019-03-18 11:05 ` Benjamin Gaignard
7 siblings, 1 reply; 18+ messages in thread
From: Sudeep Holla @ 2019-03-18 10:43 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: broonie, robh, arnd, shawnguo, s.hauer, fabio.estevam,
benjamin.gaignard, loic.pallardy, gregkh, linux-kernel,
linux-imx, kernel, linux-arm-kernel
On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> Bus domains controllers allow to divided system on chip into multiple domains
> that can be used to select by who hardware blocks could be accessed.
> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> a group of hardware blocks.
>
> Framework architecture is inspirated by pinctrl framework:
> - a default configuration could be applied before bind the driver
> - configurations could be apllied dynamically by drivers
> - device node provides the bus domains configurations
>
> An example of bus domains controller is STM32 ETZPC hardware block
> which got 3 domains:
> - secure: hardware blocks are only accessible by software running on trust
> zone.
> - non-secure: hardware blocks are accessible by non-secure software (i.e.
> linux kernel).
> - coprocessor: hardware blocks are only accessible by the corpocessor.
> Up to 94 hardware blocks of the soc could be managed by ETZPC and
> assigned to one of the three domains.
>
You fail to explain why do we need this in non-secure Linux ?
You need to have solid reasons as why this can't be done in secure
firmware. And yes I mean even on arm32. On platforms with such hardware
capabilities you will need some secure firmware to be running and these
things can be done there. I don't want this enabled for ARM64 at all,
firmware *has to deal* with this.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-03-18 10:43 ` [RESEND PATCH 0/7] Introduce bus domains controller framework Sudeep Holla
@ 2019-03-18 11:05 ` Benjamin Gaignard
2019-04-19 12:36 ` Benjamin Gaignard
2019-04-23 13:21 ` Sudeep Holla
0 siblings, 2 replies; 18+ messages in thread
From: Benjamin Gaignard @ 2019-03-18 11:05 UTC (permalink / raw)
To: Sudeep Holla
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
>
> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> > Bus domains controllers allow to divided system on chip into multiple domains
> > that can be used to select by who hardware blocks could be accessed.
> > A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> > a group of hardware blocks.
> >
> > Framework architecture is inspirated by pinctrl framework:
> > - a default configuration could be applied before bind the driver
> > - configurations could be apllied dynamically by drivers
> > - device node provides the bus domains configurations
> >
> > An example of bus domains controller is STM32 ETZPC hardware block
> > which got 3 domains:
> > - secure: hardware blocks are only accessible by software running on trust
> > zone.
> > - non-secure: hardware blocks are accessible by non-secure software (i.e.
> > linux kernel).
> > - coprocessor: hardware blocks are only accessible by the corpocessor.
> > Up to 94 hardware blocks of the soc could be managed by ETZPC and
> > assigned to one of the three domains.
> >
>
> You fail to explain why do we need this in non-secure Linux ?
> You need to have solid reasons as why this can't be done in secure
> firmware. And yes I mean even on arm32. On platforms with such hardware
> capabilities you will need some secure firmware to be running and these
> things can be done there. I don't want this enabled for ARM64 at all,
> firmware *has to deal* with this.
We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex M4
(both non-secure) on STM32MP1 SoC, this new framework allow to change hardware
block split at runtime. This could be done even on non-secure world
because their is
nothing critical to change hardware blocks users.
For example you can do "complex" tasks like display pipe configuration
on Cortex A7
where linux is running and handover the control of this hardware block
to Cortex M4 to
offload drawing on framebuffer.
Benjamin
>
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-03-18 11:05 ` Benjamin Gaignard
@ 2019-04-19 12:36 ` Benjamin Gaignard
2019-04-23 7:41 ` Enrico Weigelt, metux IT consult
2019-04-23 13:21 ` Sudeep Holla
1 sibling, 1 reply; 18+ messages in thread
From: Benjamin Gaignard @ 2019-04-19 12:36 UTC (permalink / raw)
To: Sudeep Holla
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
Le lun. 18 mars 2019 à 12:05, Benjamin Gaignard
<benjamin.gaignard@linaro.org> a écrit :
>
> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
> >
> > On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> > > Bus domains controllers allow to divided system on chip into multiple domains
> > > that can be used to select by who hardware blocks could be accessed.
> > > A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> > > a group of hardware blocks.
> > >
> > > Framework architecture is inspirated by pinctrl framework:
> > > - a default configuration could be applied before bind the driver
> > > - configurations could be apllied dynamically by drivers
> > > - device node provides the bus domains configurations
> > >
> > > An example of bus domains controller is STM32 ETZPC hardware block
> > > which got 3 domains:
> > > - secure: hardware blocks are only accessible by software running on trust
> > > zone.
> > > - non-secure: hardware blocks are accessible by non-secure software (i.e.
> > > linux kernel).
> > > - coprocessor: hardware blocks are only accessible by the corpocessor.
> > > Up to 94 hardware blocks of the soc could be managed by ETZPC and
> > > assigned to one of the three domains.
> > >
> >
> > You fail to explain why do we need this in non-secure Linux ?
> > You need to have solid reasons as why this can't be done in secure
> > firmware. And yes I mean even on arm32. On platforms with such hardware
> > capabilities you will need some secure firmware to be running and these
> > things can be done there. I don't want this enabled for ARM64 at all,
> > firmware *has to deal* with this.
>
> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex M4
> (both non-secure) on STM32MP1 SoC, this new framework allow to change hardware
> block split at runtime. This could be done even on non-secure world
> because their is
> nothing critical to change hardware blocks users.
> For example you can do "complex" tasks like display pipe configuration
> on Cortex A7
> where linux is running and handover the control of this hardware block
> to Cortex M4 to
> offload drawing on framebuffer.
>
Gentle ping to get more feedback on this series
Benjamin
> Benjamin
>
> >
> > --
> > Regards,
> > Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-04-19 12:36 ` Benjamin Gaignard
@ 2019-04-23 7:41 ` Enrico Weigelt, metux IT consult
0 siblings, 0 replies; 18+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2019-04-23 7:41 UTC (permalink / raw)
To: Benjamin Gaignard, Sudeep Holla
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
On 19.04.19 14:36, Benjamin Gaignard wrote:
Hi folks,
I've missed most of the thread, but just some comments:
>>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
>>>> Bus domains controllers allow to divided system on chip into multiple domains
>>>> that can be used to select by who hardware blocks could be accessed.
>>>> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
>>>> a group of hardware blocks.
>>>>
>>>> Framework architecture is inspirated by pinctrl framework:
>>>> - a default configuration could be applied before bind the driver
>>>> - configurations could be apllied dynamically by drivers
>>>> - device node provides the bus domains configurations
>>>>
>>>> An example of bus domains controller is STM32 ETZPC hardware block
>>>> which got 3 domains:
>>>> - secure: hardware blocks are only accessible by software running on trust
>>>> zone.
>>>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>>>> linux kernel).
>>>> - coprocessor: hardware blocks are only accessible by the corpocessor.
>>>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>>>> assigned to one of the three domains.
Haven't had a look at the code (missed that part), but think the general
idea is a good thing. In some way this seems kinda semantic superset of
pinctrl ;-) We have similar cases w/ things like audio routing in
complex codex. Maybe we could find some common ground on these specific
areas that could be generalized.
>>> You fail to explain why do we need this in non-secure Linux ?
>>> You need to have solid reasons as why this can't be done in secure
>>> firmware. And yes I mean even on arm32. On platforms with such hardware
>>> capabilities you will need some secure firmware to be running and these
>>> things can be done there. I don't want this enabled for ARM64 at all,
>>> firmware *has to deal* with this.
Actually, I'm I read words like "secure firmware", I think of crap code
from chip/board/bios vendors (which is anything but secure and even
likely to have backdoors - if these aren't already on-chip, eg. ME)
Something I really do *NOT* wanna have on my machines - and if I can't
get the board/soc w/o it, I wanna kick that firmware out of the way,
as much as I can.
Therefore, he *does* have *good* reasons.
This whole idea of "secure firmware" is bogus anyways. I'd appreciate
MMU improvements for things like better/stricter isolation (to defeat
side channel attacks), really fast switches to kernel space, at least
for interrupts (eg. reserve cache banks for kernel, so we don't need
to flush here), hw support for nested VMs and hw assisted int->vm
routing, etc, etc. ... there's a lot that could be done here.
But: introducing something daemonish that sits in the background,
can do whatever it likes, controlling OS and HW, w/o the user/device
owner knowing, is completely inacceptable for me. It's really bad that
this x86 crap concepts are pushed over to arm world.
>> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex M4
>> (both non-secure) on STM32MP1 SoC, this new framework allow to change hardware
>> block split at runtime. This could be done even on non-secure world
>> because their is nothing critical to change hardware blocks users.
Sounds like a good usecase. For now, we have to do application specific
hacks for that - a generic solution for configuring that (eg. via dt)
is highly appreciated.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-03-18 11:05 ` Benjamin Gaignard
2019-04-19 12:36 ` Benjamin Gaignard
@ 2019-04-23 13:21 ` Sudeep Holla
2019-04-23 13:33 ` Benjamin GAIGNARD
1 sibling, 1 reply; 18+ messages in thread
From: Sudeep Holla @ 2019-04-23 13:21 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM, Sudeep Holla
On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote:
> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
> >
> > On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> > > Bus domains controllers allow to divided system on chip into multiple domains
> > > that can be used to select by who hardware blocks could be accessed.
> > > A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> > > a group of hardware blocks.
> > >
> > > Framework architecture is inspirated by pinctrl framework:
> > > - a default configuration could be applied before bind the driver
> > > - configurations could be apllied dynamically by drivers
> > > - device node provides the bus domains configurations
> > >
> > > An example of bus domains controller is STM32 ETZPC hardware block
> > > which got 3 domains:
> > > - secure: hardware blocks are only accessible by software running on trust
> > > zone.
> > > - non-secure: hardware blocks are accessible by non-secure software (i.e.
> > > linux kernel).
> > > - coprocessor: hardware blocks are only accessible by the corpocessor.
> > > Up to 94 hardware blocks of the soc could be managed by ETZPC and
> > > assigned to one of the three domains.
> > >
> >
> > You fail to explain why do we need this in non-secure Linux ?
> > You need to have solid reasons as why this can't be done in secure
> > firmware. And yes I mean even on arm32. On platforms with such hardware
> > capabilities you will need some secure firmware to be running and these
> > things can be done there. I don't want this enabled for ARM64 at all,
> > firmware *has to deal* with this.
>
> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex
> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change
> hardware block split at runtime. This could be done even on non-secure world
> because their is nothing critical to change hardware blocks users.
OK, that's interesting, assuming Cortex M4 execution as non-secure. I would
expect otherwise. Even if it's configurable, I would see that happen in
secure entity via OPTEE or something similar from non-secure side.
Do you have any documents that I can refer to get the overall security
design for such platforms ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-04-23 13:21 ` Sudeep Holla
@ 2019-04-23 13:33 ` Benjamin GAIGNARD
2019-04-23 13:55 ` Sudeep Holla
0 siblings, 1 reply; 18+ messages in thread
From: Benjamin GAIGNARD @ 2019-04-23 13:33 UTC (permalink / raw)
To: Sudeep Holla, Benjamin Gaignard
Cc: Mark Brown, Rob Herring, Arnd Bergmann, Shawn Guo, s.hauer,
Fabio Estevam, Loic PALLARDY, Greg Kroah-Hartman,
Linux Kernel Mailing List, linux-imx, kernel, Linux ARM
On 4/23/19 3:21 PM, Sudeep Holla wrote:
> On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote:
>> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
>>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
>>>> Bus domains controllers allow to divided system on chip into multiple domains
>>>> that can be used to select by who hardware blocks could be accessed.
>>>> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
>>>> a group of hardware blocks.
>>>>
>>>> Framework architecture is inspirated by pinctrl framework:
>>>> - a default configuration could be applied before bind the driver
>>>> - configurations could be apllied dynamically by drivers
>>>> - device node provides the bus domains configurations
>>>>
>>>> An example of bus domains controller is STM32 ETZPC hardware block
>>>> which got 3 domains:
>>>> - secure: hardware blocks are only accessible by software running on trust
>>>> zone.
>>>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>>>> linux kernel).
>>>> - coprocessor: hardware blocks are only accessible by the corpocessor.
>>>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>>>> assigned to one of the three domains.
>>>>
>>> You fail to explain why do we need this in non-secure Linux ?
>>> You need to have solid reasons as why this can't be done in secure
>>> firmware. And yes I mean even on arm32. On platforms with such hardware
>>> capabilities you will need some secure firmware to be running and these
>>> things can be done there. I don't want this enabled for ARM64 at all,
>>> firmware *has to deal* with this.
>> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex
>> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change
>> hardware block split at runtime. This could be done even on non-secure world
>> because their is nothing critical to change hardware blocks users.
> OK, that's interesting, assuming Cortex M4 execution as non-secure. I would
> expect otherwise. Even if it's configurable, I would see that happen in
> secure entity via OPTEE or something similar from non-secure side.
Your assumption is correct Cortex M4 execution is non-secure.
>
> Do you have any documents that I can refer to get the overall security
> design for such platforms ?
SoC datasheet is here:
https://www.st.com/resource/en/datasheet/stm32mp157a.pdf
with just few words about ETZPC:
3.14 TrustZone protection controller (ETZPC)
ETZPC is used to configure TrustZone security of bus masters and slaves with
programmable-security attributes (securable resources) such as:
• On-chip SYSRAM with programmable secure region size
• AHB and APB peripherals to be made secure
Notice that by default, SYSRAM and peripheral are set to secure access
only, so, not
accessible by non-secure masters such as Cortex-M4 or DMA1/DMA2.
ETZPC can also allocate peripherals and SRAM to be accessible only by
the Cortex-M4
and/or DMA1/DMA2. This ensures the safe execution of the Cortex-M4
firmware, protected
from other masters (e.g. Cortex-A7) unwanted accesses.
Benjamin
>
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-04-23 13:33 ` Benjamin GAIGNARD
@ 2019-04-23 13:55 ` Sudeep Holla
2019-04-23 14:17 ` Benjamin GAIGNARD
0 siblings, 1 reply; 18+ messages in thread
From: Sudeep Holla @ 2019-04-23 13:55 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
On Tue, Apr 23, 2019 at 01:33:19PM +0000, Benjamin GAIGNARD wrote:
>
> On 4/23/19 3:21 PM, Sudeep Holla wrote:
> > On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote:
> >> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
> >>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> >>>> Bus domains controllers allow to divided system on chip into multiple domains
> >>>> that can be used to select by who hardware blocks could be accessed.
> >>>> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
> >>>> a group of hardware blocks.
> >>>>
> >>>> Framework architecture is inspirated by pinctrl framework:
> >>>> - a default configuration could be applied before bind the driver
> >>>> - configurations could be apllied dynamically by drivers
> >>>> - device node provides the bus domains configurations
> >>>>
> >>>> An example of bus domains controller is STM32 ETZPC hardware block
> >>>> which got 3 domains:
> >>>> - secure: hardware blocks are only accessible by software running on trust
> >>>> zone.
> >>>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
> >>>> linux kernel).
> >>>> - coprocessor: hardware blocks are only accessible by the corpocessor.
> >>>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
> >>>> assigned to one of the three domains.
> >>>>
> >>> You fail to explain why do we need this in non-secure Linux ?
> >>> You need to have solid reasons as why this can't be done in secure
> >>> firmware. And yes I mean even on arm32. On platforms with such hardware
> >>> capabilities you will need some secure firmware to be running and these
> >>> things can be done there. I don't want this enabled for ARM64 at all,
> >>> firmware *has to deal* with this.
> >> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex
> >> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change
> >> hardware block split at runtime. This could be done even on non-secure world
> >> because their is nothing critical to change hardware blocks users.
> > OK, that's interesting, assuming Cortex M4 execution as non-secure. I would
> > expect otherwise. Even if it's configurable, I would see that happen in
> > secure entity via OPTEE or something similar from non-secure side.
> Your assumption is correct Cortex M4 execution is non-secure.
Sorry if I was not clear. I told Cortex M4 non-secure execution is interesting
as I expected it to be secure.
> >
> > Do you have any documents that I can refer to get the overall security
> > design for such platforms ?
>
> SoC datasheet is here:
>
> https://www.st.com/resource/en/datasheet/stm32mp157a.pdf
>
> with just few words about ETZPC:
>
> 3.14 TrustZone protection controller (ETZPC)
> ETZPC is used to configure TrustZone security of bus masters and slaves with
> programmable-security attributes (securable resources) such as:
> • On-chip SYSRAM with programmable secure region size
> • AHB and APB peripherals to be made secure
> Notice that by default, SYSRAM and peripheral are set to secure access
> only, so, not accessible by non-secure masters such as Cortex-M4 or DMA1/DMA2.
> ETZPC can also allocate peripherals and SRAM to be accessible only by
> the Cortex-M4 and/or DMA1/DMA2. This ensures the safe execution of the
> Cortex-M4 firmware, protected from other masters (e.g. Cortex-A7) unwanted
> accesses.
>
The above statement makes me wonder if Cortex-M4 firmware is really
non-secure, if so why does it need such an isolation from other masters
like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute
in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as
mentioned in the above excerpts from the datasheet.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-04-23 13:55 ` Sudeep Holla
@ 2019-04-23 14:17 ` Benjamin GAIGNARD
2019-04-25 18:01 ` Mark Brown
0 siblings, 1 reply; 18+ messages in thread
From: Benjamin GAIGNARD @ 2019-04-23 14:17 UTC (permalink / raw)
To: Sudeep Holla
Cc: Benjamin Gaignard, Mark Brown, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
On 4/23/19 3:55 PM, Sudeep Holla wrote:
> On Tue, Apr 23, 2019 at 01:33:19PM +0000, Benjamin GAIGNARD wrote:
>> On 4/23/19 3:21 PM, Sudeep Holla wrote:
>>> On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote:
>>>> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <sudeep.holla@arm.com> a écrit :
>>>>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
>>>>>> Bus domains controllers allow to divided system on chip into multiple domains
>>>>>> that can be used to select by who hardware blocks could be accessed.
>>>>>> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
>>>>>> a group of hardware blocks.
>>>>>>
>>>>>> Framework architecture is inspirated by pinctrl framework:
>>>>>> - a default configuration could be applied before bind the driver
>>>>>> - configurations could be apllied dynamically by drivers
>>>>>> - device node provides the bus domains configurations
>>>>>>
>>>>>> An example of bus domains controller is STM32 ETZPC hardware block
>>>>>> which got 3 domains:
>>>>>> - secure: hardware blocks are only accessible by software running on trust
>>>>>> zone.
>>>>>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>>>>>> linux kernel).
>>>>>> - coprocessor: hardware blocks are only accessible by the corpocessor.
>>>>>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>>>>>> assigned to one of the three domains.
>>>>>>
>>>>> You fail to explain why do we need this in non-secure Linux ?
>>>>> You need to have solid reasons as why this can't be done in secure
>>>>> firmware. And yes I mean even on arm32. On platforms with such hardware
>>>>> capabilities you will need some secure firmware to be running and these
>>>>> things can be done there. I don't want this enabled for ARM64 at all,
>>>>> firmware *has to deal* with this.
>>>> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex
>>>> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change
>>>> hardware block split at runtime. This could be done even on non-secure world
>>>> because their is nothing critical to change hardware blocks users.
>>> OK, that's interesting, assuming Cortex M4 execution as non-secure. I would
>>> expect otherwise. Even if it's configurable, I would see that happen in
>>> secure entity via OPTEE or something similar from non-secure side.
>> Your assumption is correct Cortex M4 execution is non-secure.
> Sorry if I was not clear. I told Cortex M4 non-secure execution is interesting
> as I expected it to be secure.
>
>>> Do you have any documents that I can refer to get the overall security
>>> design for such platforms ?
>> SoC datasheet is here:
>>
>> https://www.st.com/resource/en/datasheet/stm32mp157a.pdf
>>
>> with just few words about ETZPC:
>>
>> 3.14 TrustZone protection controller (ETZPC)
>> ETZPC is used to configure TrustZone security of bus masters and slaves with
>> programmable-security attributes (securable resources) such as:
>> • On-chip SYSRAM with programmable secure region size
>> • AHB and APB peripherals to be made secure
>> Notice that by default, SYSRAM and peripheral are set to secure access
>> only, so, not accessible by non-secure masters such as Cortex-M4 or DMA1/DMA2.
>> ETZPC can also allocate peripherals and SRAM to be accessible only by
>> the Cortex-M4 and/or DMA1/DMA2. This ensures the safe execution of the
>> Cortex-M4 firmware, protected from other masters (e.g. Cortex-A7) unwanted
>> accesses.
>>
> The above statement makes me wonder if Cortex-M4 firmware is really
> non-secure, if so why does it need such an isolation from other masters
> like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute
> in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as
> mentioned in the above excerpts from the datasheet.
Cortex-M4 firmware is non-secure, it could be a free RTOS.
ETZPC doesn't isolate Cortex M4 or A7 but control which of them have
access to hardware blocks.
For example ETZPC controls if M4 or A7 can have access to I2C hardware
blocks. The goal is to make sure
firmware running on each side don't use the hardware blocks of the other
side.
Benjamin
>
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
2019-04-23 14:17 ` Benjamin GAIGNARD
@ 2019-04-25 18:01 ` Mark Brown
0 siblings, 0 replies; 18+ messages in thread
From: Mark Brown @ 2019-04-25 18:01 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: Sudeep Holla, Benjamin Gaignard, Rob Herring, Arnd Bergmann,
Shawn Guo, s.hauer, Fabio Estevam, Loic PALLARDY,
Greg Kroah-Hartman, Linux Kernel Mailing List, linux-imx, kernel,
Linux ARM
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
On Tue, Apr 23, 2019 at 02:17:23PM +0000, Benjamin GAIGNARD wrote:
> On 4/23/19 3:55 PM, Sudeep Holla wrote:
> > The above statement makes me wonder if Cortex-M4 firmware is really
> > non-secure, if so why does it need such an isolation from other masters
> > like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute
> > in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as
> > mentioned in the above excerpts from the datasheet.
> Cortex-M4 firmware is non-secure, it could be a free RTOS.
> ETZPC doesn't isolate Cortex M4 or A7 but control which of them have
> access to hardware blocks.
> For example ETZPC controls if M4 or A7 can have access to I2C hardware
> blocks. The goal is to make sure
> firmware running on each side don't use the hardware blocks of the other
> side.
The goal AIUI is mainly for robustness rather than security - trying to
mitigate against any bugs that might happen, making them more apparent
during development and mititgating their impact if they slip through.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread