Hi Abdellatif,

On Wed, Aug 13, 2025 at 05:42:58PM +0100, Abdellatif El Khlifi wrote:

Hi Arnaud,

quoted

Add a remoteproc TEE (Trusted Execution Environment) driver that will be
probed by the TEE bus. If the associated Trusted application is supported
on the secure part, this driver offers a client interface to load firmware
by the secure part.
This firmware could be authenticated by the secure trusted application.

A specificity of the implementation is that the firmware has to be
authenticated and optionally decrypted to access the resource table.

Consequently, the boot sequence is:

1) rproc_parse_fw --> rproc_tee_parse_fw
   remoteproc TEE:
   - Requests the TEE application to authenticate and load the firmware
     in the remote processor memories.
   - Requests the TEE application for the address of the resource table.
   - Creates a copy of the resource table stored in rproc->cached_table.

2) rproc_load_segments --> rproc_tee_load_fw
   remoteproc TEE:
   - Requests the TEE application to load the firmware. Nothing is done
     at the TEE application as the firmware is already loaded.
   - In case of recovery, the TEE application has to reload the firmware.

3) rproc_tee_get_loaded_rsc_table
   remoteproc TEE requests the TEE application for the address of the
   resource table.

4) rproc_start --> rproc_tee_start
   - Requests the TEE application to start the remote processor.

The shutdown sequence is:

5) rproc_stop --> rproc_tee_stop
   - Requests the TEE application to stop the remote processor.

6) rproc_tee_release_fw
   This function is used to request the TEE application to perform actions
   to return to the initial state on stop or on error during the boot
   sequence.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>

...

quoted

+
+static const struct tee_client_device_id rproc_tee_id_table[] = {
+	{UUID_INIT(0x80a4c275, 0x0a47, 0x4905, 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
+	{}
+};

Other implementations may use different UUIDs.
What about adding a kernel configuration option which, when enabled, allows
alternative implementations to override this table?

You don't need any other kernel configuration option for table override
but rather you extend this table with UUID for service provided by
TS-TEE.

quoted

+/**
+ * rproc_tee_register() - Register a remote processor controlled by the TEE application.

...

quoted

+
+static int rproc_tee_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);
+}

Could we make ver->impl_id user-configurable please ? for example, by reading
it from the device tree since it isn’t discoverable at runtime? In our setup, we’d set
it to TEE_IMPL_ID_TSTEE.

In case the TS-TEE service gets enumerated on TEE bus then the
ver->impl_id will get automatically configured to TEE_IMPL_ID_TSTEE. It
is how the driver will get to know if it is communicating with an OP-TEE
based service of TS-TEE based service.

quoted

+
+static int rproc_tee_probe(struct device *dev)
+{
+	struct tee_context *tee_ctx;
+	int ret;
+
+	/* Open context with TEE driver */
+	tee_ctx = tee_client_open_context(NULL, rproc_tee_ctx_match, NULL, NULL);
+	if (IS_ERR(tee_ctx))
+		return PTR_ERR(tee_ctx);
+
+	ret = mutex_lock_interruptible(&ctx_lock);
+	if (ret)
+		return ret;

In some TEEs, the client driver might need to perform extra work during probing.
For example, when using TS TEE, calling tee_shm_alloc_kernel_buf() is required.
Could we introduce an rproc_tee_ops and add a TEE probe operation called by the
remoteproc driver for performing custom TEE setup ?

Sure, as I mentioned above the driver will be able to know if it's
communicating with TS-TEE then the additional functionality needed can
be conditionally implemented during probe.

I think it is really the next step after this patch-set lands where we
have to support the remoteproc service hosted under different TEE
implementations like OP-TEE, TS-TEE or QTEE etc.

-Sumit