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

[Jens Wiklander]

Hi,

On Tue, Sep 15, 2026 at 3:48 AM <marouene.boubakri@xxxxxxxxxxx> wrote:
>
> From: Marouene Boubakri <marouene.boubakri@xxxxxxxxxxx>
>
> 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
>