Hi Jens,
NXP Confidential On Tue, Sep 22, 2026 at 9:53 AM Jens Wiklander <...> wrote:
I don't think we need any empty shells. I'd rather wait until we have something. So please drop patches 2 and 3.
Dropped. v3 is patch 1 alone, posted as a new thread: https://lore.kernel.org/all/20260922131735.524635-1-marouene.boubakri@oss.nx...
The RISC-V enablement will come with the transport itself.
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
v2 had no code change, it only replaced the testing placeholder left in the v1 cover letter. The changelog is below the --- line in v3.
v3 also fixes a link failure in patch 1 with OPTEE=y and ARM_FFA_TRANSPORT=m: kbuild leaves the optee-m objects out of a built-in optee.o, while optee_private.h still declared optee_ffa_abi_register() under IS_ENABLED(). The FF-A parts are now keyed on IS_REACHABLE(), which keeps the current fallback to no FF-A in that configuration, and the then redundant IS_REACHABLE() checks in ffa_abi.c are dropped.
Please review v3 instead of v2.
Thanks, Marouene
-----Original Message----- From: Jens Wiklander jens.wiklander@oss.qualcomm.com Sent: Tuesday, September 22, 2026 9:53 AM To: Marouene Boubakri (OSS) marouene.boubakri@oss.nxp.com Cc: Jens Wiklander jenswi@kernel.org; Sumit Garg sumit.garg@kernel.org; Paul Walmsley pjw@kernel.org; Palmer Dabbelt palmer@dabbelt.com; Albert Ou aou@eecs.berkeley.edu; Alexandre Ghiti alex@ghiti.fr; linux-kernel@vger.kernel.org; op-tee@lists.trustedfirmware.org; linux-riscv@lists.infradead.org; Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com Subject: Re: [PATCH v2] tee: optee: prepare the driver for RISC-V
[You don't often get email from jens.wiklander@oss.qualcomm.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
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