[RFC 0/7] Introduce bus domains controller framework

[RFC 0/7] Introduce bus domains controller framework

[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.

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.

It is an RFC, comments are welcome to help to create this framework, thanks.
Benjamin

Benjamin Gaignard (7):
  devicetree: bindings: Document domains controller bindings
  domainsctrl: Introduce domains controller framework
  base: Add calls to domains controller
  devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings
  bus: domainsctrl: Add driver for STM32 ETZPC controller
  ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC
  ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1

 .../bindings/bus/domains/domainsctrl.txt           |  35 +++
 .../bindings/bus/domains/st,stm32-etzpc.txt        |  14 ++
 arch/arm/boot/dts/stm32mp157c-ev1.dts              |   2 +
 arch/arm/boot/dts/stm32mp157c.dtsi                 |   7 +
 drivers/base/dd.c                                  |   9 +
 drivers/bus/Kconfig                                |   2 +
 drivers/bus/Makefile                               |   2 +
 drivers/bus/domains/Kconfig                        |  14 ++
 drivers/bus/domains/Makefile                       |   2 +
 drivers/bus/domains/domainsctrl.c                  | 234 +++++++++++++++++++++
 drivers/bus/domains/stm32-etzpc.c                  | 140 ++++++++++++
 include/dt-bindings/bus/domains/stm32-etzpc.h      |  25 +++
 include/linux/domainsctrl.h                        |  70 ++++++
 13 files changed, 556 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
 create mode 100644 Documentation/devicetree/bindings/bus/domains/st,stm32-etzpc.txt
 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 drivers/bus/domains/stm32-etzpc.c
 create mode 100644 include/dt-bindings/bus/domains/stm32-etzpc.h
 create mode 100644 include/linux/domainsctrl.h

-- 
2.15.0

[RFC 1/7] devicetree: bindings: Document domains controller bindings

[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           | 35 ++++++++++++++++++++++
 1 file changed, 35 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..11dadba4c1fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/domains/domainsctrl.txt
@@ -0,0 +1,35 @@
+Common Domains Controller bindings properties
+
+Domains Controller framework defines common bindings properties to describe
+the configurations to be applied for each device.
+
+Domains Controller bindings:
+- #domainctrl-cells	: provide the number of parameters provided with the
+			  phandle by the client device
+
+Client device node bindings:
+- domainsctrl-names	: list of strings to name the configurations.
+			  "default" and "unbind" are reserved names used by
+			  the framework.
+- domainsctrl-X		: list of configurations to be applied where X is
+			  the index of the configuration within the node.
+
+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

[RFC 2/7] domainsctrl: Introduce domains controller framework

[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>
---
 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

[RFC 3/7] base: Add calls to domains controller

[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>
---
 drivers/base/dd.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8ac10af17c00..2880fe893096 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>
@@ -478,6 +479,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)
@@ -548,6 +553,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);
@@ -970,6 +977,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
 		device_links_driver_cleanup(dev);
 		arch_teardown_dma_ops(dev);
 
+		domainsctrl_set_config_by_name(dev, "unbind");
+
 		devres_release_all(dev);
 		dev->driver = NULL;
 		dev_set_drvdata(dev, NULL);
-- 
2.15.0

[RFC 4/7] devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings

[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

[RFC 5/7] bus: domainsctrl: Add driver for STM32 ETZPC controller

[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

[RFC 6/7] ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC

[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 8bf1c17f8cef..d15510a78630 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1106,6 +1106,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

[RFC 7/7] ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1

[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 063ee8ac5dcb..29142ca3d685 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

Re: [RFC 1/7] devicetree: bindings: Document domains controller bindings

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Mon, Jan 14, 2019 at 03:41:56PM +0100, Benjamin Gaignard wrote:

> +Common Domains Controller bindings properties
> +
> +Domains Controller framework defines common bindings properties to describe
> +the configurations to be applied for each device.

I suspect this is going to need a few more words about what a Domains
Controller is.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC 1/7] devicetree: bindings: Document domains controller bindings

[Benjamin GAIGNARD]

On 1/16/19 6:30 PM, Mark Brown wrote:
> On Mon, Jan 14, 2019 at 03:41:56PM +0100, Benjamin Gaignard wrote:
>
>> +Common Domains Controller bindings properties
>> +
>> +Domains Controller framework defines common bindings properties to describe
>> +the configurations to be applied for each device.
> I suspect this is going to need a few more words about what a Domains
> Controller is.

Does the description of the framework in the cover letter looks better 
for you ?

I'm not comfortable to put it in bindings file but maybe I'm wrong.

Re: [RFC 1/7] devicetree: bindings: Document domains controller bindings

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Thu, Jan 17, 2019 at 01:20:45PM +0000, Benjamin GAIGNARD wrote:
> On 1/16/19 6:30 PM, Mark Brown wrote:

> > I suspect this is going to need a few more words about what a Domains
> > Controller is.

> Does the description of the framework in the cover letter looks better 
> for you ?

Yes, that looks reasonable to me.

> I'm not comfortable to put it in bindings file but maybe I'm wrong.

I can't see how someone will understand the binding document as a
standalone document - it's not like domains controllers are a widely
understood concept in the industry.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC 2/7] domainsctrl: Introduce domains controller framework

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Mon, Jan 14, 2019 at 03:41:57PM +0100, Benjamin Gaignard wrote:

> Configurations could be applied with functions like
> domainsctrl_set_config_by_index() or domainsctrl_set_config_by_name().

Do you have any clients in the works for this?  It seems fairly likely
that everything is fine in terms of setting the mode but it'd be good to
confirm that's the case.  The main thing I can think of that might be a
problem here is how you'd handle a case where we were talking to another
processor that owns the permissions, we'd probably want more ways to
query state there but I'm thinking there'd likely be some other higher
level way to talk to the other processor there so perhaps it's moot.

Otherwise this all looks pretty clean and simple, there's some handling
for probe deferral in there which is the only slightly complex thing I
noticed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC 0/7] Introduce bus domains controller framework

[Rob Herring]

On Mon, Jan 14, 2019 at 8:42 AM Benjamin Gaignard
<benjamin.gaignard@st.com> wrote:
>
> 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.

Lots of things are domains. Power domains, clock domains, etc. But
naming is hard.

We now have the inter-connect binding which ATM only deals with
bandwidth. Any reason we can't add access controls to that?

> 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.
>
> 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.

We already have a way to assign secure vs. non-secure with 'status'.
Ignoring co-processors for a minute, why does that not work for you?

Co-processors are so varied in terms of capabilities and view of the
system, I'm not sure we can define something generic.

> Up to 94 hardware blocks of the soc could be managed by ETZPC and
> assigned to one of the three domains.
>
> It is an RFC, comments are welcome to help to create this framework, thanks.

Finally, for a new, common binding, I'd like to see more than one
platform using it (or at least an intent to use it).

Rob

Re: [RFC 2/7] domainsctrl: Introduce domains controller framework

[Benjamin GAIGNARD]

On 1/17/19 6:27 PM, Mark Brown wrote:
> On Mon, Jan 14, 2019 at 03:41:57PM +0100, Benjamin Gaignard wrote:
>
>> Configurations could be applied with functions like
>> domainsctrl_set_config_by_index() or domainsctrl_set_config_by_name().
> Do you have any clients in the works for this?  It seems fairly likely
> that everything is fine in terms of setting the mode but it'd be good to
> confirm that's the case.  The main thing I can think of that might be a
> problem here is how you'd handle a case where we were talking to another
> processor that owns the permissions, we'd probably want more ways to
> query state there but I'm thinking there'd likely be some other higher
> level way to talk to the other processor there so perhaps it's moot.

Patch 3 use those functions to apply the default configuration before probing
a driver (or after unbind it). I have in mind that drivers could ask to apply
a configuration like it is done for pinctrl in resume/suspend functions.
An example of that could be to start the hardware block on the main processor
and, when going to sleep, change the configuration to grant the access to lower
power processor.

I think that talking to a remote processor is another problem already addressed
remoteproc or secure monitor calls. Domains controllers drivers should be created
for those cases.

>
> Otherwise this all looks pretty clean and simple, there's some handling
> for probe deferral in there which is the only slightly complex thing I
> noticed.

Re: [RFC 0/7] Introduce bus domains controller framework

[Benjamin GAIGNARD]

On 1/17/19 6:57 PM, Rob Herring wrote:
> On Mon, Jan 14, 2019 at 8:42 AM Benjamin Gaignard
> <benjamin.gaignard@st.com> wrote:
>> 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.
> Lots of things are domains. Power domains, clock domains, etc. But
> naming is hard.

I use 'domains' because it regroup hardware sharing the same access rights.
It is maybe not the best word.

>
> We now have the inter-connect binding which ATM only deals with
> bandwidth. Any reason we can't add access controls to that?

Because the targeted hardware block isn't the inter-connect but something
that is acting as a firewall on the bus to control the accesses rights on
hardware blocks.
'bus firewall' could have been a name for this framework but, for me, it
sound like something related to networking and that is not the case...
I could go in 'firewall' direction: driver will become 'bus firewall controller'
and apply 'firewall configurations' to grant/revoke accesses rights.
Does that sound better for you ?

>
>> 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.
>>
>> 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.
> We already have a way to assign secure vs. non-secure with 'status'.
> Ignoring co-processors for a minute, why does that not work for you?

I aim to be able to dynamically change the configuration (like for pinctrl)
so status is not enough. It is true that stm32 etzpc is limited to control
the split between main and remote processors but other controllers could have
another granularity.

>
> Co-processors are so varied in terms of capabilities and view of the
> system, I'm not sure we can define something generic.

It isn't not about define co-precessors capabilities but about define
a new API for hardware blocks controlling accesses on the bus.

>
>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>> assigned to one of the three domains.
>>
>> It is an RFC, comments are welcome to help to create this framework, thanks.
> Finally, for a new, common binding, I'd like to see more than one
> platform using it (or at least an intent to use it).

I kwon at least two other hardware block who can take benefits of this:
- ARM TCZ 400: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0504c/index.html
   which is able to manage up to 8 regoins in address space.
- IMX Ressource Domain Controller (RDC): supports four domains and up to eight regions

I hope that others will show up when reading this thread.

Benjamin


>
> Rob

Re: [RFC 2/7] domainsctrl: Introduce domains controller framework

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Fri, Jan 18, 2019 at 09:26:45AM +0000, Benjamin GAIGNARD wrote:
> On 1/17/19 6:27 PM, Mark Brown wrote:
> > On Mon, Jan 14, 2019 at 03:41:57PM +0100, Benjamin Gaignard wrote:

> > Do you have any clients in the works for this?  It seems fairly likely
> > that everything is fine in terms of setting the mode but it'd be good to
> > confirm that's the case.  The main thing I can think of that might be a

> Patch 3 use those functions to apply the default configuration before probing
> a driver (or after unbind it). I have in mind that drivers could ask to apply

Right, I saw that but I was more thinking of individual drivers.

> a configuration like it is done for pinctrl in resume/suspend functions.
> An example of that could be to start the hardware block on the main processor
> and, when going to sleep, change the configuration to grant the access to lower
> power processor.

Yes, that sounds like a good application.  I can also imagine something
like handing some hardware over to an acceleration engine (or a smaller
microcontroller core acting as one).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]