Re: [PATCH RFC 5/5] dt-bindings: tee: add RISC-V RPMI TEE transport

[Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>]

Hi Anup,

On 9/16/2026 8:12 PM, Anup Patel wrote:
> On Sat, Sep 12, 2026 at 3:45 PM Amirreza Zarrabi
> <amirreza.zarrabi@oss.qualcomm.com> wrote:
>>
>> Add a device-tree binding for the OP-TEE RISC-V transport using the RPMI
>> TEE service group over SBI MPXY.
>>
>> Describe one mailbox channel per hart and an optional interrupt used as
>> the availability doorbell for asynchronous notifications.
>>
>> Add the binding to the existing OP-TEE MAINTAINERS entry.
>>
>> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
>> ---
>>  .../bindings/tee/riscv,rpmi-mpxy-tee.yaml          | 65 ++++++++++++++++++++++
>>  MAINTAINERS                                        |  1 +
>>  2 files changed, 66 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/tee/riscv,rpmi-mpxy-tee.yaml b/Documentation/devicetree/bindings/tee/riscv,rpmi-mpxy-tee.yaml
>> new file mode 100644
>> index 000000000000..8f6ff313fd42
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/tee/riscv,rpmi-mpxy-tee.yaml
>> @@ -0,0 +1,65 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/tee/riscv,rpmi-mpxy-tee.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: RISC-V RPMI TEE service group based message proxy
>> +
>> +maintainers:
>> +  - Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
>> +
>> +description: |
>> +  The RISC-V Platform Management Interface (RPMI) [1] defines a messaging
>> +  protocol which is modular and extensible. The supervisor software can
>> +  send/receive RPMI messages via the SBI MPXY extension [2] or some dedicated
>> +  supervisor-mode RPMI transport.
>> +
>> +  The RPMI specification [1] defines a TEE service group which is the RISC-V
>> +  analog of Arm FF-A: OP-TEE and the rich execution environment (REE, i.e.
>> +  Linux) are peer endpoints and the RPMI framework (machine mode firmware)
>> +  mediates every message. Entering OP-TEE on a hart runs it on that hart until
>> +  it responds, so the SBI implementation provides one SBI MPXY channel per
>> +  hart; all of them are listed, in hart order, on a single node.
>> +
>> +  ===========================================
>> +  References
>> +  ===========================================
>> +
>> +  [1] RISC-V Platform Management Interface (RPMI) v1.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:
>> +  compatible:
>> +    const: riscv,rpmi-mpxy-tee
>> +
>> +  mboxes:
>> +    minItems: 1
>> +    description:
>> +      One SBI MPXY channel implementing the RPMI TEE service group per hart,
>> +      listed in the same order as the CPU nodes.
> 
> I am not sure why you need separate MPXY channel per hart. The MPXY shared
> memory is already per-hart whereas the MPXY channel will be doman specific
> for TEE.

True. My reasoning was that TEE_CALL, as I understand it, is expected to execute on
the same hart that issued it. Given that, the mailbox core holds the per-channel spinlock
across the call to `send_data()`, while the underlying `sbi_ecall()` is synchronous
and does not return until the TEE call completes.

So, if two harts shared the same channel, a hart executing a long-running TEE operation
would hold that channel's lock for the duration of the call, and another hart
trying to enqueue on the same channel would spin waiting for it.

Using per-hart channels avoids that cross-hart contention. I agree that this may
not be the right layer in which to address the issue. I did not pull it to the discussion in to this RFC.
I'm happy to use single channel for now and follow up on it separately if useful.

> 
> Also, for this binding refererring to only mailbox channel is
> sufficient. The underlying
> mechanism to send RPMI messages is abstracted away by the mailbox controller
> driver.

Ack.

Best regards,
Amir

> 
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +    description:
>> +      Availability doorbell raised by OP-TEE to signal asynchronous
>> +      notifications over the RPMI TEE signal bus. Optional; when absent
>> +      asynchronous notification is disabled.
>> +
>> +required:
>> +  - compatible
>> +  - mboxes
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    tee {
>> +        compatible = "riscv,rpmi-mpxy-tee";
> 
> This must be "riscv,rpmi-tee" based on above comments.
> 
>> +        mboxes = <&mpxy_mbox 0x10 0x0>, <&mpxy_mbox 0x11 0x0>;
> 
> Like mentioned above, only one mailbox channel is sufficient.
> 
>> +    };
>> +...
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 207a6e2db70c..7d0e550085b2 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -20577,6 +20577,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/tee/riscv,rpmi-mpxy-tee.yaml
>>  F:     drivers/tee/optee/
>>
>>  OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
>>
>> --
>> 2.34.1
>>
> 
> Regards,
> Anup