* [PATCH v5 1/7] remoteproc: Add TEE support
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
@ 2024-05-21 8:09 ` Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
` (5 subsequent siblings)
6 siblings, 0 replies; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:09 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware in the secure part.
This firmware could be authenticated by the secure trusted application.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
update from V4
- fix commit message,
- fix Kconfig typo,
- introduce tee_rproc_release_loaded_rsc_table function to release the
resource table,
- reorder function variables in declaration in reverse ascending order,
- introduce try_module_get and module_put to prevent module removed while
used,
- remove rsc_table field in tee_rproc structure,
- remove tee_rproc_find_loaded_rsc_table as seems not correspond to the
propoer usage regarding ops definition [1]. The resource table is
loaded before used,
- add __force attribute when cast the type aof the resource table to fix
build warning.
[1]https://elixir.bootlin.com/linux/latest/source/include/linux/remoteproc.h#L374
---
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/tee_remoteproc.c | 429 ++++++++++++++++++++++++++++
include/linux/remoteproc.h | 4 +
include/linux/tee_remoteproc.h | 99 +++++++
5 files changed, 543 insertions(+)
create mode 100644 drivers/remoteproc/tee_remoteproc.c
create mode 100644 include/linux/tee_remoteproc.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa85..6c1c07202276 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
It's safe to say N if not interested in using RPU r5f cores.
+
+config TEE_REMOTEPROC
+ tristate "Remoteproc support by a TEE application"
+ depends on OPTEE
+ help
+ Support a remote processor with a TEE application. The Trusted
+ Execution Context is responsible for loading the trusted firmware
+ image and managing the remote processor's lifecycle.
+ This can be either built-in or a loadable module.
+
endif # REMOTEPROC
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43ce..fa8daebce277 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC) += rcar_rproc.o
obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
+obj-$(CONFIG_TEE_REMOTEPROC) += tee_remoteproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/tee_remoteproc.c b/drivers/remoteproc/tee_remoteproc.c
new file mode 100644
index 000000000000..f13546628ec9
--- /dev/null
+++ b/drivers/remoteproc/tee_remoteproc.c
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) STMicroelectronics 2024 - All Rights Reserved
+ * Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
+ */
+
+#include <linux/firmware.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/remoteproc.h>
+#include <linux/slab.h>
+#include <linux/tee_drv.h>
+#include <linux/tee_remoteproc.h>
+
+#include "remoteproc_internal.h"
+
+#define MAX_TEE_PARAM_ARRY_MEMBER 4
+
+/*
+ * Authentication of the firmware and load in the remote processor memory
+ *
+ * [in] params[0].value.a: unique 32bit identifier of the remote processor
+ * [in] params[1].memref: buffer containing the image of the buffer
+ */
+#define TA_RPROC_FW_CMD_LOAD_FW 1
+
+/*
+ * Start the remote processor
+ *
+ * [in] params[0].value.a: unique 32bit identifier of the remote processor
+ */
+#define TA_RPROC_FW_CMD_START_FW 2
+
+/*
+ * Stop the remote processor
+ *
+ * [in] params[0].value.a: unique 32bit identifier of the remote processor
+ */
+#define TA_RPROC_FW_CMD_STOP_FW 3
+
+/*
+ * Return the address of the resource table, or 0 if not found
+ * No check is done to verify that the address returned is accessible by
+ * the non secure context. If the resource table is loaded in a protected
+ * memory the access by the non secure context will lead to a data abort.
+ *
+ * [in] params[0].value.a: unique 32bit identifier of the remote processor
+ * [out] params[1].value.a: 32bit LSB resource table memory address
+ * [out] params[1].value.b: 32bit MSB resource table memory address
+ * [out] params[2].value.a: 32bit LSB resource table memory size
+ * [out] params[2].value.b: 32bit MSB resource table memory size
+ */
+#define TA_RPROC_FW_CMD_GET_RSC_TABLE 4
+
+/*
+ * Return the address of the core dump
+ *
+ * [in] params[0].value.a: unique 32bit identifier of the remote processor
+ * [out] params[1].memref: address of the core dump image if exist,
+ * else return Null
+ */
+#define TA_RPROC_FW_CMD_GET_COREDUMP 5
+
+struct tee_rproc_context {
+ struct list_head sessions;
+ struct tee_context *tee_ctx;
+ struct device *dev;
+};
+
+static struct tee_rproc_context *tee_rproc_ctx;
+
+static void tee_rproc_prepare_args(struct tee_rproc *trproc, int cmd,
+ struct tee_ioctl_invoke_arg *arg,
+ struct tee_param *param,
+ unsigned int num_params)
+{
+ memset(arg, 0, sizeof(*arg));
+ memset(param, 0, MAX_TEE_PARAM_ARRY_MEMBER * sizeof(*param));
+
+ arg->func = cmd;
+ arg->session = trproc->session_id;
+ arg->num_params = num_params + 1;
+
+ param[0] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
+ .u.value.a = trproc->rproc_id,
+ };
+}
+
+static void tee_rproc_release_loaded_rsc_table(struct rproc *rproc)
+{
+ if (rproc->table_ptr) {
+ iounmap((__force __iomem void *)rproc->table_ptr);
+ /*
+ * Use a copy of the resource table for the remainder of the
+ * shutdown or recovery process.
+ */
+ rproc->table_ptr = rproc->cached_table;
+ }
+}
+
+int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
+ struct tee_rproc *trproc = rproc->tee_interface;
+ struct tee_ioctl_invoke_arg arg;
+ struct tee_shm *fw_shm;
+ int ret;
+
+ if (!trproc)
+ return -EINVAL;
+
+ fw_shm = tee_shm_register_kernel_buf(tee_rproc_ctx->tee_ctx, (void *)fw->data, fw->size);
+ if (IS_ERR(fw_shm))
+ return PTR_ERR(fw_shm);
+
+ tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_LOAD_FW, &arg, param, 1);
+
+ /* Provide the address of the firmware image */
+ param[1] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
+ .u.memref = {
+ .shm = fw_shm,
+ .size = fw->size,
+ .shm_offs = 0,
+ },
+ };
+
+ ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
+ if (ret < 0 || arg.ret != 0) {
+ dev_err(tee_rproc_ctx->dev,
+ "TA_RPROC_FW_CMD_LOAD_FW invoke failed TEE err: %x, ret:%x\n",
+ arg.ret, ret);
+ if (!ret)
+ ret = -EIO;
+ }
+
+ tee_shm_free(fw_shm);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_load_fw);
+
+struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
+{
+ struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
+ struct tee_rproc *trproc = rproc->tee_interface;
+ struct resource_table *rsc_table;
+ struct tee_ioctl_invoke_arg arg;
+ int ret;
+
+ if (!trproc)
+ return ERR_PTR(-EINVAL);
+
+ tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_GET_RSC_TABLE, &arg, param, 2);
+
+ param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+ param[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+ ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
+ if (ret < 0 || arg.ret != 0) {
+ dev_err(tee_rproc_ctx->dev,
+ "TA_RPROC_FW_CMD_GET_RSC_TABLE invoke failed TEE err: %x, ret:%x\n",
+ arg.ret, ret);
+ return ERR_PTR(-EIO);
+ }
+
+ *table_sz = param[2].u.value.a;
+
+ /* If the size is null no resource table defined in the image */
+ if (!*table_sz)
+ return NULL;
+
+ /* Store the resource table address that would be updated by the remote core. */
+ rsc_table = (__force struct resource_table *)ioremap_wc(param[1].u.value.a, *table_sz);
+ if (IS_ERR_OR_NULL(rsc_table)) {
+ dev_err(tee_rproc_ctx->dev, "Unable to map memory region: %lld+%zx\n",
+ param[1].u.value.a, *table_sz);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return rsc_table;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_get_loaded_rsc_table);
+
+int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ struct resource_table *rsc_table;
+ size_t table_sz;
+ int ret;
+
+ ret = tee_rproc_load_fw(rproc, fw);
+ if (ret)
+ return ret;
+
+ rsc_table = rproc_get_loaded_rsc_table(rproc, &table_sz);
+ if (IS_ERR(rsc_table))
+ return PTR_ERR(rsc_table);
+
+ rproc->table_ptr = rsc_table;
+ rproc->table_sz = table_sz;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_parse_fw);
+
+int tee_rproc_start(struct rproc *rproc)
+{
+ struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
+ struct tee_rproc *trproc = rproc->tee_interface;
+ struct tee_ioctl_invoke_arg arg;
+ int ret = 0;
+
+ if (!trproc) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_START_FW, &arg, param, 0);
+
+ ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
+ if (ret < 0 || arg.ret != 0) {
+ dev_err(tee_rproc_ctx->dev,
+ "TA_RPROC_FW_CMD_START_FW invoke failed TEE err: %x, ret:%x\n",
+ arg.ret, ret);
+ if (!ret)
+ ret = -EIO;
+ goto err;
+ }
+
+ return 0;
+
+err:
+ tee_rproc_release_loaded_rsc_table(rproc);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_start);
+
+int tee_rproc_stop(struct rproc *rproc)
+{
+ struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
+ struct tee_rproc *trproc = rproc->tee_interface;
+ struct tee_ioctl_invoke_arg arg;
+ int ret;
+
+ if (!trproc)
+ return -EINVAL;
+
+ tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_STOP_FW, &arg, param, 0);
+
+ ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
+ if (ret < 0 || arg.ret != 0) {
+ dev_err(tee_rproc_ctx->dev,
+ "TA_RPROC_FW_CMD_STOP_FW invoke failed TEE err: %x, ret:%x\n",
+ arg.ret, ret);
+ if (!ret)
+ ret = -EIO;
+ }
+
+ tee_rproc_release_loaded_rsc_table(rproc);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_stop);
+
+static const struct tee_client_device_id stm32_tee_rproc_id_table[] = {
+ {UUID_INIT(0x80a4c275, 0x0a47, 0x4905,
+ 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
+ {}
+};
+
+struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc, unsigned int rproc_id)
+{
+ struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
+ struct tee_ioctl_open_session_arg sess_arg;
+ struct tee_client_device *tee_device;
+ struct tee_rproc *trproc, *p_err;
+ int ret;
+
+ /*
+ * Test if the device has been probed by the TEE bus. In case of failure, we ignore the
+ * reason. The bus could be not yet probed or the service not available in the secure
+ * firmware.The assumption in such a case is that the TEE remoteproc is not probed.
+ */
+ if (!tee_rproc_ctx)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ /* Prevent tee rproc module from being removed */
+ if (!try_module_get(THIS_MODULE)) {
+ dev_err(tee_rproc_ctx->dev, "can't get owner\n");
+ p_err = ERR_PTR(-ENODEV);
+ goto module_put;
+ }
+
+ trproc = devm_kzalloc(dev, sizeof(*trproc), GFP_KERNEL);
+ if (!trproc) {
+ p_err = ERR_PTR(-ENOMEM);
+ goto module_put;
+ }
+ tee_device = to_tee_client_device(tee_rproc_ctx->dev);
+ memset(&sess_arg, 0, sizeof(sess_arg));
+
+ memcpy(sess_arg.uuid, tee_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
+
+ sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
+ sess_arg.num_params = 1;
+
+ param[0] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
+ .u.value.a = rproc_id,
+ };
+
+ ret = tee_client_open_session(tee_rproc_ctx->tee_ctx, &sess_arg, param);
+ if (ret < 0 || sess_arg.ret != 0) {
+ dev_err(dev, "tee_client_open_session failed, err: %x\n", sess_arg.ret);
+ p_err = ERR_PTR(-EINVAL);
+ goto module_put;
+ }
+
+ trproc->parent = dev;
+ trproc->rproc_id = rproc_id;
+ trproc->session_id = sess_arg.session;
+
+ trproc->rproc = rproc;
+ rproc->tee_interface = trproc;
+
+ list_add_tail(&trproc->node, &tee_rproc_ctx->sessions);
+
+ return trproc;
+
+module_put:
+ module_put(THIS_MODULE);
+ return p_err;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_register);
+
+int tee_rproc_unregister(struct tee_rproc *trproc)
+{
+ struct rproc *rproc = trproc->rproc;
+ int ret;
+
+ ret = tee_client_close_session(tee_rproc_ctx->tee_ctx, trproc->session_id);
+ if (ret < 0)
+ dev_err(trproc->parent, "tee_client_close_session failed, err: %x\n", ret);
+
+ list_del(&trproc->node);
+ rproc->tee_interface = NULL;
+
+ module_put(THIS_MODULE);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tee_rproc_unregister);
+
+static int tee_rproc_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+ /* Today we support only the OP-TEE, could be extend to other tees */
+ return (ver->impl_id == TEE_IMPL_ID_OPTEE);
+}
+
+static int tee_rproc_probe(struct device *dev)
+{
+ struct tee_context *tee_ctx;
+ int ret;
+
+ /* Open context with TEE driver */
+ tee_ctx = tee_client_open_context(NULL, tee_rproc_ctx_match, NULL, NULL);
+ if (IS_ERR(tee_ctx))
+ return PTR_ERR(tee_ctx);
+
+ tee_rproc_ctx = devm_kzalloc(dev, sizeof(*tee_ctx), GFP_KERNEL);
+ if (!tee_rproc_ctx) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ tee_rproc_ctx->dev = dev;
+ tee_rproc_ctx->tee_ctx = tee_ctx;
+ INIT_LIST_HEAD(&tee_rproc_ctx->sessions);
+
+ return 0;
+err:
+ tee_client_close_context(tee_ctx);
+
+ return ret;
+}
+
+static int tee_rproc_remove(struct device *dev)
+{
+ struct tee_rproc *entry, *tmp;
+
+ list_for_each_entry_safe(entry, tmp, &tee_rproc_ctx->sessions, node) {
+ tee_client_close_session(tee_rproc_ctx->tee_ctx, entry->session_id);
+ list_del(&entry->node);
+ kfree(entry);
+ }
+
+ tee_client_close_context(tee_rproc_ctx->tee_ctx);
+
+ return 0;
+}
+
+MODULE_DEVICE_TABLE(tee, stm32_tee_rproc_id_table);
+
+static struct tee_client_driver tee_rproc_fw_driver = {
+ .id_table = stm32_tee_rproc_id_table,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .bus = &tee_bus_type,
+ .probe = tee_rproc_probe,
+ .remove = tee_rproc_remove,
+ },
+};
+
+static int __init tee_rproc_fw_mod_init(void)
+{
+ return driver_register(&tee_rproc_fw_driver.driver);
+}
+
+static void __exit tee_rproc_fw_mod_exit(void)
+{
+ driver_unregister(&tee_rproc_fw_driver.driver);
+}
+
+module_init(tee_rproc_fw_mod_init);
+module_exit(tee_rproc_fw_mod_exit);
+
+MODULE_DESCRIPTION(" TEE remote processor control driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index b4795698d8c2..8b678009e481 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -503,6 +503,8 @@ enum rproc_features {
RPROC_MAX_FEATURES,
};
+struct tee_rproc;
+
/**
* struct rproc - represents a physical remote processor device
* @node: list node of this rproc object
@@ -545,6 +547,7 @@ enum rproc_features {
* @cdev: character device of the rproc
* @cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release
* @features: indicate remoteproc features
+ * @tee_interface: pointer to the remoteproc tee context
*/
struct rproc {
struct list_head node;
@@ -586,6 +589,7 @@ struct rproc {
struct cdev cdev;
bool cdev_put_on_release;
DECLARE_BITMAP(features, RPROC_MAX_FEATURES);
+ struct tee_rproc *tee_interface;
};
/**
diff --git a/include/linux/tee_remoteproc.h b/include/linux/tee_remoteproc.h
new file mode 100644
index 000000000000..7fbb5c3423a8
--- /dev/null
+++ b/include/linux/tee_remoteproc.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright(c) 2024 STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef TEE_REMOTEPROC_H
+#define TEE_REMOTEPROC_H
+
+#include <linux/tee_drv.h>
+#include <linux/firmware.h>
+#include <linux/remoteproc.h>
+
+struct rproc;
+
+/**
+ * struct tee_rproc - TEE remoteproc structure
+ * @node: Reference in list
+ * @rproc: Remoteproc reference
+ * @parent: Parent device
+ * @rproc_id: Identifier of the target firmware
+ * @session_id: TEE session identifier
+ */
+struct tee_rproc {
+ struct list_head node;
+ struct rproc *rproc;
+ struct device *parent;
+ u32 rproc_id;
+ u32 session_id;
+};
+
+#if IS_REACHABLE(CONFIG_TEE_REMOTEPROC)
+
+struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
+ unsigned int rproc_id);
+int tee_rproc_unregister(struct tee_rproc *trproc);
+int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw);
+int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw);
+struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz);
+int tee_rproc_start(struct rproc *rproc);
+int tee_rproc_stop(struct rproc *rproc);
+
+#else
+
+static inline struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
+ unsigned int rproc_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return 0;
+}
+
+static inline int tee_rproc_unregister(struct tee_rproc *trproc)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return 0;
+}
+
+static inline int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return 0;
+}
+
+static inline int tee_rproc_start(struct rproc *rproc)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return 0;
+}
+
+static inline int tee_rproc_stop(struct rproc *rproc)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return 0;
+}
+
+static inline struct resource_table *
+tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return NULL;
+}
+#endif /* CONFIG_TEE_REMOTEPROC */
+#endif /* TEE_REMOTEPROC_H */
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 1/7] remoteproc: Add TEE support Arnaud Pouliquen
@ 2024-05-21 8:09 ` Arnaud Pouliquen
2024-05-21 9:24 ` Krzysztof Kozlowski
2024-05-28 20:08 ` Mathieu Poirier
2024-05-21 8:09 ` [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property Arnaud Pouliquen
` (4 subsequent siblings)
6 siblings, 2 replies; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:09 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
st,stm32mp1-m4-tee to support signed remoteproc firmware.
Based on DT properties, OP-TEE authenticates, loads, starts, and stops
the firmware.
- On Linux, when the compatibility is set, the Cortex-M resets should not
be declared in the device tree.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/remoteproc/st,stm32-rproc.yaml | 51 ++++++++++++++++---
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
index 370af61d8f28..36ea54016b76 100644
--- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -16,7 +16,12 @@ maintainers:
properties:
compatible:
- const: st,stm32mp1-m4
+ enum:
+ - st,stm32mp1-m4
+ - st,stm32mp1-m4-tee
+ description:
+ Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by non-secure context
+ Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context
reg:
description:
@@ -142,21 +147,41 @@ properties:
required:
- compatible
- reg
- - resets
allOf:
- if:
properties:
- reset-names:
- not:
- contains:
- const: hold_boot
+ compatible:
+ contains:
+ const: st,stm32mp1-m4
then:
+ if:
+ properties:
+ reset-names:
+ not:
+ contains:
+ const: hold_boot
+ then:
+ required:
+ - st,syscfg-holdboot
+ else:
+ properties:
+ st,syscfg-holdboot: false
+ required:
+ - reset-names
required:
- - st,syscfg-holdboot
- else:
+ - resets
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp1-m4-tee
+ then:
properties:
st,syscfg-holdboot: false
+ reset-names: false
+ resets: false
additionalProperties: false
@@ -188,5 +213,15 @@ examples:
st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
};
+ - |
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ m4@10000000 {
+ compatible = "st,stm32mp1-m4-tee";
+ reg = <0x10000000 0x40000>,
+ <0x30000000 0x40000>,
+ <0x38000000 0x10000>;
+ st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
+ st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
+ };
...
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
2024-05-21 8:09 ` [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
@ 2024-05-21 9:24 ` Krzysztof Kozlowski
2024-05-21 12:16 ` Arnaud POULIQUEN
2024-05-28 20:08 ` Mathieu Poirier
1 sibling, 1 reply; 20+ messages in thread
From: Krzysztof Kozlowski @ 2024-05-21 9:24 UTC (permalink / raw)
To: Arnaud Pouliquen, Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32
On 21/05/2024 10:09, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In OP-TEE, a node is defined in the device tree with the
> st,stm32mp1-m4-tee to support signed remoteproc firmware.
> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> the firmware.
> - On Linux, when the compatibility is set, the Cortex-M resets should not
> be declared in the device tree.
>
Not tested.
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline), work on fork of kernel
(don't, instead use mainline) or you ignore some maintainers (really
don't). Just use b4 and everything should be fine, although remember
about `b4 prep --auto-to-cc` if you added new patches to the patchset.
You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time, thus I will skip this patch entirely till you follow
the process allowing the patch to be tested.
Please kindly resend and include all necessary To/Cc entries.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
2024-05-21 9:24 ` Krzysztof Kozlowski
@ 2024-05-21 12:16 ` Arnaud POULIQUEN
0 siblings, 0 replies; 20+ messages in thread
From: Arnaud POULIQUEN @ 2024-05-21 12:16 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32
On 5/21/24 11:24, Krzysztof Kozlowski wrote:
> On 21/05/2024 10:09, Arnaud Pouliquen wrote:
>> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
>> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
>> (TEE).
>> For instance, this compatible is used in both the Linux and OP-TEE
>> device-tree:
>> - In OP-TEE, a node is defined in the device tree with the
>> st,stm32mp1-m4-tee to support signed remoteproc firmware.
>> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
>> the firmware.
>> - On Linux, when the compatibility is set, the Cortex-M resets should not
>> be declared in the device tree.
>>
>
> Not tested.
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
>
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline), work on fork of kernel
> (don't, instead use mainline) or you ignore some maintainers (really
> don't). Just use b4 and everything should be fine, although remember
> about `b4 prep --auto-to-cc` if you added new patches to the patchset.
>
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling. Performing review on untested code might be
> a waste of time, thus I will skip this patch entirely till you follow
> the process allowing the patch to be tested.
>
> Please kindly resend and include all necessary To/Cc entries.
I apologize for this oversight; I will resend the pull request and adding
the missing CC and To.
Thanks!
Arnaud
>
> Best regards,
> Krzysztof
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
2024-05-21 8:09 ` [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
2024-05-21 9:24 ` Krzysztof Kozlowski
@ 2024-05-28 20:08 ` Mathieu Poirier
1 sibling, 0 replies; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-28 20:08 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Tue, May 21, 2024 at 10:09:56AM +0200, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In OP-TEE, a node is defined in the device tree with the
> st,stm32mp1-m4-tee to support signed remoteproc firmware.
> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> the firmware.
I don't see how firmware can be started and stopped. Please rework.
> - On Linux, when the compatibility is set, the Cortex-M resets should not
> be declared in the device tree.
This is a description of "what" is happening and not "why".
More comments to come shortly.
Thanks,
Mathieu
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/remoteproc/st,stm32-rproc.yaml | 51 ++++++++++++++++---
> 1 file changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> index 370af61d8f28..36ea54016b76 100644
> --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> @@ -16,7 +16,12 @@ maintainers:
>
> properties:
> compatible:
> - const: st,stm32mp1-m4
> + enum:
> + - st,stm32mp1-m4
> + - st,stm32mp1-m4-tee
> + description:
> + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by non-secure context
> + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context
>
> reg:
> description:
> @@ -142,21 +147,41 @@ properties:
> required:
> - compatible
> - reg
> - - resets
>
> allOf:
> - if:
> properties:
> - reset-names:
> - not:
> - contains:
> - const: hold_boot
> + compatible:
> + contains:
> + const: st,stm32mp1-m4
> then:
> + if:
> + properties:
> + reset-names:
> + not:
> + contains:
> + const: hold_boot
> + then:
> + required:
> + - st,syscfg-holdboot
> + else:
> + properties:
> + st,syscfg-holdboot: false
> + required:
> + - reset-names
> required:
> - - st,syscfg-holdboot
> - else:
> + - resets
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: st,stm32mp1-m4-tee
> + then:
> properties:
> st,syscfg-holdboot: false
> + reset-names: false
> + resets: false
>
> additionalProperties: false
>
> @@ -188,5 +213,15 @@ examples:
> st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
> st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
> };
> + - |
> + #include <dt-bindings/reset/stm32mp1-resets.h>
> + m4@10000000 {
> + compatible = "st,stm32mp1-m4-tee";
> + reg = <0x10000000 0x40000>,
> + <0x30000000 0x40000>,
> + <0x38000000 0x10000>;
> + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
> + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
> + };
>
> ...
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 1/7] remoteproc: Add TEE support Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
@ 2024-05-21 8:09 ` Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function Arnaud Pouliquen
` (3 subsequent siblings)
6 siblings, 0 replies; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:09 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
Add the "st,proc-id" property allowing to identify the remote processor.
This ID is used to define an unique ID, common between Linux, U-boot and
OP-TEE to identify a coprocessor.
This ID will be used in request to OP-TEE remoteproc Trusted Application
to specify the remote processor.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
.../devicetree/bindings/remoteproc/st,stm32-rproc.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
index 36ea54016b76..409123cd4667 100644
--- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -48,6 +48,10 @@ properties:
- description: The offset of the hold boot setting register
- description: The field mask of the hold boot
+ st,proc-id:
+ description: remote processor identifier
+ $ref: /schemas/types.yaml#/definitions/uint32
+
st,syscfg-tz:
deprecated: true
description:
@@ -182,6 +186,8 @@ allOf:
st,syscfg-holdboot: false
reset-names: false
resets: false
+ required:
+ - st,proc-id
additionalProperties: false
@@ -220,6 +226,7 @@ examples:
reg = <0x10000000 0x40000>,
<0x30000000 0x40000>,
<0x38000000 0x10000>;
+ st,proc-id = <0>;
st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
};
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
` (2 preceding siblings ...)
2024-05-21 8:09 ` [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property Arnaud Pouliquen
@ 2024-05-21 8:09 ` Arnaud Pouliquen
2024-05-28 21:03 ` Mathieu Poirier
2024-05-21 8:09 ` [PATCH v5 5/7] remoteproc: core: support of the tee interface Arnaud Pouliquen
` (2 subsequent siblings)
6 siblings, 1 reply; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:09 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
Split rproc_start()to prepare the update of the management of
the cache table on start, for the support of the firmware loading
by the TEE interface.
- create rproc_set_rsc_table_on_start() to address the management of
the cache table in a specific function, as done in
rproc_reset_rsc_table_on_stop().
- rename rproc_set_rsc_table in rproc_set_rsc_table_on_attach()
- move rproc_reset_rsc_table_on_stop() to be close to the
rproc_set_rsc_table_on_start() function
Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
drivers/remoteproc/remoteproc_core.c | 116 ++++++++++++++-------------
1 file changed, 62 insertions(+), 54 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index f276956f2c5c..42bca01f3bde 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1264,18 +1264,9 @@ void rproc_resource_cleanup(struct rproc *rproc)
}
EXPORT_SYMBOL(rproc_resource_cleanup);
-static int rproc_start(struct rproc *rproc, const struct firmware *fw)
+static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
{
struct resource_table *loaded_table;
- struct device *dev = &rproc->dev;
- int ret;
-
- /* load the ELF segments to memory */
- ret = rproc_load_segments(rproc, fw);
- if (ret) {
- dev_err(dev, "Failed to load program segments: %d\n", ret);
- return ret;
- }
/*
* The starting device has been given the rproc->cached_table as the
@@ -1291,6 +1282,64 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
rproc->table_ptr = loaded_table;
}
+ return 0;
+}
+
+static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
+{
+ /* A resource table was never retrieved, nothing to do here */
+ if (!rproc->table_ptr)
+ return 0;
+
+ /*
+ * If a cache table exists the remote processor was started by
+ * the remoteproc core. That cache table should be used for
+ * the rest of the shutdown process.
+ */
+ if (rproc->cached_table)
+ goto out;
+
+ /*
+ * If we made it here the remote processor was started by another
+ * entity and a cache table doesn't exist. As such make a copy of
+ * the resource table currently used by the remote processor and
+ * use that for the rest of the shutdown process. The memory
+ * allocated here is free'd in rproc_shutdown().
+ */
+ rproc->cached_table = kmemdup(rproc->table_ptr,
+ rproc->table_sz, GFP_KERNEL);
+ if (!rproc->cached_table)
+ return -ENOMEM;
+
+ /*
+ * Since the remote processor is being switched off the clean table
+ * won't be needed. Allocated in rproc_set_rsc_table_on_start().
+ */
+ kfree(rproc->clean_table);
+
+out:
+ /*
+ * Use a copy of the resource table for the remainder of the
+ * shutdown process.
+ */
+ rproc->table_ptr = rproc->cached_table;
+ return 0;
+}
+
+static int rproc_start(struct rproc *rproc, const struct firmware *fw)
+{
+ struct device *dev = &rproc->dev;
+ int ret;
+
+ /* load the ELF segments to memory */
+ ret = rproc_load_segments(rproc, fw);
+ if (ret) {
+ dev_err(dev, "Failed to load program segments: %d\n", ret);
+ return ret;
+ }
+
+ rproc_set_rsc_table_on_start(rproc, fw);
+
ret = rproc_prepare_subdevices(rproc);
if (ret) {
dev_err(dev, "failed to prepare subdevices for %s: %d\n",
@@ -1450,7 +1499,7 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
return ret;
}
-static int rproc_set_rsc_table(struct rproc *rproc)
+static int rproc_set_rsc_table_on_attach(struct rproc *rproc)
{
struct resource_table *table_ptr;
struct device *dev = &rproc->dev;
@@ -1540,54 +1589,13 @@ static int rproc_reset_rsc_table_on_detach(struct rproc *rproc)
/*
* The clean resource table is no longer needed. Allocated in
- * rproc_set_rsc_table().
+ * rproc_set_rsc_table_on_attach().
*/
kfree(rproc->clean_table);
return 0;
}
-static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
-{
- /* A resource table was never retrieved, nothing to do here */
- if (!rproc->table_ptr)
- return 0;
-
- /*
- * If a cache table exists the remote processor was started by
- * the remoteproc core. That cache table should be used for
- * the rest of the shutdown process.
- */
- if (rproc->cached_table)
- goto out;
-
- /*
- * If we made it here the remote processor was started by another
- * entity and a cache table doesn't exist. As such make a copy of
- * the resource table currently used by the remote processor and
- * use that for the rest of the shutdown process. The memory
- * allocated here is free'd in rproc_shutdown().
- */
- rproc->cached_table = kmemdup(rproc->table_ptr,
- rproc->table_sz, GFP_KERNEL);
- if (!rproc->cached_table)
- return -ENOMEM;
-
- /*
- * Since the remote processor is being switched off the clean table
- * won't be needed. Allocated in rproc_set_rsc_table().
- */
- kfree(rproc->clean_table);
-
-out:
- /*
- * Use a copy of the resource table for the remainder of the
- * shutdown process.
- */
- rproc->table_ptr = rproc->cached_table;
- return 0;
-}
-
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal with the firmware image.
@@ -1614,7 +1622,7 @@ static int rproc_attach(struct rproc *rproc)
goto disable_iommu;
}
- ret = rproc_set_rsc_table(rproc);
+ ret = rproc_set_rsc_table_on_attach(rproc);
if (ret) {
dev_err(dev, "can't load resource table: %d\n", ret);
goto unprepare_device;
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function
2024-05-21 8:09 ` [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function Arnaud Pouliquen
@ 2024-05-28 21:03 ` Mathieu Poirier
0 siblings, 0 replies; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-28 21:03 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Tue, May 21, 2024 at 10:09:58AM +0200, Arnaud Pouliquen wrote:
> Split rproc_start()to prepare the update of the management of
I don't see any "splitting" for rproc_start() in this patch. Please consider
rewording or removing.
> the cache table on start, for the support of the firmware loading
> by the TEE interface.
> - create rproc_set_rsc_table_on_start() to address the management of
> the cache table in a specific function, as done in
> rproc_reset_rsc_table_on_stop().
> - rename rproc_set_rsc_table in rproc_set_rsc_table_on_attach()
> - move rproc_reset_rsc_table_on_stop() to be close to the
> rproc_set_rsc_table_on_start() function
This patch is really hard to read due to all 3 operations happening at the same
time. Please split in 3 smaller patches.
>
> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 116 ++++++++++++++-------------
> 1 file changed, 62 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..42bca01f3bde 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1264,18 +1264,9 @@ void rproc_resource_cleanup(struct rproc *rproc)
> }
> EXPORT_SYMBOL(rproc_resource_cleanup);
>
> -static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> {
> struct resource_table *loaded_table;
> - struct device *dev = &rproc->dev;
> - int ret;
> -
> - /* load the ELF segments to memory */
> - ret = rproc_load_segments(rproc, fw);
> - if (ret) {
> - dev_err(dev, "Failed to load program segments: %d\n", ret);
> - return ret;
> - }
>
> /*
> * The starting device has been given the rproc->cached_table as the
> @@ -1291,6 +1282,64 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> rproc->table_ptr = loaded_table;
> }
>
> + return 0;
> +}
> +
> +static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> +{
> + /* A resource table was never retrieved, nothing to do here */
> + if (!rproc->table_ptr)
> + return 0;
> +
> + /*
> + * If a cache table exists the remote processor was started by
> + * the remoteproc core. That cache table should be used for
> + * the rest of the shutdown process.
> + */
> + if (rproc->cached_table)
> + goto out;
> +
> + /*
> + * If we made it here the remote processor was started by another
> + * entity and a cache table doesn't exist. As such make a copy of
> + * the resource table currently used by the remote processor and
> + * use that for the rest of the shutdown process. The memory
> + * allocated here is free'd in rproc_shutdown().
> + */
> + rproc->cached_table = kmemdup(rproc->table_ptr,
> + rproc->table_sz, GFP_KERNEL);
> + if (!rproc->cached_table)
> + return -ENOMEM;
> +
> + /*
> + * Since the remote processor is being switched off the clean table
> + * won't be needed. Allocated in rproc_set_rsc_table_on_start().
> + */
> + kfree(rproc->clean_table);
> +
> +out:
> + /*
> + * Use a copy of the resource table for the remainder of the
> + * shutdown process.
> + */
> + rproc->table_ptr = rproc->cached_table;
> + return 0;
> +}
> +
> +static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct device *dev = &rproc->dev;
> + int ret;
> +
> + /* load the ELF segments to memory */
> + ret = rproc_load_segments(rproc, fw);
> + if (ret) {
> + dev_err(dev, "Failed to load program segments: %d\n", ret);
> + return ret;
> + }
> +
> + rproc_set_rsc_table_on_start(rproc, fw);
> +
> ret = rproc_prepare_subdevices(rproc);
> if (ret) {
> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> @@ -1450,7 +1499,7 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
> return ret;
> }
>
> -static int rproc_set_rsc_table(struct rproc *rproc)
> +static int rproc_set_rsc_table_on_attach(struct rproc *rproc)
> {
> struct resource_table *table_ptr;
> struct device *dev = &rproc->dev;
> @@ -1540,54 +1589,13 @@ static int rproc_reset_rsc_table_on_detach(struct rproc *rproc)
>
> /*
> * The clean resource table is no longer needed. Allocated in
> - * rproc_set_rsc_table().
> + * rproc_set_rsc_table_on_attach().
> */
> kfree(rproc->clean_table);
>
> return 0;
> }
>
> -static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> -{
> - /* A resource table was never retrieved, nothing to do here */
> - if (!rproc->table_ptr)
> - return 0;
> -
> - /*
> - * If a cache table exists the remote processor was started by
> - * the remoteproc core. That cache table should be used for
> - * the rest of the shutdown process.
> - */
> - if (rproc->cached_table)
> - goto out;
> -
> - /*
> - * If we made it here the remote processor was started by another
> - * entity and a cache table doesn't exist. As such make a copy of
> - * the resource table currently used by the remote processor and
> - * use that for the rest of the shutdown process. The memory
> - * allocated here is free'd in rproc_shutdown().
> - */
> - rproc->cached_table = kmemdup(rproc->table_ptr,
> - rproc->table_sz, GFP_KERNEL);
> - if (!rproc->cached_table)
> - return -ENOMEM;
> -
> - /*
> - * Since the remote processor is being switched off the clean table
> - * won't be needed. Allocated in rproc_set_rsc_table().
> - */
> - kfree(rproc->clean_table);
> -
> -out:
> - /*
> - * Use a copy of the resource table for the remainder of the
> - * shutdown process.
> - */
> - rproc->table_ptr = rproc->cached_table;
> - return 0;
> -}
> -
> /*
> * Attach to remote processor - similar to rproc_fw_boot() but without
> * the steps that deal with the firmware image.
> @@ -1614,7 +1622,7 @@ static int rproc_attach(struct rproc *rproc)
> goto disable_iommu;
> }
>
> - ret = rproc_set_rsc_table(rproc);
> + ret = rproc_set_rsc_table_on_attach(rproc);
> if (ret) {
> dev_err(dev, "can't load resource table: %d\n", ret);
> goto unprepare_device;
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
` (3 preceding siblings ...)
2024-05-21 8:09 ` [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function Arnaud Pouliquen
@ 2024-05-21 8:09 ` Arnaud Pouliquen
2024-05-28 21:30 ` Mathieu Poirier
2024-05-21 8:10 ` [PATCH v5 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
2024-05-21 8:10 ` [PATCH v5 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware Arnaud Pouliquen
6 siblings, 1 reply; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:09 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
1) on start:
- Using the TEE loader, the resource table is loaded by an external entity.
In such case the resource table address is not find from the firmware but
provided by the TEE remoteproc framework.
Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
- test that rproc->cached_table is not null before performing the memcpy
2)on stop
The use of the cached_table seems mandatory:
- during recovery sequence to have a snapshot of the resource table
resources used,
- on stop to allow for the deinitialization of resources after the
the remote processor has been shutdown.
However if the TEE interface is being used, we first need to unmap the
table_ptr before setting it to rproc->cached_table.
The update of rproc->table_ptr to rproc->cached_table is performed in
tee_remoteproc.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 42bca01f3bde..3a642151c983 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
{
struct resource_table *loaded_table;
+ struct device *dev = &rproc->dev;
/*
* The starting device has been given the rproc->cached_table as the
@@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
* this information to device memory. We also update the table_ptr so
* that any subsequent changes will be applied to the loaded version.
*/
- loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
- if (loaded_table) {
- memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
- rproc->table_ptr = loaded_table;
+ if (rproc->tee_interface) {
+ loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
+ if (IS_ERR(loaded_table)) {
+ dev_err(dev, "can't get resource table\n");
+ return PTR_ERR(loaded_table);
+ }
+ } else {
+ loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
}
+ if (loaded_table && rproc->cached_table)
+ memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
+
+ rproc->table_ptr = loaded_table;
+
return 0;
}
@@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
kfree(rproc->clean_table);
out:
- /*
- * Use a copy of the resource table for the remainder of the
- * shutdown process.
+ /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
+ * before updating the proc->table_ptr reference.
*/
- rproc->table_ptr = rproc->cached_table;
+ if (!rproc->tee_interface) {
+ /*
+ * Use a copy of the resource table for the remainder of the
+ * shutdown process.
+ */
+ rproc->table_ptr = rproc->cached_table;
+ }
return 0;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-21 8:09 ` [PATCH v5 5/7] remoteproc: core: support of the tee interface Arnaud Pouliquen
@ 2024-05-28 21:30 ` Mathieu Poirier
2024-05-29 7:13 ` Arnaud POULIQUEN
0 siblings, 1 reply; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-28 21:30 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> 1) on start:
> - Using the TEE loader, the resource table is loaded by an external entity.
> In such case the resource table address is not find from the firmware but
> provided by the TEE remoteproc framework.
> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> - test that rproc->cached_table is not null before performing the memcpy
>
> 2)on stop
> The use of the cached_table seems mandatory:
> - during recovery sequence to have a snapshot of the resource table
> resources used,
> - on stop to allow for the deinitialization of resources after the
> the remote processor has been shutdown.
> However if the TEE interface is being used, we first need to unmap the
> table_ptr before setting it to rproc->cached_table.
> The update of rproc->table_ptr to rproc->cached_table is performed in
> tee_remoteproc.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 42bca01f3bde..3a642151c983 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> {
> struct resource_table *loaded_table;
> + struct device *dev = &rproc->dev;
>
> /*
> * The starting device has been given the rproc->cached_table as the
> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
> * this information to device memory. We also update the table_ptr so
> * that any subsequent changes will be applied to the loaded version.
> */
> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> - if (loaded_table) {
> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> - rproc->table_ptr = loaded_table;
> + if (rproc->tee_interface) {
> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
> + if (IS_ERR(loaded_table)) {
> + dev_err(dev, "can't get resource table\n");
> + return PTR_ERR(loaded_table);
> + }
> + } else {
> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> }
>
> + if (loaded_table && rproc->cached_table)
> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> +
Why is this not part of the else {} above as it was the case before this patch?
And why was an extra check for ->cached_table added?
This should be a simple change, i.e introduce an if {} else {} block to take
care of the two scenarios. Plus the comment is misplaced now.
More comments tomorrow.
Thanks,
Mathieu
> + rproc->table_ptr = loaded_table;
> +
> return 0;
> }
>
> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> kfree(rproc->clean_table);
>
> out:
> - /*
> - * Use a copy of the resource table for the remainder of the
> - * shutdown process.
> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
> + * before updating the proc->table_ptr reference.
> */
> - rproc->table_ptr = rproc->cached_table;
> + if (!rproc->tee_interface) {
> + /*
> + * Use a copy of the resource table for the remainder of the
> + * shutdown process.
> + */
> + rproc->table_ptr = rproc->cached_table;
> + }
> return 0;
> }
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-28 21:30 ` Mathieu Poirier
@ 2024-05-29 7:13 ` Arnaud POULIQUEN
2024-05-29 20:35 ` Mathieu Poirier
0 siblings, 1 reply; 20+ messages in thread
From: Arnaud POULIQUEN @ 2024-05-29 7:13 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
Hello Mathieu,
On 5/28/24 23:30, Mathieu Poirier wrote:
> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
>> 1) on start:
>> - Using the TEE loader, the resource table is loaded by an external entity.
>> In such case the resource table address is not find from the firmware but
>> provided by the TEE remoteproc framework.
>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
>> - test that rproc->cached_table is not null before performing the memcpy
>>
>> 2)on stop
>> The use of the cached_table seems mandatory:
>> - during recovery sequence to have a snapshot of the resource table
>> resources used,
>> - on stop to allow for the deinitialization of resources after the
>> the remote processor has been shutdown.
>> However if the TEE interface is being used, we first need to unmap the
>> table_ptr before setting it to rproc->cached_table.
>> The update of rproc->table_ptr to rproc->cached_table is performed in
>> tee_remoteproc.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>> ---
>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
>> 1 file changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
>> index 42bca01f3bde..3a642151c983 100644
>> --- a/drivers/remoteproc/remoteproc_core.c
>> +++ b/drivers/remoteproc/remoteproc_core.c
>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
>> {
>> struct resource_table *loaded_table;
>> + struct device *dev = &rproc->dev;
>>
>> /*
>> * The starting device has been given the rproc->cached_table as the
>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
>> * this information to device memory. We also update the table_ptr so
>> * that any subsequent changes will be applied to the loaded version.
>> */
>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>> - if (loaded_table) {
>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>> - rproc->table_ptr = loaded_table;
>> + if (rproc->tee_interface) {
>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
>> + if (IS_ERR(loaded_table)) {
>> + dev_err(dev, "can't get resource table\n");
>> + return PTR_ERR(loaded_table);
>> + }
>> + } else {
>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>> }
>>
>> + if (loaded_table && rproc->cached_table)
>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>> +
>
> Why is this not part of the else {} above as it was the case before this patch?
> And why was an extra check for ->cached_table added?
Here we have to cover 2 use cases if rproc->tee_interface is set.
1) The remote processor is in stop state
- loaded_table points to the resource table in the remote memory and
- rproc->cached_table is null
=> no memcopy
2) crash recovery
- loaded_table points to the resource table in the remote memory
- rproc-cached_table point to a copy of the resource table
=> need to perform the memcpy to reapply settings in the resource table
I can duplicate the memcpy in if{} and else{} but this will be similar code
as needed in both case.
Adding rproc->cached_table test if proc->tee_interface=NULL seems also
reasonable as a memcpy from 0 should not be performed.
>
> This should be a simple change, i.e introduce an if {} else {} block to take
> care of the two scenarios. Plus the comment is misplaced now.
What about split it in 2 patches?
- one adding the test on rproc->cached_table for the memcpy
- one adding the if {} else {}?
Thanks,
Arnaud
>
> More comments tomorrow.
>
> Thanks,
> Mathieu
>
>> + rproc->table_ptr = loaded_table;
>> +
>> return 0;
>> }
>>
>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
>> kfree(rproc->clean_table);
>>
>> out:
>> - /*
>> - * Use a copy of the resource table for the remainder of the
>> - * shutdown process.
>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
>> + * before updating the proc->table_ptr reference.
>> */
>> - rproc->table_ptr = rproc->cached_table;
>> + if (!rproc->tee_interface) {
>> + /*
>> + * Use a copy of the resource table for the remainder of the
>> + * shutdown process.
>> + */
>> + rproc->table_ptr = rproc->cached_table;
>> + }
>> return 0;
>> }
>>
>> --
>> 2.25.1
>>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-29 7:13 ` Arnaud POULIQUEN
@ 2024-05-29 20:35 ` Mathieu Poirier
2024-05-30 7:42 ` Arnaud POULIQUEN
0 siblings, 1 reply; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-29 20:35 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 5/28/24 23:30, Mathieu Poirier wrote:
> > On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> >> 1) on start:
> >> - Using the TEE loader, the resource table is loaded by an external entity.
> >> In such case the resource table address is not find from the firmware but
> >> provided by the TEE remoteproc framework.
> >> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> >> - test that rproc->cached_table is not null before performing the memcpy
> >>
> >> 2)on stop
> >> The use of the cached_table seems mandatory:
> >> - during recovery sequence to have a snapshot of the resource table
> >> resources used,
> >> - on stop to allow for the deinitialization of resources after the
> >> the remote processor has been shutdown.
> >> However if the TEE interface is being used, we first need to unmap the
> >> table_ptr before setting it to rproc->cached_table.
> >> The update of rproc->table_ptr to rproc->cached_table is performed in
> >> tee_remoteproc.
> >>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >> ---
> >> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
> >> 1 file changed, 23 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >> index 42bca01f3bde..3a642151c983 100644
> >> --- a/drivers/remoteproc/remoteproc_core.c
> >> +++ b/drivers/remoteproc/remoteproc_core.c
> >> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> >> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> >> {
> >> struct resource_table *loaded_table;
> >> + struct device *dev = &rproc->dev;
> >>
> >> /*
> >> * The starting device has been given the rproc->cached_table as the
> >> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
> >> * this information to device memory. We also update the table_ptr so
> >> * that any subsequent changes will be applied to the loaded version.
> >> */
> >> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >> - if (loaded_table) {
> >> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >> - rproc->table_ptr = loaded_table;
> >> + if (rproc->tee_interface) {
> >> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
> >> + if (IS_ERR(loaded_table)) {
> >> + dev_err(dev, "can't get resource table\n");
> >> + return PTR_ERR(loaded_table);
> >> + }
> >> + } else {
> >> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >> }
> >>
> >> + if (loaded_table && rproc->cached_table)
> >> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >> +
> >
> > Why is this not part of the else {} above as it was the case before this patch?
> > And why was an extra check for ->cached_table added?
>
> Here we have to cover 2 use cases if rproc->tee_interface is set.
> 1) The remote processor is in stop state
> - loaded_table points to the resource table in the remote memory and
> - rproc->cached_table is null
> => no memcopy
> 2) crash recovery
> - loaded_table points to the resource table in the remote memory
> - rproc-cached_table point to a copy of the resource table
A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
But as the comment says [1], that part of the code was meant to be used for the
attach()/detach() use case. Mixing both will become extremely confusing and
impossible to maintain.
I think the TEE scenario should be as similar as the "normal" one where TEE is
not involved. To that end, I suggest to create a cached_table in
tee_rproc_parse_fw(), exactly the same way it is done in
rproc_elf_load_rsc_table(). That way the code path in
rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
work with when the remote processor is recovered. In fact we may not need
rproc_set_rsc_table_on_start() at all but that needs to be asserted.
[1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
> => need to perform the memcpy to reapply settings in the resource table
>
> I can duplicate the memcpy in if{} and else{} but this will be similar code
> as needed in both case.
> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
> reasonable as a memcpy from 0 should not be performed.
>
>
> >
> > This should be a simple change, i.e introduce an if {} else {} block to take
> > care of the two scenarios. Plus the comment is misplaced now.
>
> What about split it in 2 patches?
> - one adding the test on rproc->cached_table for the memcpy
> - one adding the if {} else {}?
>
> Thanks,
> Arnaud
>
>
> >
> > More comments tomorrow.
> >
> > Thanks,
> > Mathieu
> >
> >> + rproc->table_ptr = loaded_table;
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> >> kfree(rproc->clean_table);
> >>
> >> out:
> >> - /*
> >> - * Use a copy of the resource table for the remainder of the
> >> - * shutdown process.
> >> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
> >> + * before updating the proc->table_ptr reference.
> >> */
> >> - rproc->table_ptr = rproc->cached_table;
> >> + if (!rproc->tee_interface) {
> >> + /*
> >> + * Use a copy of the resource table for the remainder of the
> >> + * shutdown process.
> >> + */
> >> + rproc->table_ptr = rproc->cached_table;
> >> + }
> >> return 0;
> >> }
> >>
> >> --
> >> 2.25.1
> >>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-29 20:35 ` Mathieu Poirier
@ 2024-05-30 7:42 ` Arnaud POULIQUEN
2024-05-30 16:14 ` Mathieu Poirier
2024-05-31 17:28 ` Mathieu Poirier
0 siblings, 2 replies; 20+ messages in thread
From: Arnaud POULIQUEN @ 2024-05-30 7:42 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
Hello Mathieu,
On 5/29/24 22:35, Mathieu Poirier wrote:
> On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
>> Hello Mathieu,
>>
>> On 5/28/24 23:30, Mathieu Poirier wrote:
>>> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
>>>> 1) on start:
>>>> - Using the TEE loader, the resource table is loaded by an external entity.
>>>> In such case the resource table address is not find from the firmware but
>>>> provided by the TEE remoteproc framework.
>>>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
>>>> - test that rproc->cached_table is not null before performing the memcpy
>>>>
>>>> 2)on stop
>>>> The use of the cached_table seems mandatory:
>>>> - during recovery sequence to have a snapshot of the resource table
>>>> resources used,
>>>> - on stop to allow for the deinitialization of resources after the
>>>> the remote processor has been shutdown.
>>>> However if the TEE interface is being used, we first need to unmap the
>>>> table_ptr before setting it to rproc->cached_table.
>>>> The update of rproc->table_ptr to rproc->cached_table is performed in
>>>> tee_remoteproc.
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> ---
>>>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
>>>> 1 file changed, 23 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
>>>> index 42bca01f3bde..3a642151c983 100644
>>>> --- a/drivers/remoteproc/remoteproc_core.c
>>>> +++ b/drivers/remoteproc/remoteproc_core.c
>>>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
>>>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
>>>> {
>>>> struct resource_table *loaded_table;
>>>> + struct device *dev = &rproc->dev;
>>>>
>>>> /*
>>>> * The starting device has been given the rproc->cached_table as the
>>>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
>>>> * this information to device memory. We also update the table_ptr so
>>>> * that any subsequent changes will be applied to the loaded version.
>>>> */
>>>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>>>> - if (loaded_table) {
>>>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>>>> - rproc->table_ptr = loaded_table;
>>>> + if (rproc->tee_interface) {
>>>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
>>>> + if (IS_ERR(loaded_table)) {
>>>> + dev_err(dev, "can't get resource table\n");
>>>> + return PTR_ERR(loaded_table);
>>>> + }
>>>> + } else {
>>>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>>>> }
>>>>
>>>> + if (loaded_table && rproc->cached_table)
>>>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>>>> +
>>>
>>> Why is this not part of the else {} above as it was the case before this patch?
>>> And why was an extra check for ->cached_table added?
>>
>> Here we have to cover 2 use cases if rproc->tee_interface is set.
>> 1) The remote processor is in stop state
>> - loaded_table points to the resource table in the remote memory and
>> - rproc->cached_table is null
>> => no memcopy
>> 2) crash recovery
>> - loaded_table points to the resource table in the remote memory
>> - rproc-cached_table point to a copy of the resource table
>
> A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
> But as the comment says [1], that part of the code was meant to be used for the
> attach()/detach() use case. Mixing both will become extremely confusing and
> impossible to maintain.
i am not sure to understand your point here... the cached_table table was
already existing for the "normal" case[2]. Seems to me that the cache table is
needed on stop in all scenarios.
[2]
https://elixir.bootlin.com/linux/v4.20.17/source/drivers/remoteproc/remoteproc_core.c#L1402
>
> I think the TEE scenario should be as similar as the "normal" one where TEE is
> not involved. To that end, I suggest to create a cached_table in
> tee_rproc_parse_fw(), exactly the same way it is done in
> rproc_elf_load_rsc_table(). That way the code path in
> rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
> work with when the remote processor is recovered. In fact we may not need
> rproc_set_rsc_table_on_start() at all but that needs to be asserted.
This is was I proposed in my V4 [3]. Could you please confirm that this aligns
with what you have in mind?
In such a case, should I keep the updates below in
rproc_reset_rsc_table_on_stop(), or should I revert to using rproc->rsc_table to
store the pointer to the resource table in tee_remoteproc for the associated
memory map/unmap?"
[3]
https://patchwork.kernel.org/project/linux-remoteproc/patch/20240308144708.62362-2-arnaud.pouliquen@foss.st.com/
Thanks,
Arnaud
>
> [1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
>
>> => need to perform the memcpy to reapply settings in the resource table
>>
>> I can duplicate the memcpy in if{} and else{} but this will be similar code
>> as needed in both case.
>> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
>> reasonable as a memcpy from 0 should not be performed.
>>
>>
>>>
>>> This should be a simple change, i.e introduce an if {} else {} block to take
>>> care of the two scenarios. Plus the comment is misplaced now.
>>
>> What about split it in 2 patches?
>> - one adding the test on rproc->cached_table for the memcpy
>> - one adding the if {} else {}?
>>
>> Thanks,
>> Arnaud
>>
>>
>>>
>>> More comments tomorrow.
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>> + rproc->table_ptr = loaded_table;
>>>> +
>>>> return 0;
>>>> }
>>>>
>>>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
>>>> kfree(rproc->clean_table);
>>>>
>>>> out:
>>>> - /*
>>>> - * Use a copy of the resource table for the remainder of the
>>>> - * shutdown process.
>>>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
>>>> + * before updating the proc->table_ptr reference.
>>>> */
>>>> - rproc->table_ptr = rproc->cached_table;
>>>> + if (!rproc->tee_interface) {
>>>> + /*
>>>> + * Use a copy of the resource table for the remainder of the
>>>> + * shutdown process.
>>>> + */
>>>> + rproc->table_ptr = rproc->cached_table;
>>>> + }
>>>> return 0;
>>>> }
>>>>
>>>> --
>>>> 2.25.1
>>>>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-30 7:42 ` Arnaud POULIQUEN
@ 2024-05-30 16:14 ` Mathieu Poirier
2024-05-31 17:28 ` Mathieu Poirier
1 sibling, 0 replies; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-30 16:14 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Thu, May 30, 2024 at 09:42:26AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 5/29/24 22:35, Mathieu Poirier wrote:
> > On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 5/28/24 23:30, Mathieu Poirier wrote:
> >>> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> >>>> 1) on start:
> >>>> - Using the TEE loader, the resource table is loaded by an external entity.
> >>>> In such case the resource table address is not find from the firmware but
> >>>> provided by the TEE remoteproc framework.
> >>>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> >>>> - test that rproc->cached_table is not null before performing the memcpy
> >>>>
> >>>> 2)on stop
> >>>> The use of the cached_table seems mandatory:
> >>>> - during recovery sequence to have a snapshot of the resource table
> >>>> resources used,
> >>>> - on stop to allow for the deinitialization of resources after the
> >>>> the remote processor has been shutdown.
> >>>> However if the TEE interface is being used, we first need to unmap the
> >>>> table_ptr before setting it to rproc->cached_table.
> >>>> The update of rproc->table_ptr to rproc->cached_table is performed in
> >>>> tee_remoteproc.
> >>>>
> >>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>> ---
> >>>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
> >>>> 1 file changed, 23 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >>>> index 42bca01f3bde..3a642151c983 100644
> >>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> >>>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> >>>> {
> >>>> struct resource_table *loaded_table;
> >>>> + struct device *dev = &rproc->dev;
> >>>>
> >>>> /*
> >>>> * The starting device has been given the rproc->cached_table as the
> >>>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
> >>>> * this information to device memory. We also update the table_ptr so
> >>>> * that any subsequent changes will be applied to the loaded version.
> >>>> */
> >>>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>> - if (loaded_table) {
> >>>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>> - rproc->table_ptr = loaded_table;
> >>>> + if (rproc->tee_interface) {
> >>>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
> >>>> + if (IS_ERR(loaded_table)) {
> >>>> + dev_err(dev, "can't get resource table\n");
> >>>> + return PTR_ERR(loaded_table);
> >>>> + }
> >>>> + } else {
> >>>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>> }
> >>>>
> >>>> + if (loaded_table && rproc->cached_table)
> >>>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>> +
> >>>
> >>> Why is this not part of the else {} above as it was the case before this patch?
> >>> And why was an extra check for ->cached_table added?
> >>
> >> Here we have to cover 2 use cases if rproc->tee_interface is set.
> >> 1) The remote processor is in stop state
> >> - loaded_table points to the resource table in the remote memory and
> >> - rproc->cached_table is null
> >> => no memcopy
> >> 2) crash recovery
> >> - loaded_table points to the resource table in the remote memory
> >> - rproc-cached_table point to a copy of the resource table
> >
> > A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
> > But as the comment says [1], that part of the code was meant to be used for the
> > attach()/detach() use case. Mixing both will become extremely confusing and
> > impossible to maintain.
>
> i am not sure to understand your point here... the cached_table table was
> already existing for the "normal" case[2]. Seems to me that the cache table is
> needed on stop in all scenarios.
>
> [2]
> https://elixir.bootlin.com/linux/v4.20.17/source/drivers/remoteproc/remoteproc_core.c#L1402
>
> >
> > I think the TEE scenario should be as similar as the "normal" one where TEE is
> > not involved. To that end, I suggest to create a cached_table in
> > tee_rproc_parse_fw(), exactly the same way it is done in
> > rproc_elf_load_rsc_table(). That way the code path in
> > rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
> > work with when the remote processor is recovered. In fact we may not need
> > rproc_set_rsc_table_on_start() at all but that needs to be asserted.
>
> This is was I proposed in my V4 [3]. Could you please confirm that this aligns
> with what you have in mind?
Let me think a little - I'll get back to you.
> In such a case, should I keep the updates below in
> rproc_reset_rsc_table_on_stop(), or should I revert to using rproc->rsc_table to
> store the pointer to the resource table in tee_remoteproc for the associated
> memory map/unmap?"
>
> [3]
> https://patchwork.kernel.org/project/linux-remoteproc/patch/20240308144708.62362-2-arnaud.pouliquen@foss.st.com/
>
> Thanks,
> Arnaud
>
> >
> > [1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
> >
> >> => need to perform the memcpy to reapply settings in the resource table
> >>
> >> I can duplicate the memcpy in if{} and else{} but this will be similar code
> >> as needed in both case.
> >> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
> >> reasonable as a memcpy from 0 should not be performed.
> >>
> >>
> >>>
> >>> This should be a simple change, i.e introduce an if {} else {} block to take
> >>> care of the two scenarios. Plus the comment is misplaced now.
> >>
> >> What about split it in 2 patches?
> >> - one adding the test on rproc->cached_table for the memcpy
> >> - one adding the if {} else {}?
> >>
> >> Thanks,
> >> Arnaud
> >>
> >>
> >>>
> >>> More comments tomorrow.
> >>>
> >>> Thanks,
> >>> Mathieu
> >>>
> >>>> + rproc->table_ptr = loaded_table;
> >>>> +
> >>>> return 0;
> >>>> }
> >>>>
> >>>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> >>>> kfree(rproc->clean_table);
> >>>>
> >>>> out:
> >>>> - /*
> >>>> - * Use a copy of the resource table for the remainder of the
> >>>> - * shutdown process.
> >>>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
> >>>> + * before updating the proc->table_ptr reference.
> >>>> */
> >>>> - rproc->table_ptr = rproc->cached_table;
> >>>> + if (!rproc->tee_interface) {
> >>>> + /*
> >>>> + * Use a copy of the resource table for the remainder of the
> >>>> + * shutdown process.
> >>>> + */
> >>>> + rproc->table_ptr = rproc->cached_table;
> >>>> + }
> >>>> return 0;
> >>>> }
> >>>>
> >>>> --
> >>>> 2.25.1
> >>>>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-30 7:42 ` Arnaud POULIQUEN
2024-05-30 16:14 ` Mathieu Poirier
@ 2024-05-31 17:28 ` Mathieu Poirier
2024-06-03 8:21 ` Arnaud POULIQUEN
1 sibling, 1 reply; 20+ messages in thread
From: Mathieu Poirier @ 2024-05-31 17:28 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Thu, May 30, 2024 at 09:42:26AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 5/29/24 22:35, Mathieu Poirier wrote:
> > On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 5/28/24 23:30, Mathieu Poirier wrote:
> >>> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> >>>> 1) on start:
> >>>> - Using the TEE loader, the resource table is loaded by an external entity.
> >>>> In such case the resource table address is not find from the firmware but
> >>>> provided by the TEE remoteproc framework.
> >>>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> >>>> - test that rproc->cached_table is not null before performing the memcpy
> >>>>
> >>>> 2)on stop
> >>>> The use of the cached_table seems mandatory:
> >>>> - during recovery sequence to have a snapshot of the resource table
> >>>> resources used,
> >>>> - on stop to allow for the deinitialization of resources after the
> >>>> the remote processor has been shutdown.
> >>>> However if the TEE interface is being used, we first need to unmap the
> >>>> table_ptr before setting it to rproc->cached_table.
> >>>> The update of rproc->table_ptr to rproc->cached_table is performed in
> >>>> tee_remoteproc.
> >>>>
> >>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>> ---
> >>>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
> >>>> 1 file changed, 23 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >>>> index 42bca01f3bde..3a642151c983 100644
> >>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> >>>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> >>>> {
> >>>> struct resource_table *loaded_table;
> >>>> + struct device *dev = &rproc->dev;
> >>>>
> >>>> /*
> >>>> * The starting device has been given the rproc->cached_table as the
> >>>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
> >>>> * this information to device memory. We also update the table_ptr so
> >>>> * that any subsequent changes will be applied to the loaded version.
> >>>> */
> >>>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>> - if (loaded_table) {
> >>>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>> - rproc->table_ptr = loaded_table;
> >>>> + if (rproc->tee_interface) {
> >>>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
> >>>> + if (IS_ERR(loaded_table)) {
> >>>> + dev_err(dev, "can't get resource table\n");
> >>>> + return PTR_ERR(loaded_table);
> >>>> + }
> >>>> + } else {
> >>>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>> }
> >>>>
> >>>> + if (loaded_table && rproc->cached_table)
> >>>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>> +
> >>>
> >>> Why is this not part of the else {} above as it was the case before this patch?
> >>> And why was an extra check for ->cached_table added?
> >>
> >> Here we have to cover 2 use cases if rproc->tee_interface is set.
> >> 1) The remote processor is in stop state
> >> - loaded_table points to the resource table in the remote memory and
> >> - rproc->cached_table is null
> >> => no memcopy
> >> 2) crash recovery
> >> - loaded_table points to the resource table in the remote memory
> >> - rproc-cached_table point to a copy of the resource table
> >
> > A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
> > But as the comment says [1], that part of the code was meant to be used for the
> > attach()/detach() use case. Mixing both will become extremely confusing and
> > impossible to maintain.
>
> i am not sure to understand your point here... the cached_table table was
> already existing for the "normal" case[2]. Seems to me that the cache table is
> needed on stop in all scenarios.
>
> [2]
> https://elixir.bootlin.com/linux/v4.20.17/source/drivers/remoteproc/remoteproc_core.c#L1402
>
> >
> > I think the TEE scenario should be as similar as the "normal" one where TEE is
> > not involved. To that end, I suggest to create a cached_table in
> > tee_rproc_parse_fw(), exactly the same way it is done in
> > rproc_elf_load_rsc_table(). That way the code path in
> > rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
> > work with when the remote processor is recovered. In fact we may not need
> > rproc_set_rsc_table_on_start() at all but that needs to be asserted.
>
> This is was I proposed in my V4 [3]. Could you please confirm that this aligns
> with what you have in mind?
After spending more time on this I have the following 3 observations:
1) We need a ->cached_table, otherwise the crash recovery path gets really
messy.
2) It _might_ be a good idea to rename tee_rproc_get_loaded_rsc_table() to
tee_rproc_find_loaded_rsc_table() to be aligned with the scenario where the
firmware is loaded by the remoteproc core. I think you had
tee_rproc_find_loaded_rsc_table() in the first place and I asked you to change
it. If so, apologies - reviewing patches isn't an exact science.
3) The same way ->cached_table is created in rproc_elf_load_rsc_table(), which
is essentially ops::parse_fw(), we should create one in tee_rproc_parse_fw()
with a kmemdup(). Exactly the same as in rproc_elf_load_rsc_table(). In
tee_rproc_parse_fw(), @rsc_table should be iounmap'ed right away so that we
don't need to keep a local variable to free it later. In rproc_start() the call
to rproc_find_loaded_rsc_table() will get another mapped handle to the resource
table in memory. It might be a little unefficient but it sure beats doing a lot
of modifications in the core.
As I said above this isn't an exact science and we may need to changes more
things but at least it should take us a little further.
Thanks,
Mathieu
> In such a case, should I keep the updates below in
> rproc_reset_rsc_table_on_stop(), or should I revert to using rproc->rsc_table to
> store the pointer to the resource table in tee_remoteproc for the associated
> memory map/unmap?"
>
> [3]
> https://patchwork.kernel.org/project/linux-remoteproc/patch/20240308144708.62362-2-arnaud.pouliquen@foss.st.com/
>
> Thanks,
> Arnaud
>
> >
> > [1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
> >
> >> => need to perform the memcpy to reapply settings in the resource table
> >>
> >> I can duplicate the memcpy in if{} and else{} but this will be similar code
> >> as needed in both case.
> >> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
> >> reasonable as a memcpy from 0 should not be performed.
> >>
> >>
> >>>
> >>> This should be a simple change, i.e introduce an if {} else {} block to take
> >>> care of the two scenarios. Plus the comment is misplaced now.
> >>
> >> What about split it in 2 patches?
> >> - one adding the test on rproc->cached_table for the memcpy
> >> - one adding the if {} else {}?
> >>
> >> Thanks,
> >> Arnaud
> >>
> >>
> >>>
> >>> More comments tomorrow.
> >>>
> >>> Thanks,
> >>> Mathieu
> >>>
> >>>> + rproc->table_ptr = loaded_table;
> >>>> +
> >>>> return 0;
> >>>> }
> >>>>
> >>>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> >>>> kfree(rproc->clean_table);
> >>>>
> >>>> out:
> >>>> - /*
> >>>> - * Use a copy of the resource table for the remainder of the
> >>>> - * shutdown process.
> >>>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
> >>>> + * before updating the proc->table_ptr reference.
> >>>> */
> >>>> - rproc->table_ptr = rproc->cached_table;
> >>>> + if (!rproc->tee_interface) {
> >>>> + /*
> >>>> + * Use a copy of the resource table for the remainder of the
> >>>> + * shutdown process.
> >>>> + */
> >>>> + rproc->table_ptr = rproc->cached_table;
> >>>> + }
> >>>> return 0;
> >>>> }
> >>>>
> >>>> --
> >>>> 2.25.1
> >>>>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-05-31 17:28 ` Mathieu Poirier
@ 2024-06-03 8:21 ` Arnaud POULIQUEN
2024-06-03 14:24 ` Mathieu Poirier
0 siblings, 1 reply; 20+ messages in thread
From: Arnaud POULIQUEN @ 2024-06-03 8:21 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
Hello Mathieu,
On 5/31/24 19:28, Mathieu Poirier wrote:
> On Thu, May 30, 2024 at 09:42:26AM +0200, Arnaud POULIQUEN wrote:
>> Hello Mathieu,
>>
>> On 5/29/24 22:35, Mathieu Poirier wrote:
>>> On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
>>>> Hello Mathieu,
>>>>
>>>> On 5/28/24 23:30, Mathieu Poirier wrote:
>>>>> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
>>>>>> 1) on start:
>>>>>> - Using the TEE loader, the resource table is loaded by an external entity.
>>>>>> In such case the resource table address is not find from the firmware but
>>>>>> provided by the TEE remoteproc framework.
>>>>>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
>>>>>> - test that rproc->cached_table is not null before performing the memcpy
>>>>>>
>>>>>> 2)on stop
>>>>>> The use of the cached_table seems mandatory:
>>>>>> - during recovery sequence to have a snapshot of the resource table
>>>>>> resources used,
>>>>>> - on stop to allow for the deinitialization of resources after the
>>>>>> the remote processor has been shutdown.
>>>>>> However if the TEE interface is being used, we first need to unmap the
>>>>>> table_ptr before setting it to rproc->cached_table.
>>>>>> The update of rproc->table_ptr to rproc->cached_table is performed in
>>>>>> tee_remoteproc.
>>>>>>
>>>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>>>> ---
>>>>>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
>>>>>> 1 file changed, 23 insertions(+), 8 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
>>>>>> index 42bca01f3bde..3a642151c983 100644
>>>>>> --- a/drivers/remoteproc/remoteproc_core.c
>>>>>> +++ b/drivers/remoteproc/remoteproc_core.c
>>>>>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
>>>>>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
>>>>>> {
>>>>>> struct resource_table *loaded_table;
>>>>>> + struct device *dev = &rproc->dev;
>>>>>>
>>>>>> /*
>>>>>> * The starting device has been given the rproc->cached_table as the
>>>>>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
>>>>>> * this information to device memory. We also update the table_ptr so
>>>>>> * that any subsequent changes will be applied to the loaded version.
>>>>>> */
>>>>>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>>>>>> - if (loaded_table) {
>>>>>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>>>>>> - rproc->table_ptr = loaded_table;
>>>>>> + if (rproc->tee_interface) {
>>>>>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
>>>>>> + if (IS_ERR(loaded_table)) {
>>>>>> + dev_err(dev, "can't get resource table\n");
>>>>>> + return PTR_ERR(loaded_table);
>>>>>> + }
>>>>>> + } else {
>>>>>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
>>>>>> }
>>>>>>
>>>>>> + if (loaded_table && rproc->cached_table)
>>>>>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
>>>>>> +
>>>>>
>>>>> Why is this not part of the else {} above as it was the case before this patch?
>>>>> And why was an extra check for ->cached_table added?
>>>>
>>>> Here we have to cover 2 use cases if rproc->tee_interface is set.
>>>> 1) The remote processor is in stop state
>>>> - loaded_table points to the resource table in the remote memory and
>>>> - rproc->cached_table is null
>>>> => no memcopy
>>>> 2) crash recovery
>>>> - loaded_table points to the resource table in the remote memory
>>>> - rproc-cached_table point to a copy of the resource table
>>>
>>> A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
>>> But as the comment says [1], that part of the code was meant to be used for the
>>> attach()/detach() use case. Mixing both will become extremely confusing and
>>> impossible to maintain.
>>
>> i am not sure to understand your point here... the cached_table table was
>> already existing for the "normal" case[2]. Seems to me that the cache table is
>> needed on stop in all scenarios.
>>
>> [2]
>> https://elixir.bootlin.com/linux/v4.20.17/source/drivers/remoteproc/remoteproc_core.c#L1402
>>
>>>
>>> I think the TEE scenario should be as similar as the "normal" one where TEE is
>>> not involved. To that end, I suggest to create a cached_table in
>>> tee_rproc_parse_fw(), exactly the same way it is done in
>>> rproc_elf_load_rsc_table(). That way the code path in
>>> rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
>>> work with when the remote processor is recovered. In fact we may not need
>>> rproc_set_rsc_table_on_start() at all but that needs to be asserted.
>>
>> This is was I proposed in my V4 [3]. Could you please confirm that this aligns
>> with what you have in mind?
>
> After spending more time on this I have the following 3 observations:
>
> 1) We need a ->cached_table, otherwise the crash recovery path gets really
> messy.
>
> 2) It _might_ be a good idea to rename tee_rproc_get_loaded_rsc_table() to
> tee_rproc_find_loaded_rsc_table() to be aligned with the scenario where the
> firmware is loaded by the remoteproc core. I think you had
> tee_rproc_find_loaded_rsc_table() in the first place and I asked you to change
> it. If so, apologies - reviewing patches isn't an exact science.
>
> 3) The same way ->cached_table is created in rproc_elf_load_rsc_table(), which
> is essentially ops::parse_fw(), we should create one in tee_rproc_parse_fw()
> with a kmemdup(). Exactly the same as in rproc_elf_load_rsc_table(). In
> tee_rproc_parse_fw(), @rsc_table should be iounmap'ed right away so that we
> don't need to keep a local variable to free it later. In rproc_start() the call
> to rproc_find_loaded_rsc_table() will get another mapped handle to the resource
> table in memory. It might be a little unefficient but it sure beats doing a lot
> of modifications in the core.
Remapping the resource table in rproc_find_loaded_rsc_table will require that we
unmap it on rproc_stop before updating rproc->table_ptr to rproc->cached_table.
On the other hand, I wonder if declaring the memory region in the stm32-rproc DT
node would address this second mapping and avoid a map in
rproc_find_loaded_rsc_table().
I will do the V6 integrating your suggestions and having a deeper look on the
resource table map/unmap.
>
> As I said above this isn't an exact science and we may need to changes more
> things but at least it should take us a little further.
That seems to me reasonable and part of the normal upstream process :)
Thanks,
Arnaud
>
> Thanks,
> Mathieu
>
>> In such a case, should I keep the updates below in
>> rproc_reset_rsc_table_on_stop(), or should I revert to using rproc->rsc_table to
>> store the pointer to the resource table in tee_remoteproc for the associated
>> memory map/unmap?"
>>
>> [3]
>> https://patchwork.kernel.org/project/linux-remoteproc/patch/20240308144708.62362-2-arnaud.pouliquen@foss.st.com/
>>
>> Thanks,
>> Arnaud
>>
>>>
>>> [1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
>>>
>>>> => need to perform the memcpy to reapply settings in the resource table
>>>>
>>>> I can duplicate the memcpy in if{} and else{} but this will be similar code
>>>> as needed in both case.
>>>> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
>>>> reasonable as a memcpy from 0 should not be performed.
>>>>
>>>>
>>>>>
>>>>> This should be a simple change, i.e introduce an if {} else {} block to take
>>>>> care of the two scenarios. Plus the comment is misplaced now.
>>>>
>>>> What about split it in 2 patches?
>>>> - one adding the test on rproc->cached_table for the memcpy
>>>> - one adding the if {} else {}?
>>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>>
>>>>>
>>>>> More comments tomorrow.
>>>>>
>>>>> Thanks,
>>>>> Mathieu
>>>>>
>>>>>> + rproc->table_ptr = loaded_table;
>>>>>> +
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
>>>>>> kfree(rproc->clean_table);
>>>>>>
>>>>>> out:
>>>>>> - /*
>>>>>> - * Use a copy of the resource table for the remainder of the
>>>>>> - * shutdown process.
>>>>>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
>>>>>> + * before updating the proc->table_ptr reference.
>>>>>> */
>>>>>> - rproc->table_ptr = rproc->cached_table;
>>>>>> + if (!rproc->tee_interface) {
>>>>>> + /*
>>>>>> + * Use a copy of the resource table for the remainder of the
>>>>>> + * shutdown process.
>>>>>> + */
>>>>>> + rproc->table_ptr = rproc->cached_table;
>>>>>> + }
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> --
>>>>>> 2.25.1
>>>>>>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
2024-06-03 8:21 ` Arnaud POULIQUEN
@ 2024-06-03 14:24 ` Mathieu Poirier
0 siblings, 0 replies; 20+ messages in thread
From: Mathieu Poirier @ 2024-06-03 14:24 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, linux-remoteproc, linux-kernel, linux-stm32
On Mon, 3 Jun 2024 at 02:22, Arnaud POULIQUEN
<arnaud.pouliquen@foss.st.com> wrote:
>
> Hello Mathieu,
>
> On 5/31/24 19:28, Mathieu Poirier wrote:
> > On Thu, May 30, 2024 at 09:42:26AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 5/29/24 22:35, Mathieu Poirier wrote:
> >>> On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> >>>> Hello Mathieu,
> >>>>
> >>>> On 5/28/24 23:30, Mathieu Poirier wrote:
> >>>>> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> >>>>>> 1) on start:
> >>>>>> - Using the TEE loader, the resource table is loaded by an external entity.
> >>>>>> In such case the resource table address is not find from the firmware but
> >>>>>> provided by the TEE remoteproc framework.
> >>>>>> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> >>>>>> - test that rproc->cached_table is not null before performing the memcpy
> >>>>>>
> >>>>>> 2)on stop
> >>>>>> The use of the cached_table seems mandatory:
> >>>>>> - during recovery sequence to have a snapshot of the resource table
> >>>>>> resources used,
> >>>>>> - on stop to allow for the deinitialization of resources after the
> >>>>>> the remote processor has been shutdown.
> >>>>>> However if the TEE interface is being used, we first need to unmap the
> >>>>>> table_ptr before setting it to rproc->cached_table.
> >>>>>> The update of rproc->table_ptr to rproc->cached_table is performed in
> >>>>>> tee_remoteproc.
> >>>>>>
> >>>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>>>> ---
> >>>>>> drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++-------
> >>>>>> 1 file changed, 23 insertions(+), 8 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >>>>>> index 42bca01f3bde..3a642151c983 100644
> >>>>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>>>> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> >>>>>> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> >>>>>> {
> >>>>>> struct resource_table *loaded_table;
> >>>>>> + struct device *dev = &rproc->dev;
> >>>>>>
> >>>>>> /*
> >>>>>> * The starting device has been given the rproc->cached_table as the
> >>>>>> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmwa
> >>>>>> * this information to device memory. We also update the table_ptr so
> >>>>>> * that any subsequent changes will be applied to the loaded version.
> >>>>>> */
> >>>>>> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>>>> - if (loaded_table) {
> >>>>>> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>>>> - rproc->table_ptr = loaded_table;
> >>>>>> + if (rproc->tee_interface) {
> >>>>>> + loaded_table = rproc_get_loaded_rsc_table(rproc, &rproc->table_sz);
> >>>>>> + if (IS_ERR(loaded_table)) {
> >>>>>> + dev_err(dev, "can't get resource table\n");
> >>>>>> + return PTR_ERR(loaded_table);
> >>>>>> + }
> >>>>>> + } else {
> >>>>>> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> >>>>>> }
> >>>>>>
> >>>>>> + if (loaded_table && rproc->cached_table)
> >>>>>> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> >>>>>> +
> >>>>>
> >>>>> Why is this not part of the else {} above as it was the case before this patch?
> >>>>> And why was an extra check for ->cached_table added?
> >>>>
> >>>> Here we have to cover 2 use cases if rproc->tee_interface is set.
> >>>> 1) The remote processor is in stop state
> >>>> - loaded_table points to the resource table in the remote memory and
> >>>> - rproc->cached_table is null
> >>>> => no memcopy
> >>>> 2) crash recovery
> >>>> - loaded_table points to the resource table in the remote memory
> >>>> - rproc-cached_table point to a copy of the resource table
> >>>
> >>> A cached_table exists because it was created in rproc_reset_rsc_table_on_stop().
> >>> But as the comment says [1], that part of the code was meant to be used for the
> >>> attach()/detach() use case. Mixing both will become extremely confusing and
> >>> impossible to maintain.
> >>
> >> i am not sure to understand your point here... the cached_table table was
> >> already existing for the "normal" case[2]. Seems to me that the cache table is
> >> needed on stop in all scenarios.
> >>
> >> [2]
> >> https://elixir.bootlin.com/linux/v4.20.17/source/drivers/remoteproc/remoteproc_core.c#L1402
> >>
> >>>
> >>> I think the TEE scenario should be as similar as the "normal" one where TEE is
> >>> not involved. To that end, I suggest to create a cached_table in
> >>> tee_rproc_parse_fw(), exactly the same way it is done in
> >>> rproc_elf_load_rsc_table(). That way the code path in
> >>> rproc_set_rsc_table_on_start() become very similar and we have a cached_table to
> >>> work with when the remote processor is recovered. In fact we may not need
> >>> rproc_set_rsc_table_on_start() at all but that needs to be asserted.
> >>
> >> This is was I proposed in my V4 [3]. Could you please confirm that this aligns
> >> with what you have in mind?
> >
> > After spending more time on this I have the following 3 observations:
> >
> > 1) We need a ->cached_table, otherwise the crash recovery path gets really
> > messy.
> >
> > 2) It _might_ be a good idea to rename tee_rproc_get_loaded_rsc_table() to
> > tee_rproc_find_loaded_rsc_table() to be aligned with the scenario where the
> > firmware is loaded by the remoteproc core. I think you had
> > tee_rproc_find_loaded_rsc_table() in the first place and I asked you to change
> > it. If so, apologies - reviewing patches isn't an exact science.
> >
> > 3) The same way ->cached_table is created in rproc_elf_load_rsc_table(), which
> > is essentially ops::parse_fw(), we should create one in tee_rproc_parse_fw()
> > with a kmemdup(). Exactly the same as in rproc_elf_load_rsc_table(). In
> > tee_rproc_parse_fw(), @rsc_table should be iounmap'ed right away so that we
> > don't need to keep a local variable to free it later. In rproc_start() the call
> > to rproc_find_loaded_rsc_table() will get another mapped handle to the resource
> > table in memory. It might be a little unefficient but it sure beats doing a lot
> > of modifications in the core.
>
> Remapping the resource table in rproc_find_loaded_rsc_table will require that we
> unmap it on rproc_stop before updating rproc->table_ptr to rproc->cached_table.
>
Exactly.
> On the other hand, I wonder if declaring the memory region in the stm32-rproc DT
> node would address this second mapping and avoid a map in
> rproc_find_loaded_rsc_table().
>
That would be even better.
> I will do the V6 integrating your suggestions and having a deeper look on the
> resource table map/unmap.
>
> >
> > As I said above this isn't an exact science and we may need to changes more
> > things but at least it should take us a little further.
>
> That seems to me reasonable and part of the normal upstream process :)
>
>
> Thanks,
> Arnaud
>
> >
> > Thanks,
> > Mathieu
> >
> >> In such a case, should I keep the updates below in
> >> rproc_reset_rsc_table_on_stop(), or should I revert to using rproc->rsc_table to
> >> store the pointer to the resource table in tee_remoteproc for the associated
> >> memory map/unmap?"
> >>
> >> [3]
> >> https://patchwork.kernel.org/project/linux-remoteproc/patch/20240308144708.62362-2-arnaud.pouliquen@foss.st.com/
> >>
> >> Thanks,
> >> Arnaud
> >>
> >>>
> >>> [1]. https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/remoteproc/remoteproc_core.c#L1565
> >>>
> >>>> => need to perform the memcpy to reapply settings in the resource table
> >>>>
> >>>> I can duplicate the memcpy in if{} and else{} but this will be similar code
> >>>> as needed in both case.
> >>>> Adding rproc->cached_table test if proc->tee_interface=NULL seems also
> >>>> reasonable as a memcpy from 0 should not be performed.
> >>>>
> >>>>
> >>>>>
> >>>>> This should be a simple change, i.e introduce an if {} else {} block to take
> >>>>> care of the two scenarios. Plus the comment is misplaced now.
> >>>>
> >>>> What about split it in 2 patches?
> >>>> - one adding the test on rproc->cached_table for the memcpy
> >>>> - one adding the if {} else {}?
> >>>>
> >>>> Thanks,
> >>>> Arnaud
> >>>>
> >>>>
> >>>>>
> >>>>> More comments tomorrow.
> >>>>>
> >>>>> Thanks,
> >>>>> Mathieu
> >>>>>
> >>>>>> + rproc->table_ptr = loaded_table;
> >>>>>> +
> >>>>>> return 0;
> >>>>>> }
> >>>>>>
> >>>>>> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> >>>>>> kfree(rproc->clean_table);
> >>>>>>
> >>>>>> out:
> >>>>>> - /*
> >>>>>> - * Use a copy of the resource table for the remainder of the
> >>>>>> - * shutdown process.
> >>>>>> + /* If the remoteproc_tee interface is used, then we have first to unmap the resource table
> >>>>>> + * before updating the proc->table_ptr reference.
> >>>>>> */
> >>>>>> - rproc->table_ptr = rproc->cached_table;
> >>>>>> + if (!rproc->tee_interface) {
> >>>>>> + /*
> >>>>>> + * Use a copy of the resource table for the remainder of the
> >>>>>> + * shutdown process.
> >>>>>> + */
> >>>>>> + rproc->table_ptr = rproc->cached_table;
> >>>>>> + }
> >>>>>> return 0;
> >>>>>> }
> >>>>>>
> >>>>>> --
> >>>>>> 2.25.1
> >>>>>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v5 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
` (4 preceding siblings ...)
2024-05-21 8:09 ` [PATCH v5 5/7] remoteproc: core: support of the tee interface Arnaud Pouliquen
@ 2024-05-21 8:10 ` Arnaud Pouliquen
2024-05-21 8:10 ` [PATCH v5 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware Arnaud Pouliquen
6 siblings, 0 replies; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:10 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
drivers/remoteproc/stm32_rproc.c | 84 +++++++++++++++++++-------------
1 file changed, 51 insertions(+), 33 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 88623df7d0c3..8cd838df4e92 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -209,6 +209,54 @@ static int stm32_rproc_mbox_idx(struct rproc *rproc, const unsigned char *name)
return -EINVAL;
}
+static void stm32_rproc_request_shutdown(struct rproc *rproc)
+{
+ struct stm32_rproc *ddata = rproc->priv;
+ int err, dummy_data, idx;
+
+ /* Request shutdown of the remote processor */
+ if (rproc->state != RPROC_OFFLINE && rproc->state != RPROC_CRASHED) {
+ idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_SHUTDOWN);
+ if (idx >= 0 && ddata->mb[idx].chan) {
+ /* A dummy data is sent to allow to block on transmit. */
+ err = mbox_send_message(ddata->mb[idx].chan,
+ &dummy_data);
+ if (err < 0)
+ dev_warn(&rproc->dev, "warning: remote FW shutdown without ack\n");
+ }
+ }
+}
+
+static int stm32_rproc_release(struct rproc *rproc)
+{
+ struct stm32_rproc *ddata = rproc->priv;
+ unsigned int err = 0;
+
+ /* To allow platform Standby power mode, set remote proc Deep Sleep. */
+ if (ddata->pdds.map) {
+ err = regmap_update_bits(ddata->pdds.map, ddata->pdds.reg,
+ ddata->pdds.mask, 1);
+ if (err) {
+ dev_err(&rproc->dev, "failed to set pdds\n");
+ return err;
+ }
+ }
+
+ /* Update coprocessor state to OFF if available. */
+ if (ddata->m4_state.map) {
+ err = regmap_update_bits(ddata->m4_state.map,
+ ddata->m4_state.reg,
+ ddata->m4_state.mask,
+ M4_STATE_OFF);
+ if (err) {
+ dev_err(&rproc->dev, "failed to set copro state\n");
+ return err;
+ }
+ }
+
+ return 0;
+}
+
static int stm32_rproc_prepare(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
@@ -519,17 +567,9 @@ static int stm32_rproc_detach(struct rproc *rproc)
static int stm32_rproc_stop(struct rproc *rproc)
{
struct stm32_rproc *ddata = rproc->priv;
- int err, idx;
+ int err;
- /* request shutdown of the remote processor */
- if (rproc->state != RPROC_OFFLINE && rproc->state != RPROC_CRASHED) {
- idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_SHUTDOWN);
- if (idx >= 0 && ddata->mb[idx].chan) {
- err = mbox_send_message(ddata->mb[idx].chan, "detach");
- if (err < 0)
- dev_warn(&rproc->dev, "warning: remote FW shutdown without ack\n");
- }
- }
+ stm32_rproc_request_shutdown(rproc);
err = stm32_rproc_set_hold_boot(rproc, true);
if (err)
@@ -541,29 +581,7 @@ static int stm32_rproc_stop(struct rproc *rproc)
return err;
}
- /* to allow platform Standby power mode, set remote proc Deep Sleep */
- if (ddata->pdds.map) {
- err = regmap_update_bits(ddata->pdds.map, ddata->pdds.reg,
- ddata->pdds.mask, 1);
- if (err) {
- dev_err(&rproc->dev, "failed to set pdds\n");
- return err;
- }
- }
-
- /* update coprocessor state to OFF if available */
- if (ddata->m4_state.map) {
- err = regmap_update_bits(ddata->m4_state.map,
- ddata->m4_state.reg,
- ddata->m4_state.mask,
- M4_STATE_OFF);
- if (err) {
- dev_err(&rproc->dev, "failed to set copro state\n");
- return err;
- }
- }
-
- return 0;
+ return stm32_rproc_release(rproc);
}
static void stm32_rproc_kick(struct rproc *rproc, int vqid)
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH v5 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
` (5 preceding siblings ...)
2024-05-21 8:10 ` [PATCH v5 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
@ 2024-05-21 8:10 ` Arnaud Pouliquen
6 siblings, 0 replies; 20+ messages in thread
From: Arnaud Pouliquen @ 2024-05-21 8:10 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: linux-remoteproc, linux-kernel, linux-stm32, arnaud.pouliquen
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format defined by the TEE.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
---
Update from V4:
- remove hard coded remote proc ID STM32_MP1_M4_PROC_ID, get the
ID from the DT,
- replace find_loaded_rsc_table by get_loaded_rsc_table.
---
drivers/remoteproc/stm32_rproc.c | 65 ++++++++++++++++++++++++++++++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 8cd838df4e92..f6f748814bf2 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -20,6 +20,7 @@
#include <linux/remoteproc.h>
#include <linux/reset.h>
#include <linux/slab.h>
+#include <linux/tee_remoteproc.h>
#include <linux/workqueue.h>
#include "remoteproc_internal.h"
@@ -257,6 +258,19 @@ static int stm32_rproc_release(struct rproc *rproc)
return 0;
}
+static int stm32_rproc_tee_stop(struct rproc *rproc)
+{
+ int err;
+
+ stm32_rproc_request_shutdown(rproc);
+
+ err = tee_rproc_stop(rproc);
+ if (err)
+ return err;
+
+ return stm32_rproc_release(rproc);
+}
+
static int stm32_rproc_prepare(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
@@ -693,8 +707,20 @@ static const struct rproc_ops st_rproc_ops = {
.get_boot_addr = rproc_elf_get_boot_addr,
};
+static const struct rproc_ops st_rproc_tee_ops = {
+ .prepare = stm32_rproc_prepare,
+ .start = tee_rproc_start,
+ .stop = stm32_rproc_tee_stop,
+ .kick = stm32_rproc_kick,
+ .load = tee_rproc_load_fw,
+ .parse_fw = tee_rproc_parse_fw,
+ .get_loaded_rsc_table = tee_rproc_get_loaded_rsc_table,
+
+};
+
static const struct of_device_id stm32_rproc_match[] = {
- { .compatible = "st,stm32mp1-m4" },
+ {.compatible = "st,stm32mp1-m4",},
+ {.compatible = "st,stm32mp1-m4-tee",},
{},
};
MODULE_DEVICE_TABLE(of, stm32_rproc_match);
@@ -853,17 +879,42 @@ static int stm32_rproc_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct stm32_rproc *ddata;
struct device_node *np = dev->of_node;
+ struct tee_rproc *trproc = NULL;
struct rproc *rproc;
unsigned int state;
+ u32 proc_id;
int ret;
ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
- rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
- if (!rproc)
- return -ENOMEM;
+ if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
+ /*
+ * Delegate the firmware management to the secure context.
+ * The firmware loaded has to be signed.
+ */
+ ret = of_property_read_u32(np, "st,proc-id", &proc_id);
+ if (ret) {
+ dev_err(dev, "failed to read st,rproc-id property\n");
+ return ret;
+ }
+
+ rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, NULL, sizeof(*ddata));
+ if (!rproc)
+ return -ENOMEM;
+
+ trproc = tee_rproc_register(dev, rproc, proc_id);
+ if (IS_ERR(trproc)) {
+ dev_err_probe(dev, PTR_ERR(trproc),
+ "signed firmware not supported by TEE\n");
+ return PTR_ERR(trproc);
+ }
+ } else {
+ rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
+ if (!rproc)
+ return -ENOMEM;
+ }
ddata = rproc->priv;
@@ -915,6 +966,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
}
+ if (trproc)
+ tee_rproc_unregister(trproc);
+
return ret;
}
@@ -935,6 +989,9 @@ static void stm32_rproc_remove(struct platform_device *pdev)
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
}
+ if (rproc->tee_interface)
+ tee_rproc_unregister(rproc->tee_interface);
+
}
static int stm32_rproc_suspend(struct device *dev)
--
2.25.1
^ permalink raw reply related [flat|nested] 20+ messages in thread