Hi,
On Tue, Sep 15, 2026 at 3:48 AM marouene.boubakri@oss.nxp.com wrote:
From: Marouene Boubakri marouene.boubakri@oss.nxp.com
The OP-TEE driver reaches OP-TEE through the SMC ABI or the FF-A ABI, both specific to Arm, and the TEE subsystem and the OP-TEE driver depend on HAVE_ARM_SMCCC. On RISC-V there is no SMC instruction: OP-TEE runs in a domain isolated by the M-mode firmware and is reached through the RISC-V Platform Management Interface (RPMI), carried on an SBI Message Proxy (MPXY) channel, for which Linux already has a mailbox driver.
This series only puts the build plumbing in place for a third ABI next to the SMC and FF-A ones:
- patch 1 builds the Arm-specific code of the driver only on Arm: smc_abi.c when HAVE_ARM_SMCCC is set and ffa_abi.c when ARM_FFA_TRANSPORT is enabled, with stubs for their registration otherwise. The SMCCC header, the SMC and FF-A specific types and the SMC RPC register parameters in optee_private.h are kept under the same conditions, so that nothing Arm-specific is left in the common part of the driver;
This makes sense. Thanks for the cleanup. I'm reviewing the patch.
patch 2 adds an RPMI ABI placeholder: an OPTEE_RPMI_ABI option built when the MPXY mailbox driver is enabled, rpmi_abi.c and its registration from the driver core. The transport is not implemented, so the registration fails with -EOPNOTSUPP;
patch 3 lets the TEE subsystem and the OP-TEE driver be enabled on RISC-V, and teaches the memory type check of the driver about the RISC-V page attributes, without which the driver does not build there. It is kept separate as it changes the dependencies of the subsystem-wide TEE menu.
I don't think we need any empty shells. I'd rather wait until we have something. So please drop patches 2 and 3.
There is no functional change. On Arm, OPTEE still depends on HAVE_ARM_SMCCC and the SMC and FF-A ABIs are built whenever they can be registered. On RISC-V the driver builds without any Arm-specific code but no ABI registers, so it does not load. The RPMI transport will be implemented on top of this in a separate series.
Testing: Tested with the configurations below, riscv64 and arm64, built-in and as modules, and W=1 at every step of the series.
- riscv64, minimal config + CONFIG_TEE=y CONFIG_OPTEE=y
- riscv64, minimal config + CONFIG_TEE=m CONFIG_OPTEE=m
- arm64, minimal config + CONFIG_OPTEE=y CONFIG_ARM_FFA_TRANSPORT=y
- arm64, minimal config + CONFIG_OPTEE=y CONFIG_ARM_FFA_TRANSPORT=m
- arm64, minimal config + CONFIG_OPTEE=y CONFIG_ARM_FFA_TRANSPORT=n
Since this is a V2, I'm missing what has changed from the V1. The patch subject prefix is also incorrect (the V1 was correct) and confuses the b4 tool. When you post a new version of a patch set, please don't add an explicit In-Reply-To header in the cover letter to the previous patch set https://www.kernel.org/doc/html/v4.19/process/submitting-patches.html#explic...
Cheers, Jens
Marouene Boubakri (3): tee: optee: build the Arm-specific code only on Arm tee: optee: add an RPMI ABI placeholder tee: optee: allow enabling the driver on RISC-V
drivers/tee/Kconfig | 2 +- drivers/tee/optee/Kconfig | 10 +++++- drivers/tee/optee/Makefile | 5 +-- drivers/tee/optee/call.c | 8 +++++ drivers/tee/optee/core.c | 8 +++-- drivers/tee/optee/notif.c | 1 - drivers/tee/optee/optee_private.h | 52 ++++++++++++++++++++++++++++++- drivers/tee/optee/rpmi_abi.c | 23 ++++++++++++++ 8 files changed, 101 insertions(+), 8 deletions(-) create mode 100644 drivers/tee/optee/rpmi_abi.c
-- 2.34.1