[PATCH v2] tee: optee: prepare the driver for RISC-V

Tue Sep 22 06:06:53 PDT 2026

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.nxp.com/

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 at oss.qualcomm.com>
Sent: Tuesday, September 22, 2026 9:53 AM
To: Marouene Boubakri (OSS) <marouene.boubakri at oss.nxp.com>
Cc: Jens Wiklander <jenswi at kernel.org>; Sumit Garg <sumit.garg at kernel.org>; Paul Walmsley <pjw at kernel.org>; Palmer Dabbelt <palmer at dabbelt.com>; Albert Ou <aou at eecs.berkeley.edu>; Alexandre Ghiti <alex at ghiti.fr>; linux-kernel at vger.kernel.org; op-tee at lists.trustedfirmware.org; linux-riscv at lists.infradead.org; Amirreza Zarrabi <amirreza.zarrabi at oss.qualcomm.com>
Subject: Re: [PATCH v2] tee: optee: prepare the driver for RISC-V

[You don't often get email from jens.wiklander at 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 at oss.nxp.com> wrote:
>
> From: Marouene Boubakri <marouene.boubakri at 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#explicit-in-reply-to-headers

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
>