[RFC PATCH v1 0/6] tee: optee: RISC-V support over the RPMI TEE service group

[RFC PATCH v1 0/6] tee: optee: RISC-V support over the RPMI TEE service group

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

On RISC-V, OP-TEE runs as a supervisor domain isolated from Linux by the
M-mode firmware. There is no SMC or HVC instruction: the firmware has to
switch the calling hart between the two domains, and the way Linux asks
for that switch has to come from the RISC-V specifications rather than
from an ad-hoc SBI extension.

This series adds RISC-V support to the OP-TEE driver by carrying the
existing SMC ABI over the TEE service group of the RISC-V Platform
Management Interface (RPMI) [1], sent with the SBI Message Proxy (MPXY)
extension of SBI v3.0 [2] through the in-tree MPXY mailbox driver. Each
invocation of the SMC ABI becomes a TEE_CALL request whose service data
holds the register arguments a0-a7, and whose service response holds
the return values a0-a3. The M-mode firmware implementing the service
group (the "RPMI TEE framework") switches the calling hart to the OP-TEE
domain until OP-TEE responds, so a TEE_CALL behaves like an SMC: it runs
on the calling hart and returns when OP-TEE completes the call, requests
an RPC or yields on a foreign interrupt. The SMC ABI, the message
protocol, RPCs, dynamic and static shared memory and notifications are
unchanged, which is why the conduit lives next to the SMCCC one in
smc_abi.c instead of being a new ABI like ffa_abi.c.

Specification status, and how the series is split:

The TEE service group (SERVICEGROUP_ID 0x0010) is part of RPMI v2.0,
which is in development: it was added to the main branch of the
specification repository in June 2026 [3] and is not in the released
RPMI v1.0. Everything in this series that depends on it is kept in the
last three patches, which are RFC until RPMI v2.0 is frozen as required
by Documentation/arch/riscv/patch-acceptance.rst:

- patches 1-3 only rely on SBI v3.0 MPXY and RPMI v1.0 as already
  supported by the kernel, and on existing OP-TEE driver internals.
  They are meant to be mergeable on their own;

- patches 4-6 add the RPMI v2.0 TEE service group definitions, the
  binding and the conduit. They implement TEE_CALL as specified; the
  only OP-TEE specific parts are the content of the service data and
  service response, which the specification leaves to the service, and
  the OP-TEE API UID used as service UUID.

Why this conduit rather than the alternatives:

- A raw ecall to a "TEE" SBI extension, as used by the current OP-TEE OS
  RISC-V port and by the RISE reference firmware, relies on an EID that
  does not exist in the SBI specification and on returning four values
  from an ecall, which the SBI calling convention does not allow.

- The RPMI MANAGEMENT_MODE service group (RPMI v1.0) is defined for UEFI
  PI Management Mode communication and its data is the MM communication
  buffer; carrying the OP-TEE message protocol in it would go against
  the specification's intent and collide with its intended users.

- An implementation specific service group (0x8000-0xFFFF) is allowed by
  RPMI v1.0 but would not be a generic OP-TEE conduit.

The one non-obvious part is patch 1. An MPXY message send is an ecall on
the calling hart, using per-hart shared memory, which returns once the
message has been processed. With TEE_CALL that is when OP-TEE has
finished running on that hart, which can take an arbitrarily long time.
Sending such messages with mbox_send_message() would execute OP-TEE from
within msg_submit() with the mailbox channel spinlock held and
interrupts disabled, serializing every hart on that lock. Patch 1 adds
riscv_sbi_mpxy_mbox_call() to the MPXY mailbox driver, which performs
the transfer directly in the calling context with only local interrupts
disabled (the per-hart shared memory is also used from hard interrupt
context by mbox_send_message() users). Harts proceed in parallel since
each one has its own shared memory. The channel is still requested
through the mailbox core so that its ownership is tracked. Opinions on
whether this belongs in the MPXY driver, or whether the MPXY shared
memory handling should move to a core helper usable by several drivers,
are welcome.

Endpoint identifiers: the framework assigns an identifier to every REE
and TEE. The only way for an endpoint to learn them without firmware
help is the optional TEE_PROBE_SYSTEM service, whose response is CBOR
encoded and cannot be parsed in the kernel, so the binding carries the
REE and OP-TEE identifiers as properties that the firmware is expected
to fix up in the device tree. Feedback on this is welcome too.

Known gaps:

- The framework side (OpenSBI: TEE_CALL forwarding through domain
  context switching) and the messaging return path of the OP-TEE OS
  RISC-V port are being upstreamed separately.

- The service group defines no notification events; OP-TEE asynchronous
  notifications on RISC-V are left for later and OP-TEE OS does not
  advertise them on this conduit.

- The byte order of the SERVICE UUID field is not specified by RPMI;
  this series uses the RFC 4122 order. The memory parcel services of the
  service group are not used, secure world accesses registered pages
  directly as with the SMC conduit.

Testing: built for riscv64 (defconfig plus TEE/OP-TEE, both built-in and
as modules) and for arm64 (defconfig plus OP-TEE and FF-A) with W=1 at
every step of the series, plus dt_binding_check. [TODO before posting:
describe the runtime testing done on QEMU virt with the OpenSBI and
OP-TEE OS changes mentioned above, e.g. xtest results.]

[1] https://github.com/riscv-non-isa/riscv-rpmi/releases
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/releases
[3] https://github.com/riscv-non-isa/riscv-rpmi/commits/main/src/srvgrp-tee.adoc


