All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Xing Loong <xing.xl.loong@gmail.com>,
	Jens Wiklander <jens.wiklander@linaro.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	Sumit Garg <sumit.garg@kernel.org>,
	op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding
Date: Wed, 1 Jul 2026 16:05:05 +0200	[thread overview]
Message-ID: <70068ae8-ede1-41d2-899b-98ed11e19953@kernel.org> (raw)
In-Reply-To: <20260701132514.186953-3-xing.xl.loong@gmail.com>

On 01/07/2026 15:25, Xing Loong wrote:
> Add YAML devicetree binding for the MbedTEE Trusted Execution

Drop YAML, there is no such thing as YAML binding.

> Environment driver.

We don't take bindings for drivers but for hardware or firmware. Please
describe these instead.

> 
> The binding covers two platform configurations:
>   - ARM/AArch64 (TrustZone, SMC): two reserved-memory regions
>     (rpc-t2r-ring and rpc-t2r-shm) plus a GIC SPI edge interrupt
>     for TEE-to-REE notifications.
>   - RISC-V (IMSIC): three reserved-memory regions, adding
>     rpc-r2t-ring for REE-to-TEE command submissions; no interrupts
>     property (T2R notifications use IMSIC MSI allocated at runtime).
> 
> Signed-off-by: Xing Loong <xing.xl.loong@gmail.com>
> ---
>  .../bindings/firmware/mbedtee,rpc.yaml        | 221 ++++++++++++++++++
>  1 file changed, 221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> new file mode 100644
> index 0000000..08ae255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> @@ -0,0 +1,221 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/mbedtee,rpc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MbedTEE Trusted Execution Environment
> +
> +maintainers:
> +  - Xing Loong <xing.xl.loong@gmail.com>
> +
> +description: |
> +  MbedTEE is a Trusted Execution Environment for embedded systems.
> +  This binding describes the shared-memory regions used for RPC

Describe firmware, not the binding. It's redundant to say what the
binding is about, just say what is the hardware.

> +  communication between the Linux REE driver and MbedTEE OS.
> +
> +  The REE and TEE CPUs sharing the RPC memory must be in a
> +  hardware-coherent domain (same CPU cluster, coherent caches).
> +
> +  Two or three reserved-memory regions are required:
> +
> +    rpc-t2r-ring  ring buffer for TEE-to-REE notifications (all platforms)
> +    rpc-t2r-shm   shared memory for TEE-to-REE RPC payloads (all platforms)
> +    rpc-r2t-ring  ring buffer for REE-to-TEE command submissions (RISC-V only)
> +
> +  On ARM/AArch64 the transport uses SMC calls; TEE-to-REE
> +  notifications use a GIC SPI edge interrupt.
> +
> +  On RISC-V the TEE notifies the REE via IMSIC MSI; the REE submits
> +  commands via shared-memory rpc-r2t-ring that the TEE polls. No
> +  REE-to-TEE interrupt is used. No SBI ecall is involved.
> +
> +properties:
> +  $nodename:
> +    const: mbedtee

Drop, why would it be relevant?

> +
> +  compatible:
> +    const: mbedtee,rpc

Feels way too generic. First, Google results on mbedtee are basically
non-existing, so what sort of company is that?

Second, rpc is just not specific enough. Please carefully read writing
bindings doc.

> +
> +  interrupts:
> +    description:
> +      GIC interrupt used by the TEE to notify the REE of pending RPC
> +      responses (ARM/AArch64 only). Not present on RISC-V platforms which
> +      use IMSIC platform MSI interrupts allocated dynamically at runtime.

Please read writing bindings doc.

> +
> +  msi-parent:
> +    maxItems: 1
> +    description:
> +      IMSIC MSI controller used by the Linux driver to allocate the

Again drivers...

> +      TEE-to-REE notification interrupt on RISC-V platforms. Not present on
> +      ARM/AArch64 platforms, which use the interrupts property.
> +
> +  memory-region:
> +    minItems: 2
> +    maxItems: 3
> +    description:
> +      References to reserved-memory regions for REE<->TEE communication.
> +      Entries must match memory-region-names order.

Obvious. Please do not come with your own style of bindings.

> +
> +  memory-region-names:
> +    minItems: 2
> +    maxItems: 3

Why is this flexible?

> +    items:
> +      enum:
> +        - rpc-t2r-ring