Marouene Boubakri (6):
  mailbox: riscv-sbi-mpxy: add riscv_sbi_mpxy_mbox_call() for hart-local
    requests
  tee: optee: select the SMC ABI conduit from the firmware node match
    data
  tee: optee: teach the memory type check about RISC-V page attributes
  mailbox: riscv-rpmi-message: add TEE service group definitions
  dt-bindings: firmware: add OP-TEE over the RISC-V RPMI TEE service
    group
  tee: optee: add a RISC-V conduit over the RPMI TEE service group

 .../bindings/firmware/linaro,optee-rpmi.yaml  |  79 +++++++
 Documentation/tee/op-tee.rst                  |  18 +-
 MAINTAINERS                                   |   2 +
 drivers/mailbox/riscv-sbi-mpxy-mbox.c         |  60 ++++++
 drivers/tee/Kconfig                           |   2 +-
 drivers/tee/optee/Kconfig                     |  11 +-
 drivers/tee/optee/Makefile                    |   1 +
 drivers/tee/optee/call.c                      |   8 +
 drivers/tee/optee/optee_private.h             |   3 +
 drivers/tee/optee/optee_rpmi.h                |  69 ++++++
 drivers/tee/optee/rpmi_conduit.c              | 203 ++++++++++++++++++
 drivers/tee/optee/smc_abi.c                   |  41 +++-
 include/linux/mailbox/riscv-rpmi-message.h    |  25 +++
 include/linux/mailbox/riscv-sbi-mpxy-mbox.h   |  23 ++
 14 files changed, 538 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml
 create mode 100644 drivers/tee/optee/optee_rpmi.h
 create mode 100644 drivers/tee/optee/rpmi_conduit.c
 create mode 100644 include/linux/mailbox/riscv-sbi-mpxy-mbox.h


base-commit: 50d05c7c76c96b90462f24debacca971d2e86713
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 1/6] mailbox: riscv-sbi-mpxy: add riscv_sbi_mpxy_mbox_call() for hart-local requests

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

An SBI MPXY message send is not queued in a hardware mailbox: it is an
ecall executed on the calling hart with the calling hart's shared memory
which returns once the SBI implementation has processed the message.
For most RPMI service groups that means forwarding the message to a
platform microcontroller, which takes a bounded time. Some message
protocols are instead processed on the calling hart itself, for example
when the SBI implementation forwards the message to another supervisor
domain and switches the hart to it until it responds (this is the model
of the TEE service group of RPMI v2.0, where TEE_CALL runs the target
TEE on the hart of the caller). Such processing is unbounded and
depends on interrupts reaching the other domain so that it can yield.

Sending such messages through mbox_send_message() is not an option: the
mailbox core calls the controller send_data() callback from msg_submit()
with the channel spinlock held and interrupts disabled. Every hart would
then serialize on a single spinlock, spinning with interrupts disabled
for the whole duration of a message processed on another hart, while
the calling hart would run the other domain with the channel lock held.

Add riscv_sbi_mpxy_mbox_call() which performs the RPMI transfer directly
in the calling context, bypassing the mailbox core queue and channel
lock. The channel must still be requested through the mailbox core so
that its ownership is tracked. Local interrupts are disabled around the
ecall since the per-hart shared memory is also used from hard interrupt
context by mbox_send_message() users such as the RPMI system MSI
irqchip; calls from different harts proceed in parallel because each
hart has its own shared memory.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 MAINTAINERS                                 |  1 +
 drivers/mailbox/riscv-sbi-mpxy-mbox.c       | 60 +++++++++++++++++++++
 include/linux/mailbox/riscv-sbi-mpxy-mbox.h | 23 ++++++++
 3 files changed, 84 insertions(+)
 create mode 100644 include/linux/mailbox/riscv-sbi-mpxy-mbox.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c392ded53..44860f991 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23581,6 +23581,7 @@ F:	drivers/clk/clk-rpmi.c
 F:	drivers/irqchip/irq-riscv-rpmi-sysmsi.c
 F:	drivers/mailbox/riscv-sbi-mpxy-mbox.c
 F:	include/linux/mailbox/riscv-rpmi-message.h
+F:	include/linux/mailbox/riscv-sbi-mpxy-mbox.h
 
 RISC-V SPACEMIT SoC Support
 M:	Yixun Lan <dlan@kernel.org>
diff --git a/drivers/mailbox/riscv-sbi-mpxy-mbox.c b/drivers/mailbox/riscv-sbi-mpxy-mbox.c
index ea69c6b6b..2c80e6fd1 100644
--- a/drivers/mailbox/riscv-sbi-mpxy-mbox.c
+++ b/drivers/mailbox/riscv-sbi-mpxy-mbox.c
@@ -12,6 +12,7 @@
 #include <linux/irqchip/riscv-imsic.h>
 #include <linux/mailbox_controller.h>
 #include <linux/mailbox/riscv-rpmi-message.h>
+#include <linux/mailbox/riscv-sbi-mpxy-mbox.h>
 #include <linux/minmax.h>
 #include <linux/mm.h>
 #include <linux/module.h>
@@ -719,6 +720,65 @@ static const struct mbox_chan_ops mpxy_mbox_ops = {
 	.shutdown = mpxy_mbox_shutdown,
 };
 
+/**
+ * riscv_sbi_mpxy_mbox_call() - Send an RPMI message directly on an MPXY channel
+ * @chan: SBI MPXY mailbox channel owned by the caller
+ * @msg: RPMI message of type RPMI_MBOX_MSG_TYPE_SEND_WITH_RESPONSE or
+ *       RPMI_MBOX_MSG_TYPE_SEND_WITHOUT_RESPONSE
+ *
+ * An SBI MPXY message send is not queued anywhere: it is an ecall executed
+ * on the calling hart, using the calling hart's shared memory, which only
+ * returns once the SBI implementation has processed the message. For some
+ * message protocols that processing is unbounded because it runs on the
+ * calling hart itself, for example when the SBI implementation forwards
+ * the message to another supervisor domain and switches the hart to it
+ * until it responds (the RPMI TEE service group's TEE_CALL does this).
+ *
+ * Such messages must not go through mbox_send_message(): the mailbox core
+ * invokes the controller send_data() callback with the channel spinlock
+ * held and interrupts disabled, which would serialize all harts on a single
+ * lock and keep interrupts disabled on the calling hart for the whole
+ * duration of the call.
+ *
+ * This helper bypasses the mailbox core queue and channel lock and performs
+ * the transfer directly in the calling context. Only local interrupts are
+ * disabled around the ecall, because the per-hart shared memory can be used
+ * from hard interrupt context through mbox_send_message() by other clients.
+ * Calls from different harts run concurrently since each hart has its own
+ * shared memory.
+ *
+ * The caller must own @chan through mbox_request_channel() (or a variant of
+ * it) so that no other client can use the channel, and must not use
+ * mbox_send_message() on it concurrently.
+ *
+ * Return: 0 on success or a negative error code.
+ */
+int riscv_sbi_mpxy_mbox_call(struct mbox_chan *chan,
+			     struct rpmi_mbox_message *msg)
+{
+	struct mpxy_mbox_channel *mchan;
+	unsigned long flags;
+
+	if (!chan || !chan->cl || !chan->mbox || !msg)
+		return -EINVAL;
+	if (chan->mbox->ops != &mpxy_mbox_ops)
+		return -EINVAL;
+	if (msg->type != RPMI_MBOX_MSG_TYPE_SEND_WITH_RESPONSE &&
+	    msg->type != RPMI_MBOX_MSG_TYPE_SEND_WITHOUT_RESPONSE)
+		return -EINVAL;
+
+	mchan = chan->con_priv;
+	if (mchan->attrs.msg_proto_id != SBI_MPXY_MSGPROTO_RPMI_ID)
+		return -EOPNOTSUPP;
+
+	local_irq_save(flags);
+	mpxy_mbox_send_rpmi_data(mchan, msg);
+	local_irq_restore(flags);
+
+	return msg->error;
+}
+EXPORT_SYMBOL_GPL(riscv_sbi_mpxy_mbox_call);
+
 /* ====== MPXY platform driver ===== */
 
 static void mpxy_mbox_msi_write(struct msi_desc *desc, struct msi_msg *msg)
diff --git a/include/linux/mailbox/riscv-sbi-mpxy-mbox.h b/include/linux/mailbox/riscv-sbi-mpxy-mbox.h
new file mode 100644
index 000000000..4fb7b04cd
--- /dev/null
+++ b/include/linux/mailbox/riscv-sbi-mpxy-mbox.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright 2026 NXP */
+
+#ifndef _LINUX_RISCV_SBI_MPXY_MBOX_H_
+#define _LINUX_RISCV_SBI_MPXY_MBOX_H_
+
+#include <linux/errno.h>
+
+struct mbox_chan;
+struct rpmi_mbox_message;
+
+#if IS_ENABLED(CONFIG_RISCV_SBI_MPXY_MBOX)
+int riscv_sbi_mpxy_mbox_call(struct mbox_chan *chan,
+			     struct rpmi_mbox_message *msg);
+#else
+static inline int riscv_sbi_mpxy_mbox_call(struct mbox_chan *chan,
+					   struct rpmi_mbox_message *msg)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif /* _LINUX_RISCV_SBI_MPXY_MBOX_H_ */
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 2/6] tee: optee: select the SMC ABI conduit from the firmware node match data

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

The SMC ABI is defined in terms of register arguments and return values
and does not depend on how they reach secure world: smc_abi.c already
abstracts the conduit behind optee_invoke_fn, only its selection is
hard-wired to the SMCCC "method" property of the "linaro,optee-tz" node.

Introduce struct optee_smc_conduit carried by the match data of the
firmware node, move the SMCCC specific wrappers and the "method"
property parsing into the SMCCC conduit and build that conduit only
when the architecture provides SMCCC (__arm_smccc_hvc() has no stub
when CONFIG_HAVE_ARM_SMCCC is not set).

This prepares for a conduit that carries the SMC ABI over RISC-V RPMI
messages. No functional change on Arm.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 drivers/tee/optee/smc_abi.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
index b8a2bdac3..221939f72 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -1464,6 +1464,20 @@ optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm)
 	return rc;
 }
 
+/*
+ * struct optee_smc_conduit - conduit used to invoke the SMC ABI
+ * @init:	probes the conduit and returns the function invoking the
+ *		SMC ABI through it, or an ERR_PTR() on failure
+ *
+ * The SMC ABI is defined in terms of register arguments and return values
+ * (see optee_smc.h) but does not depend on how they reach secure world. A
+ * conduit is selected by the compatible string of the OP-TEE firmware node.
+ */
+struct optee_smc_conduit {
+	optee_invoke_fn *(*init)(struct device *dev);
+};
+
+#ifdef CONFIG_HAVE_ARM_SMCCC
 /* Simple wrapper functions to be able to use a function pointer */
 static void optee_smccc_smc(unsigned long a0, unsigned long a1,
 			    unsigned long a2, unsigned long a3,
@@ -1483,7 +1497,7 @@ static void optee_smccc_hvc(unsigned long a0, unsigned long a1,
 	arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
 }
 
-static optee_invoke_fn *get_invoke_func(struct device *dev)
+static optee_invoke_fn *optee_smccc_conduit_init(struct device *dev)
 {
 	const char *method;
 
@@ -1503,6 +1517,11 @@ static optee_invoke_fn *get_invoke_func(struct device *dev)
 	return ERR_PTR(-EINVAL);
 }
 
+static const struct optee_smc_conduit optee_smccc_conduit = {
+	.init = optee_smccc_conduit_init,
+};
+#endif
+
 /* optee_remove - Device Removal Routine
  * @pdev: platform device information struct
  *
@@ -1728,6 +1747,7 @@ static int optee_protmem_pool_init(struct optee *optee)
 
 static int optee_probe(struct platform_device *pdev)
 {
+	const struct optee_smc_conduit *conduit;
 	optee_invoke_fn *invoke_fn;
 	struct tee_shm_pool *pool = ERR_PTR(-EINVAL);
 	struct optee *optee = NULL;
@@ -1741,7 +1761,11 @@ static int optee_probe(struct platform_device *pdev)
 	u32 sec_caps;
 	int rc;
 
-	invoke_fn = get_invoke_func(&pdev->dev);
+	conduit = device_get_match_data(&pdev->dev);
+	if (!conduit)
+		return -ENODEV;
+
+	invoke_fn = conduit->init(&pdev->dev);
 	if (IS_ERR(invoke_fn))
 		return PTR_ERR(invoke_fn);
 
@@ -1956,7 +1980,9 @@ static int optee_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id optee_dt_match[] = {
-	{ .compatible = "linaro,optee-tz" },
+#ifdef CONFIG_HAVE_ARM_SMCCC
+	{ .compatible = "linaro,optee-tz", .data = &optee_smccc_conduit },
+#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, optee_dt_match);
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 3/6] tee: optee: teach the memory type check about RISC-V page attributes

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

optee_check_mem_type() only lets normal cacheable memory be registered
with secure world since OP-TEE maps registered pages as such and must
not observe mismatched memory attributes.

On RISC-V the memory type of a mapping is encoded in the Svpbmt bits of
the PTE (or their T-Head equivalent selected at runtime by the
_PAGE_MTMASK alternative): normal cacheable memory (PMA) has them
cleared, pgprot_writecombine() and pgprot_noncached() set them. Without
Svpbmt the memory type is defined by the PMAs alone, _PAGE_MTMASK is
empty and every mapping passes the check, as there is nothing else to
inspect.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 drivers/tee/optee/call.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index e046aff61..c29bff224 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -604,6 +604,14 @@ static bool is_normal_memory(pgprot_t p)
 #elif defined(CONFIG_ARM64)
 	return ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL)) ||
 	       ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED));
+#elif defined(CONFIG_RISCV)
+	/*
+	 * Svpbmt, or the T-Head equivalent, encodes non-cacheable and I/O
+	 * memory in the memory type bits of the PTE, normal cacheable memory
+	 * (PMA) has them cleared. Without Svpbmt the memory type only comes
+	 * from the PMAs, the mask is empty and all mappings pass the check.
+	 */
+	return !(pgprot_val(p) & _PAGE_MTMASK);
 #else
 #error "Unsupported architecture"
 #endif
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 4/6] mailbox: riscv-rpmi-message: add TEE service group definitions

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