rpc is redundant, drop

> +        - rpc-t2r-shm
> +        - rpc-r2t-ring
> +
> +required:
> +  - compatible
> +
> +allOf:
> +  - if:
> +      required:
> +        - interrupts
> +    then:
> +      required:
> +        - interrupts
> +        - memory-region
> +        - memory-region-names
> +      properties:
> +        msi-parent: false
> +        memory-region:
> +          minItems: 2
> +          maxItems: 2
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +    else:
> +      required:
> +        - msi-parent
> +        - memory-region
> +        - memory-region-names

So memory-region is always required?

> +      properties:
> +        memory-region:
> +          minItems: 3
> +          maxItems: 3
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +            - const: rpc-r2t-ring

Your top level schema said that. You only need minItems.

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    /* ARM TrustZone (SMC) */
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    / {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      gic: interrupt-controller@2f000000 {
> +        compatible = "arm,gic-v3";
> +        reg = <0 0x2f000000 0 0x10000>,
> +              <0 0x2f100000 0 0x200000>;
> +        interrupt-controller;
> +        #interrupt-cells = <3>;
> +      };
> +
> +      reserved-memory {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        ranges;
> +
> +        mbedtee_t2r_ring: rpc-t2r-ring@85f10000 {
> +          reg = <0 0x85f10000 0 0x20000>;
> +          no-map;
> +        };
> +
> +        mbedtee_t2r_shm: rpc-t2r-shm@85f30000 {
> +          reg = <0 0x85f30000 0 0x40000>;
> +          no-map;
> +        };
> +      };

None of the above is relevant, drop.


> +
> +      firmware {
> +        mbedtee {
> +          compatible = "mbedtee,rpc";
> +          interrupt-parent = <&gic>;
> +          interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
> +          memory-region = <&mbedtee_t2r_ring>, <&mbedtee_t2r_shm>;
> +          memory-region-names = "rpc-t2r-ring", "rpc-t2r-shm";
> +        };
> +      };
> +    };
> +


Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Xing Loong <xing.xl.loong@gmail.com>,
	Jens Wiklander <jens.wiklander@linaro.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	Sumit Garg <sumit.garg@kernel.org>,
	op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding
Date: Wed, 1 Jul 2026 16:05:05 +0200	[thread overview]
Message-ID: <70068ae8-ede1-41d2-899b-98ed11e19953@kernel.org> (raw)
In-Reply-To: <20260701132514.186953-3-xing.xl.loong@gmail.com>

On 01/07/2026 15:25, Xing Loong wrote:
> Add YAML devicetree binding for the MbedTEE Trusted Execution

Drop YAML, there is no such thing as YAML binding.

> Environment driver.

We don't take bindings for drivers but for hardware or firmware. Please
describe these instead.

> 
> The binding covers two platform configurations:
>   - ARM/AArch64 (TrustZone, SMC): two reserved-memory regions
>     (rpc-t2r-ring and rpc-t2r-shm) plus a GIC SPI edge interrupt
>     for TEE-to-REE notifications.
>   - RISC-V (IMSIC): three reserved-memory regions, adding
>     rpc-r2t-ring for REE-to-TEE command submissions; no interrupts
>     property (T2R notifications use IMSIC MSI allocated at runtime).
> 
> Signed-off-by: Xing Loong <xing.xl.loong@gmail.com>
> ---
>  .../bindings/firmware/mbedtee,rpc.yaml        | 221 ++++++++++++++++++
>  1 file changed, 221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> new file mode 100644
> index 0000000..08ae255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> @@ -0,0 +1,221 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/mbedtee,rpc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MbedTEE Trusted Execution Environment
> +
> +maintainers:
> +  - Xing Loong <xing.xl.loong@gmail.com>
> +
> +description: |
> +  MbedTEE is a Trusted Execution Environment for embedded systems.
> +  This binding describes the shared-memory regions used for RPC

Describe firmware, not the binding. It's redundant to say what the
binding is about, just say what is the hardware.

> +  communication between the Linux REE driver and MbedTEE OS.
> +
> +  The REE and TEE CPUs sharing the RPC memory must be in a
> +  hardware-coherent domain (same CPU cluster, coherent caches).
> +
> +  Two or three reserved-memory regions are required:
> +
> +    rpc-t2r-ring  ring buffer for TEE-to-REE notifications (all platforms)
> +    rpc-t2r-shm   shared memory for TEE-to-REE RPC payloads (all platforms)
> +    rpc-r2t-ring  ring buffer for REE-to-TEE command submissions (RISC-V only)
> +
> +  On ARM/AArch64 the transport uses SMC calls; TEE-to-REE
> +  notifications use a GIC SPI edge interrupt.
> +
> +  On RISC-V the TEE notifies the REE via IMSIC MSI; the REE submits
> +  commands via shared-memory rpc-r2t-ring that the TEE polls. No
> +  REE-to-TEE interrupt is used. No SBI ecall is involved.
> +
> +properties:
> +  $nodename:
> +    const: mbedtee

Drop, why would it be relevant?

> +
> +  compatible:
> +    const: mbedtee,rpc

Feels way too generic. First, Google results on mbedtee are basically
non-existing, so what sort of company is that?

Second, rpc is just not specific enough. Please carefully read writing
bindings doc.

> +
> +  interrupts:
> +    description:
> +      GIC interrupt used by the TEE to notify the REE of pending RPC
> +      responses (ARM/AArch64 only). Not present on RISC-V platforms which
> +      use IMSIC platform MSI interrupts allocated dynamically at runtime.

Please read writing bindings doc.

> +
> +  msi-parent:
> +    maxItems: 1
> +    description:
> +      IMSIC MSI controller used by the Linux driver to allocate the

Again drivers...

> +      TEE-to-REE notification interrupt on RISC-V platforms. Not present on
> +      ARM/AArch64 platforms, which use the interrupts property.
> +
> +  memory-region:
> +    minItems: 2
> +    maxItems: 3
> +    description:
> +      References to reserved-memory regions for REE<->TEE communication.
> +      Entries must match memory-region-names order.

Obvious. Please do not come with your own style of bindings.

> +
> +  memory-region-names:
> +    minItems: 2
> +    maxItems: 3

Why is this flexible?

> +    items:
> +      enum:
> +        - rpc-t2r-ring

rpc is redundant, drop

> +        - rpc-t2r-shm
> +        - rpc-r2t-ring
> +
> +required:
> +  - compatible
> +
> +allOf:
> +  - if:
> +      required:
> +        - interrupts
> +    then:
> +      required:
> +        - interrupts
> +        - memory-region
> +        - memory-region-names
> +      properties:
> +        msi-parent: false
> +        memory-region:
> +          minItems: 2
> +          maxItems: 2
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +    else:
> +      required:
> +        - msi-parent
> +        - memory-region
> +        - memory-region-names

So memory-region is always required?

> +      properties:
> +        memory-region:
> +          minItems: 3
> +          maxItems: 3
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +            - const: rpc-r2t-ring

Your top level schema said that. You only need minItems.

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    /* ARM TrustZone (SMC) */
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    / {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      gic: interrupt-controller@2f000000 {
> +        compatible = "arm,gic-v3";
> +        reg = <0 0x2f000000 0 0x10000>,
> +              <0 0x2f100000 0 0x200000>;
> +        interrupt-controller;
> +        #interrupt-cells = <3>;
> +      };
> +
> +      reserved-memory {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        ranges;
> +
> +        mbedtee_t2r_ring: rpc-t2r-ring@85f10000 {
> +          reg = <0 0x85f10000 0 0x20000>;
> +          no-map;
> +        };
> +
> +        mbedtee_t2r_shm: rpc-t2r-shm@85f30000 {
> +          reg = <0 0x85f30000 0 0x40000>;
> +          no-map;
> +        };
> +      };

None of the above is relevant, drop.


> +
> +      firmware {
> +        mbedtee {
> +          compatible = "mbedtee,rpc";
> +          interrupt-parent = <&gic>;
> +          interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
> +          memory-region = <&mbedtee_t2r_ring>, <&mbedtee_t2r_shm>;
> +          memory-region-names = "rpc-t2r-ring", "rpc-t2r-shm";
> +        };
> +      };
> +    };
> +


Best regards,
Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski via OP-TEE <op-tee@lists.trustedfirmware.org>
To: Xing Loong <xing.xl.loong@gmail.com>,
	Jens Wiklander <jens.wiklander@linaro.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	Sumit Garg <sumit.garg@kernel.org>,
	op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding
Date: Wed, 1 Jul 2026 16:05:05 +0200	[thread overview]
Message-ID: <70068ae8-ede1-41d2-899b-98ed11e19953@kernel.org> (raw)
In-Reply-To: <20260701132514.186953-3-xing.xl.loong@gmail.com>

On 01/07/2026 15:25, Xing Loong wrote:
> Add YAML devicetree binding for the MbedTEE Trusted Execution

Drop YAML, there is no such thing as YAML binding.

> Environment driver.

We don't take bindings for drivers but for hardware or firmware. Please
describe these instead.

> 
> The binding covers two platform configurations:
>   - ARM/AArch64 (TrustZone, SMC): two reserved-memory regions
>     (rpc-t2r-ring and rpc-t2r-shm) plus a GIC SPI edge interrupt
>     for TEE-to-REE notifications.
>   - RISC-V (IMSIC): three reserved-memory regions, adding
>     rpc-r2t-ring for REE-to-TEE command submissions; no interrupts
>     property (T2R notifications use IMSIC MSI allocated at runtime).
> 
> Signed-off-by: Xing Loong <xing.xl.loong@gmail.com>
> ---
>  .../bindings/firmware/mbedtee,rpc.yaml        | 221 ++++++++++++++++++
>  1 file changed, 221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> new file mode 100644
> index 0000000..08ae255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml
> @@ -0,0 +1,221 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/mbedtee,rpc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MbedTEE Trusted Execution Environment
> +
> +maintainers:
> +  - Xing Loong <xing.xl.loong@gmail.com>
> +
> +description: |
> +  MbedTEE is a Trusted Execution Environment for embedded systems.
> +  This binding describes the shared-memory regions used for RPC

Describe firmware, not the binding. It's redundant to say what the
binding is about, just say what is the hardware.

> +  communication between the Linux REE driver and MbedTEE OS.
> +
> +  The REE and TEE CPUs sharing the RPC memory must be in a
> +  hardware-coherent domain (same CPU cluster, coherent caches).
> +
> +  Two or three reserved-memory regions are required:
> +
> +    rpc-t2r-ring  ring buffer for TEE-to-REE notifications (all platforms)
> +    rpc-t2r-shm   shared memory for TEE-to-REE RPC payloads (all platforms)
> +    rpc-r2t-ring  ring buffer for REE-to-TEE command submissions (RISC-V only)
> +
> +  On ARM/AArch64 the transport uses SMC calls; TEE-to-REE
> +  notifications use a GIC SPI edge interrupt.
> +
> +  On RISC-V the TEE notifies the REE via IMSIC MSI; the REE submits
> +  commands via shared-memory rpc-r2t-ring that the TEE polls. No
> +  REE-to-TEE interrupt is used. No SBI ecall is involved.
> +
> +properties:
> +  $nodename:
> +    const: mbedtee

Drop, why would it be relevant?

> +
> +  compatible:
> +    const: mbedtee,rpc

Feels way too generic. First, Google results on mbedtee are basically
non-existing, so what sort of company is that?

Second, rpc is just not specific enough. Please carefully read writing
bindings doc.

> +
> +  interrupts:
> +    description:
> +      GIC interrupt used by the TEE to notify the REE of pending RPC
> +      responses (ARM/AArch64 only). Not present on RISC-V platforms which
> +      use IMSIC platform MSI interrupts allocated dynamically at runtime.

Please read writing bindings doc.

> +
> +  msi-parent:
> +    maxItems: 1
> +    description:
> +      IMSIC MSI controller used by the Linux driver to allocate the

Again drivers...

> +      TEE-to-REE notification interrupt on RISC-V platforms. Not present on
> +      ARM/AArch64 platforms, which use the interrupts property.
> +
> +  memory-region:
> +    minItems: 2
> +    maxItems: 3
> +    description:
> +      References to reserved-memory regions for REE<->TEE communication.
> +      Entries must match memory-region-names order.

Obvious. Please do not come with your own style of bindings.

> +
> +  memory-region-names:
> +    minItems: 2
> +    maxItems: 3

Why is this flexible?

> +    items:
> +      enum:
> +        - rpc-t2r-ring

rpc is redundant, drop

> +        - rpc-t2r-shm
> +        - rpc-r2t-ring
> +
> +required:
> +  - compatible
> +
> +allOf:
> +  - if:
> +      required:
> +        - interrupts
> +    then:
> +      required:
> +        - interrupts
> +        - memory-region
> +        - memory-region-names
> +      properties:
> +        msi-parent: false
> +        memory-region:
> +          minItems: 2
> +          maxItems: 2
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +    else:
> +      required:
> +        - msi-parent
> +        - memory-region
> +        - memory-region-names

So memory-region is always required?

> +      properties:
> +        memory-region:
> +          minItems: 3
> +          maxItems: 3
> +        memory-region-names:
> +          items:
> +            - const: rpc-t2r-ring
> +            - const: rpc-t2r-shm
> +            - const: rpc-r2t-ring

Your top level schema said that. You only need minItems.

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    /* ARM TrustZone (SMC) */
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    / {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      gic: interrupt-controller@2f000000 {
> +        compatible = "arm,gic-v3";
> +        reg = <0 0x2f000000 0 0x10000>,
> +              <0 0x2f100000 0 0x200000>;
> +        interrupt-controller;
> +        #interrupt-cells = <3>;
> +      };
> +
> +      reserved-memory {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        ranges;
> +
> +        mbedtee_t2r_ring: rpc-t2r-ring@85f10000 {
> +          reg = <0 0x85f10000 0 0x20000>;
> +          no-map;
> +        };
> +
> +        mbedtee_t2r_shm: rpc-t2r-shm@85f30000 {
> +          reg = <0 0x85f30000 0 0x40000>;
> +          no-map;
> +        };
> +      };

None of the above is relevant, drop.


> +
> +      firmware {
> +        mbedtee {
> +          compatible = "mbedtee,rpc";
> +          interrupt-parent = <&gic>;
> +          interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
> +          memory-region = <&mbedtee_t2r_ring>, <&mbedtee_t2r_shm>;
> +          memory-region-names = "rpc-t2r-ring", "rpc-t2r-shm";
> +        };
> +      };
> +    };
> +


Best regards,
Krzysztof

  parent reply	other threads:[~2026-07-01 14:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 13:25 [PATCH 0/3] tee: add MbedTEE driver Xing Loong
2026-07-01 13:25 ` Xing Loong
2026-07-01 13:25 ` [PATCH 1/3] dt-bindings: vendor-prefixes: add mbedtee Xing Loong
2026-07-01 13:25   ` Xing Loong
2026-07-01 13:25 ` [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding Xing Loong
2026-07-01 13:25   ` Xing Loong
2026-07-01 13:32   ` sashiko-bot
2026-07-01 14:05   ` Krzysztof Kozlowski [this message]
2026-07-01 14:05     ` Krzysztof Kozlowski via OP-TEE
2026-07-01 14:05     ` Krzysztof Kozlowski
2026-07-03  7:16     ` Xing Loong
2026-07-03  7:16       ` Xing Loong
2026-07-01 16:39   ` Rob Herring (Arm) via OP-TEE
2026-07-01 16:39     ` Rob Herring (Arm)
2026-07-01 16:39     ` Rob Herring (Arm)
2026-07-01 13:25 ` [PATCH 3/3] tee: add MbedTEE driver Xing Loong
2026-07-01 13:25   ` Xing Loong
2026-07-01 13:42   ` sashiko-bot
2026-07-02 15:11 ` [PATCH v2 0/3] " Xing Loong
2026-07-02 15:11   ` Xing Loong
2026-07-02 15:11   ` [PATCH v2 1/3] dt-bindings: vendor-prefixes: add mbedtee Xing Loong
2026-07-02 15:11     ` Xing Loong
2026-07-02 15:11   ` [PATCH v2 2/3] dt-bindings: firmware: add mbedtee,tee binding Xing Loong
2026-07-02 15:11     ` Xing Loong
2026-07-02 15:21     ` sashiko-bot
2026-07-02 15:27     ` Krzysztof Kozlowski
2026-07-02 15:27       ` Krzysztof Kozlowski
2026-07-02 15:27       ` Krzysztof Kozlowski via OP-TEE
2026-07-02 15:11   ` [PATCH v2 3/3] tee: add MbedTEE driver Xing Loong
2026-07-02 15:11     ` Xing Loong
2026-07-02 15:32     ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70068ae8-ede1-41d2-899b-98ed11e19953@kernel.org \
    --to=krzk@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jens.wiklander@linaro.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=robh@kernel.org \
    --cc=sumit.garg@kernel.org \
    --cc=xing.xl.loong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.