The RPMI specification v2.0, currently in development on the main
branch of the specification repository, adds a TEE service group
(SERVICEGROUP_ID 0x0010) which lets a client in a Rich Execution
Environment invoke services in a Trusted Execution Environment through
the M-mode firmware or hypervisor implementing the group. Its TEE_CALL
service is a synchronous request whose target TEE executes on the hart
of the caller until a response is returned.

Add the service group ID and the service IDs, as defined in the
specification draft, so that TEE drivers can use them together with the
SBI MPXY mailbox driver.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 include/linux/mailbox/riscv-rpmi-message.h | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/include/linux/mailbox/riscv-rpmi-message.h b/include/linux/mailbox/riscv-rpmi-message.h
index e135c6564..0530e1ddd 100644
--- a/include/linux/mailbox/riscv-rpmi-message.h
+++ b/include/linux/mailbox/riscv-rpmi-message.h
@@ -93,6 +93,7 @@ static inline int rpmi_to_linux_error(int rpmi_error)
 /* RPMI service group IDs */
 #define RPMI_SRVGRP_SYSTEM_MSI		0x00002
 #define RPMI_SRVGRP_CLOCK		0x00008
+#define RPMI_SRVGRP_TEE			0x00010
 
 /* RPMI clock service IDs */
 enum rpmi_clock_service_id {
@@ -119,6 +120,30 @@ enum rpmi_sysmsi_service_id {
 	RPMI_SYSMSI_SRV_ID_MAX_COUNT
 };
 
+/* RPMI TEE service IDs */
+enum rpmi_tee_service_id {
+	RPMI_TEE_SRV_ENABLE_NOTIFICATION = 0x01,
+	RPMI_TEE_SRV_PROBE_FEATURES = 0x02,
+	RPMI_TEE_SRV_PROBE_SYSTEM = 0x03,
+	RPMI_TEE_SRV_EXIT = 0x04,
+	RPMI_TEE_SRV_SIGNAL_BUS_SETUP = 0x05,
+	RPMI_TEE_SRV_SIGNAL_BUS_TEARDOWN = 0x06,
+	RPMI_TEE_SRV_SIGNAL_RAISE = 0x07,
+	RPMI_TEE_SRV_SIGNAL_RETRIEVE = 0x08,
+	RPMI_TEE_SRV_MEMORY_PARCEL_CREATE = 0x09,
+	RPMI_TEE_SRV_MEMORY_PARCEL_ACCEPT = 0x0a,
+	RPMI_TEE_SRV_MEMORY_PARCEL_RELEASE = 0x0b,
+	RPMI_TEE_SRV_MEMORY_PARCEL_RECLAIM = 0x0c,
+	RPMI_TEE_SRV_MEMORY_SEGMENT_SEND = 0x0d,
+	RPMI_TEE_SRV_MEMORY_SEGMENT_RECEIVE = 0x0e,
+	RPMI_TEE_SRV_REGISTER_FOR_LIFECYCLE_INFO = 0x0f,
+	RPMI_TEE_SRV_ON_START_INFO = 0x10,
+	RPMI_TEE_SRV_ON_SHUTDOWN_INFO = 0x11,
+	RPMI_TEE_SRV_ON_CHANGED_INFO = 0x12,
+	RPMI_TEE_SRV_CALL = 0x13,
+	RPMI_TEE_SRV_ID_MAX_COUNT
+};
+
 /* RPMI Linux mailbox attribute IDs */
 enum rpmi_mbox_attribute_id {
 	RPMI_MBOX_ATTR_SPEC_VERSION,
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 5/6] dt-bindings: firmware: add OP-TEE over the RISC-V RPMI TEE service group

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

On RISC-V, OP-TEE runs as a supervisor domain isolated from the Rich
Execution Environment by the M-mode firmware. There is no SMC or HVC
instruction to reach it: the kernel invokes OP-TEE through the TEE
service group of the RISC-V Platform Management Interface (RPMI) v2.0,
carried on an SBI Message Proxy (MPXY) channel. Each call is a TEE_CALL
service request whose service data carries the register arguments of
the OP-TEE SMC ABI, so the ABI itself is unchanged from Arm.

Add a binding for such an OP-TEE instance. The compatible string keeps
the "linaro" vendor prefix of "linaro,optee-tz" which identifies the
OP-TEE reference implementation. The node references the MPXY mailbox
channel implementing the TEE service group, and carries the endpoint
identifiers assigned by the RPMI TEE framework to the REE and to OP-TEE
since the framework does not define any way for an endpoint to learn
them other than the optional TEE_PROBE_SYSTEM service, whose CBOR
encoded response cannot be parsed in the kernel.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 .../bindings/firmware/linaro,optee-rpmi.yaml  | 79 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml

diff --git a/Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml b/Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml
new file mode 100644
index 000000000..1c3dffc33
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/linaro,optee-rpmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OP-TEE accessed through the RISC-V RPMI TEE service group
+
+maintainers:
+  - Marouene Boubakri <marouene.boubakri@oss.nxp.com>
+
+description: |
+  OP-TEE is a piece of software using hardware features to provide a Trusted
+  Execution Environment. On RISC-V, OP-TEE runs as a supervisor domain
+  isolated from the Rich Execution Environment (REE) by the M-mode firmware.
+
+  The REE reaches OP-TEE through the TEE service group of the RISC-V Platform
+  Management Interface (RPMI) [1], carried on a channel of the SBI Message
+  Proxy (MPXY) extension [2]. Each call into OP-TEE is a TEE_CALL service
+  request whose service data carries the register arguments of the OP-TEE
+  SMC ABI (drivers/tee/optee/optee_smc.h), as described in
+  drivers/tee/optee/optee_rpmi.h.
+
+  The RPMI TEE framework (the M-mode firmware) assigns an identifier to each
+  endpoint. The identifiers of the REE and of OP-TEE are required to
+  address TEE_CALL requests and are described here.
+
+  The compatible string uses the same "linaro" vendor prefix as
+  "linaro,optee-tz", which identifies the OP-TEE reference implementation.
+
+  [1] RISC-V Platform Management Interface (RPMI) v2.0 (or higher)
+      https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+  [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+      https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+properties:
+  $nodename:
+    const: optee
+
+  compatible:
+    const: linaro,optee-rpmi
+
+  mboxes:
+    maxItems: 1
+    description:
+      SBI MPXY channel implementing the RPMI TEE service group.
+
+  riscv,rpmi-tee-sender-id:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Endpoint identifier of the REE, used as SENDER_ID of the TEE_CALL
+      requests.
+
+  riscv,rpmi-tee-target-id:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Endpoint identifier of OP-TEE, used as TARGET_ID of the TEE_CALL
+      requests.
+
+required:
+  - compatible
+  - mboxes
+  - riscv,rpmi-tee-sender-id
+  - riscv,rpmi-tee-target-id
+
+additionalProperties: false
+
+examples:
+  - |
+    firmware {
+        optee {
+            compatible = "linaro,optee-rpmi";
+            mboxes = <&mpxy_mbox 0x10 0x0>;
+            riscv,rpmi-tee-sender-id = <0>;
+            riscv,rpmi-tee-target-id = <1>;
+        };
+    };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 44860f991..bf4884f34 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20415,6 +20415,7 @@ M:	Jens Wiklander <jenswi@kernel.org>
 L:	op-tee@lists.trustedfirmware.org (moderated for non-subscribers)
 S:	Maintained
 F:	Documentation/ABI/testing/sysfs-bus-optee-devices
+F:	Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml
 F:	drivers/tee/optee/
 
 OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[RFC PATCH v1 6/6] tee: optee: add a RISC-V conduit over the RPMI TEE service group

[marouene.boubakri]

From: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

On RISC-V, OP-TEE runs as a supervisor domain isolated from the Rich
Execution Environment by the M-mode firmware. There is no SMC or HVC
instruction to reach it: the kernel invokes OP-TEE through the TEE
service group of the RISC-V Platform Management Interface (RPMI) v2.0,
whose TEE_CALL service is carried by the SBI Message Proxy (MPXY)
extension of SBI v3.0. The M-mode firmware implementing the service
group (the RPMI TEE framework) switches the calling hart to the OP-TEE
domain until OP-TEE responds, so a TEE_CALL behaves exactly like an
SMC: it runs on the calling hart and returns when OP-TEE completes the
call, requests an RPC or yields on a foreign interrupt.

Add a conduit for the SMC ABI which sends the register arguments a0-a7
of each invocation as the service data of a TEE_CALL request and takes
the return values a0-a3 from its service response, using the OP-TEE API
UID as the service UUID. The TEE_CALL request and response follow the
specification, only the content of the service data and of the service
response, which the specification leaves to the service, is defined
here. The message layout is in optee_rpmi.h which is kept in sync with
OP-TEE OS like optee_smc.h and optee_msg.h. The SMC ABI itself, the
message protocol, the RPC handling, dynamic and static shared memory
and notifications are unchanged.

The conduit binds to a "linaro,optee-rpmi" firmware node referencing the
MPXY mailbox channel and carrying the REE and OP-TEE endpoint
identifiers assigned by the framework. The channel is requested through
the mailbox core to claim it, and its RPMI attributes are checked at
probe, but TEE_CALL requests are sent with riscv_sbi_mpxy_mbox_call()
rather than mbox_send_message(): OP-TEE executes on the calling hart for
an unbounded time, which cannot happen under the mailbox channel
spinlock with interrupts disabled. Errors reported by the SBI
implementation or the framework, which mean that OP-TEE was not
reached, are converted into OPTEE_SMC_RETURN_EBUSY or
OPTEE_SMC_RETURN_ENOTAVAIL so that the callers see a failed call.

Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com>
---
 Documentation/tee/op-tee.rst      |  18 ++-
 drivers/tee/Kconfig               |   2 +-
 drivers/tee/optee/Kconfig         |  11 +-
 drivers/tee/optee/Makefile        |   1 +
 drivers/tee/optee/optee_private.h |   3 +
 drivers/tee/optee/optee_rpmi.h    |  69 ++++++++++
 drivers/tee/optee/rpmi_conduit.c  | 203 ++++++++++++++++++++++++++++++
 drivers/tee/optee/smc_abi.c       |   9 ++
 8 files changed, 312 insertions(+), 4 deletions(-)
 create mode 100644 drivers/tee/optee/optee_rpmi.h
 create mode 100644 drivers/tee/optee/rpmi_conduit.c

diff --git a/Documentation/tee/op-tee.rst b/Documentation/tee/op-tee.rst
index b0ac097d5..b56c32bf2 100644
--- a/Documentation/tee/op-tee.rst
+++ b/Documentation/tee/op-tee.rst
@@ -4,14 +4,24 @@
 OP-TEE (Open Portable Trusted Execution Environment)
 ====================================================
 
-The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
-TrustZone based OP-TEE solution that is supported.
+The OP-TEE driver handles OP-TEE [1] based TEEs. The ARM TrustZone based
+OP-TEE solution and OP-TEE running as an isolated supervisor domain on
+RISC-V are supported.
 
 Lowest level of communication with OP-TEE builds on ARM SMC Calling
 Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
 [3] used internally by the driver. Stacked on top of that is OP-TEE Message
 Protocol [4].
 
+On RISC-V the SMC interface is unchanged but its register arguments and
+return values are carried by the TEE_CALL service of the TEE service group
+of the RISC-V Platform Management Interface (RPMI) [7], sent to the M-mode
+firmware on an SBI Message Proxy (MPXY) channel [8]. The M-mode firmware
+switches the calling hart to the OP-TEE domain until OP-TEE responds, so a
+call behaves like an SMC: it runs on the calling hart and returns when
+OP-TEE completes, requests an RPC or yields on a foreign interrupt. The
+message layout is described in drivers/tee/optee/optee_rpmi.h.
+
 OP-TEE SMC interface provides the basic functions required by SMCCC and some
 additional functions specific for OP-TEE. The most interesting functions are:
 
@@ -164,3 +174,7 @@ References
     "TEE Client API Specification v1.0" and click download.
 
 [6] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
+
+[7] https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+[8] https://github.com/riscv-non-isa/riscv-sbi-doc/releases
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index 98c3ad083..6434204d8 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -2,7 +2,7 @@
 # Generic Trusted Execution Environment Configuration
 menuconfig TEE
 	tristate "Trusted Execution Environment support"
-	depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD
+	depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD || RISCV_SBI_MPXY_MBOX
 	select CRYPTO_LIB_SHA1
 	select DMA_SHARED_BUFFER
 	select GENERIC_ALLOCATOR
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index 50d2051f7..0b6cd91a8 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -2,13 +2,22 @@
 # OP-TEE Trusted Execution Environment Configuration
 config OPTEE
 	tristate "OP-TEE"
-	depends on HAVE_ARM_SMCCC
+	depends on HAVE_ARM_SMCCC || RISCV_SBI_MPXY_MBOX
+	depends on RISCV_SBI_MPXY_MBOX || !RISCV_SBI_MPXY_MBOX
 	depends on MMU
 	depends on RPMB || !RPMB
 	help
 	  This implements the OP-TEE Trusted Execution Environment (TEE)
 	  driver.
 
+config OPTEE_RPMI_CONDUIT
+	bool
+	depends on OPTEE && RISCV_SBI_MPXY_MBOX
+	default y
+	help
+	  Reach OP-TEE through the TEE service group of the RISC-V Platform
+	  Management Interface (RPMI) on an SBI Message Proxy (MPXY) channel.
+
 config OPTEE_INSECURE_LOAD_IMAGE
 	bool "Load OP-TEE image as firmware"
 	default n
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index ad7049c1c..4b5a868a9 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -9,6 +9,7 @@ optee-objs += supp.o
 optee-objs += device.o
 optee-objs += smc_abi.o
 optee-objs += ffa_abi.o
+optee-$(CONFIG_OPTEE_RPMI_CONDUIT) += rpmi_conduit.o
 
 # for tracing framework to find optee_trace.h
 CFLAGS_smc_abi.o := -I$(src)
diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
index aefe1e6f5..b90359988 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -424,6 +424,9 @@ static inline void reg_pair_from_64(u32 *reg0, u32 *reg1, u64 val)
 /* Registration of the ABIs */
 int optee_smc_abi_register(void);
 void optee_smc_abi_unregister(void);
+#if IS_ENABLED(CONFIG_OPTEE_RPMI_CONDUIT)
+optee_invoke_fn *optee_rpmi_conduit_init(struct device *dev);
+#endif
 int optee_ffa_abi_register(void);
 void optee_ffa_abi_unregister(void);
 
diff --git a/drivers/tee/optee/optee_rpmi.h b/drivers/tee/optee/optee_rpmi.h
new file mode 100644
index 000000000..89821255b
--- /dev/null
+++ b/drivers/tee/optee/optee_rpmi.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */
+/*
+ * Copyright 2026 NXP
+ */
+#ifndef OPTEE_RPMI_H
+#define OPTEE_RPMI_H
+
+#include <linux/types.h>
+#include <linux/uuid.h>
+
+/*
+ * This file defines how the OP-TEE SMC ABI (optee_smc.h) is carried by the
+ * TEE service group of the RISC-V Platform Management Interface (RPMI). It
+ * is kept in sync between secure world and the normal world driver.
+ *
+ * An invocation of the SMC ABI is a TEE_CALL service request sent to the
+ * RPMI TEE framework on an SBI MPXY channel where:
+ * - SENDER_ID identifies the REE endpoint and TARGET_ID the OP-TEE
+ *   endpoint, both assigned by the framework,
+ * - SERVICE is OPTEE_RPMI_SERVICE_UUID in RFC 4122 byte order,
+ * - SERVICE_DATA carries the register arguments a0-a7 of the SMC ABI as
+ *   little-endian 64-bit words.
+ *
+ * The SERVICE_RSP of the TEE_CALL response carries the return values a0-a3
+ * of the SMC ABI as little-endian 64-bit words. The STATUS of the response
+ * is set by the framework and is RPMI_SUCCESS whenever OP-TEE was reached,
+ * errors reported by OP-TEE itself are returned in a0 as usual.
+ */
+
+/*
+ * UUID identifying the OP-TEE API as a TEE_CALL service, the same value
+ * as returned by OPTEE_SMC_CALLS_UID (OPTEE_MSG_UID_0..3).
+ */
+#define OPTEE_RPMI_SERVICE_UUID \
+	UUID_INIT(0x384fb3e0, 0xe7f8, 0x11e3, \
+		  0xaf, 0x63, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x1b)
+
+#define OPTEE_RPMI_CALL_NUM_ARGS	8
+#define OPTEE_RPMI_CALL_NUM_RETS	4
+
+/**
+ * struct optee_rpmi_call_req - TEE_CALL request data invoking the SMC ABI
+ * @sender_id:	SENDER_ID, endpoint identifier of the REE
+ * @target_id:	TARGET_ID, endpoint identifier of OP-TEE
+ * @service:	SERVICE, bytes of OPTEE_RPMI_SERVICE_UUID
+ * @data_len:	SERVICE_DATA_LEN, sizeof(@args)
+ * @args:	SERVICE_DATA, register arguments a0-a7 of the SMC ABI
+ */
+struct optee_rpmi_call_req {
+	__le32 sender_id;
+	__le32 target_id;
+	u8 service[UUID_SIZE];
+	__le32 data_len;
+	__le64 args[OPTEE_RPMI_CALL_NUM_ARGS];
+} __packed;
+
+/**
+ * struct optee_rpmi_call_rsp - TEE_CALL response data of the SMC ABI
+ * @status:	STATUS, RPMI error code set by the framework
+ * @rsp_len:	SERVICE_RSP_LEN, sizeof(@rets)
+ * @rets:	SERVICE_RSP, return values a0-a3 of the SMC ABI
+ */
+struct optee_rpmi_call_rsp {
+	__le32 status;
+	__le32 rsp_len;
+	__le64 rets[OPTEE_RPMI_CALL_NUM_RETS];
+} __packed;
+
+#endif /*OPTEE_RPMI_H*/
diff --git a/drivers/tee/optee/rpmi_conduit.c b/drivers/tee/optee/rpmi_conduit.c
new file mode 100644
index 000000000..bc4ff975c
--- /dev/null
+++ b/drivers/tee/optee/rpmi_conduit.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 NXP
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/arm-smccc.h>
+#include <linux/build_bug.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/mailbox_client.h>
+#include <linux/mailbox/riscv-rpmi-message.h>
+#include <linux/mailbox/riscv-sbi-mpxy-mbox.h>
+#include <linux/printk.h>
+#include <linux/property.h>
+#include <linux/types.h>
+#include <linux/uuid.h>
+#include "optee_private.h"
+#include "optee_rpmi.h"
+#include "optee_smc.h"
+
+/*
+ * This file implements the conduit carrying the SMC ABI over the TEE
+ * service group of the RISC-V Platform Management Interface (RPMI). Each
+ * invocation of the ABI is a TEE_CALL request sent on an SBI MPXY channel
+ * with the message layout described in optee_rpmi.h.
+ *
+ * The TEE_CALL request is not sent with mbox_send_message(): the target
+ * TEE executes on the calling hart until it responds, so the transfer is
+ * done with riscv_sbi_mpxy_mbox_call() which bypasses the mailbox core
+ * queue and channel lock. Calls from different harts run concurrently,
+ * exactly like SMCs do.
+ */
+
+static_assert(sizeof(struct optee_rpmi_call_req) == 92);
+static_assert(sizeof(struct optee_rpmi_call_rsp) == 40);
+
+/**
+ * struct optee_rpmi_conduit - RPMI TEE service group conduit
+ * @cl:		mailbox client owning @chan
+ * @chan:	SBI MPXY channel implementing the RPMI TEE service group
+ * @sender_id:	endpoint identifier of the REE
+ * @target_id:	endpoint identifier of OP-TEE
+ */
+struct optee_rpmi_conduit {
+	struct mbox_client cl;
+	struct mbox_chan *chan;
+	u32 sender_id;
+	u32 target_id;
+};
+
+/* Like the rest of the SMC ABI, at most a single OP-TEE instance is supported */
+static struct optee_rpmi_conduit optee_rpmi;
+
+static const uuid_t optee_rpmi_service_uuid = OPTEE_RPMI_SERVICE_UUID;
+
+static void optee_rpmi_invoke_fn(unsigned long a0, unsigned long a1,
+				 unsigned long a2, unsigned long a3,
+				 unsigned long a4, unsigned long a5,
+				 unsigned long a6, unsigned long a7,
+				 struct arm_smccc_res *res)
+{
+	struct optee_rpmi_call_req req = {
+		.sender_id = cpu_to_le32(optee_rpmi.sender_id),
+		.target_id = cpu_to_le32(optee_rpmi.target_id),
+		.data_len = cpu_to_le32(sizeof(req.args)),
+		.args = {
+			cpu_to_le64(a0), cpu_to_le64(a1), cpu_to_le64(a2),
+			cpu_to_le64(a3), cpu_to_le64(a4), cpu_to_le64(a5),
+			cpu_to_le64(a6), cpu_to_le64(a7),
+		},
+	};
+	struct optee_rpmi_call_rsp rsp = {};
+	struct rpmi_mbox_message msg;
+	int rc;
+
+	export_uuid(req.service, &optee_rpmi_service_uuid);
+
+	rpmi_mbox_init_send_with_response(&msg, RPMI_TEE_SRV_CALL,
+					  &req, sizeof(req), &rsp, sizeof(rsp));
+	rc = riscv_sbi_mpxy_mbox_call(optee_rpmi.chan, &msg);
+	if (!rc) {
+		if (msg.data.out_response_len < sizeof(rsp.status))
+			rc = -EIO;
+		else
+			rc = rpmi_to_linux_error((s32)le32_to_cpu(rsp.status));
+	}
+	if (!rc && (msg.data.out_response_len < sizeof(rsp) ||
+		    le32_to_cpu(rsp.rsp_len) != sizeof(rsp.rets)))
+		rc = -EIO;
+
+	if (rc) {
+		/*
+		 * The SBI implementation or the RPMI TEE framework failed to
+		 * deliver the call, OP-TEE was not reached. Report it in a0
+		 * as the SMC ABI does for a call that could not be handled.
+		 */
+		if (rc != -EBUSY)
+			pr_warn_ratelimited("TEE_CALL of 0x%lx failed: %d\n",
+					    a0, rc);
+		res->a0 = rc == -EBUSY ? OPTEE_SMC_RETURN_EBUSY :
+					 OPTEE_SMC_RETURN_ENOTAVAIL;
+		res->a1 = 0;
+		res->a2 = 0;
+		res->a3 = 0;
+		return;
+	}
+
+	res->a0 = le64_to_cpu(rsp.rets[0]);
+	res->a1 = le64_to_cpu(rsp.rets[1]);
+	res->a2 = le64_to_cpu(rsp.rets[2]);
+	res->a3 = le64_to_cpu(rsp.rets[3]);
+}
+
+static void optee_rpmi_conduit_release(void *data)
+{
+	struct optee_rpmi_conduit *conduit = data;
+
+	mbox_free_channel(conduit->chan);
+	conduit->chan = NULL;
+}
+
+static int optee_rpmi_get_attr(struct optee_rpmi_conduit *conduit,
+			       enum rpmi_mbox_attribute_id id, u32 *value)
+{
+	struct rpmi_mbox_message msg;
+	int rc;
+
+	rpmi_mbox_init_get_attribute(&msg, id);
+	rc = rpmi_mbox_send_message(conduit->chan, &msg);
+	if (rc)
+		return rc;
+
+	*value = msg.attr.value;
+	return 0;
+}
+
+optee_invoke_fn *optee_rpmi_conduit_init(struct device *dev)
+{
+	struct optee_rpmi_conduit *conduit = &optee_rpmi;
+	u32 value;
+	int rc;
+
+	if (conduit->chan)
+		return ERR_PTR(-EBUSY);
+
+	rc = device_property_read_u32(dev, "riscv,rpmi-tee-sender-id",
+				      &conduit->sender_id);
+	if (rc)
+		return ERR_PTR(dev_err_probe(dev, rc,
+					     "missing \"riscv,rpmi-tee-sender-id\" property\n"));
+
+	rc = device_property_read_u32(dev, "riscv,rpmi-tee-target-id",
+				      &conduit->target_id);
+	if (rc)
+		return ERR_PTR(dev_err_probe(dev, rc,
+					     "missing \"riscv,rpmi-tee-target-id\" property\n"));
+
+	conduit->cl.dev = dev;
+	conduit->cl.tx_block = false;
+	conduit->cl.knows_txdone = true;
+	conduit->chan = mbox_request_channel(&conduit->cl, 0);
+	if (IS_ERR(conduit->chan)) {
+		rc = PTR_ERR(conduit->chan);
+		conduit->chan = NULL;
+		return ERR_PTR(dev_err_probe(dev, rc,
+					     "failed to request MPXY channel\n"));
+	}
+
+	rc = devm_add_action_or_reset(dev, optee_rpmi_conduit_release, conduit);
+	if (rc)
+		return ERR_PTR(rc);
+
+	rc = optee_rpmi_get_attr(conduit, RPMI_MBOX_ATTR_SERVICEGROUP_ID,
+				 &value);
+	if (rc)
+		return ERR_PTR(dev_err_probe(dev, rc,
+					     "failed to read RPMI service group ID\n"));
+	if (value != RPMI_SRVGRP_TEE) {
+		dev_err(dev, "MPXY channel implements RPMI service group 0x%x, not TEE\n",
+			value);
+		return ERR_PTR(-ENODEV);
+	}
+
+	rc = optee_rpmi_get_attr(conduit, RPMI_MBOX_ATTR_MAX_MSG_DATA_SIZE,
+				 &value);
+	if (rc)
+		return ERR_PTR(dev_err_probe(dev, rc,
+					     "failed to read RPMI max message size\n"));
+	if (value < sizeof(struct optee_rpmi_call_req) ||
+	    value < sizeof(struct optee_rpmi_call_rsp)) {
+		dev_err(dev, "MPXY channel message size %u is too small\n",
+			value);
+		return ERR_PTR(-EINVAL);
+	}
+
+	pr_info("using RPMI TEE service group, endpoints %u -> %u\n",
+		conduit->sender_id, conduit->target_id);
+
+	return optee_rpmi_invoke_fn;
+}
diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
index 221939f72..3d5d54526 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -1522,6 +1522,12 @@ static const struct optee_smc_conduit optee_smccc_conduit = {
 };
 #endif
 
+#if IS_ENABLED(CONFIG_OPTEE_RPMI_CONDUIT)
+static const struct optee_smc_conduit optee_rpmi_conduit = {
+	.init = optee_rpmi_conduit_init,
+};
+#endif
+
 /* optee_remove - Device Removal Routine
  * @pdev: platform device information struct
  *
@@ -1982,6 +1988,9 @@ static int optee_probe(struct platform_device *pdev)
 static const struct of_device_id optee_dt_match[] = {
 #ifdef CONFIG_HAVE_ARM_SMCCC
 	{ .compatible = "linaro,optee-tz", .data = &optee_smccc_conduit },
+#endif
+#if IS_ENABLED(CONFIG_OPTEE_RPMI_CONDUIT)
+	{ .compatible = "linaro,optee-rpmi", .data = &optee_rpmi_conduit },
 #endif
 	{},
 };
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv