Both the OP-TEE core and some OP-TEE drivers use an if/else expression
to check a boolean which can instead be returned directly. Implement
this change.
---
Rouven Czerwinski (3):
optee: simplify OP-TEE context match
hwrng: optee - simplify OP-TEE context match
rtc: optee: simplify OP-TEE context match
drivers/char/hw_random/optee-rng.c | 5 +----
drivers/rtc/rtc-optee.c | 5 +----
drivers/tee/optee/device.c | 5 +----
3 files changed, 3 insertions(+), 12 deletions(-)
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260126-optee-simplify-context-match-d5b3467bfacc
Best regards,
--
Rouven Czerwinski <rouven.czerwinski(a)linaro.org>
Main updates from version V19[3]:
--------------------------------
The devicetree is now structured as follows:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
#address-cells = <1>;
#size-cells = <0>;
rproc-service@0 {
compatible = "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
m4: m4@0 {
compatible = "st,stm32mp15-m4-tee";
reg = <0>;
mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
mbox-names = "vq0", "vq1", "shutdown";
memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>,
<&vdev0vring1>, <&vdev0buffer>, <&retram>;
interrupt-parent = <&exti>;
interrupts = <68 1>;
status = "okay";
};
};
};
};
As a consequence, this version:
- Introduces a new stm32_rproc_tee.c remoteproc driver.
Instead of further complicating the existing stm32_rproc.c driver, a
dedicated TEE-based driver is added. Both drivers are intended to also
support the STM32MP2x Cortex-M33 remote processor in a next step.
- Reworks the bindings:
- Drop the st,stm32-rproc.yaml updates that were introduced in previous
revisions.
- Add remoteproc-tee.yaml for the
"rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" compatible.
- Add st,stm32-rproc-tee.yaml for the "st,stm32mp15-m4-tee" compatible.
- Reworks the probing sequence:
The m4@0 device is now probed by the remoteproc-tee driver, which itself
is instantiated by the TEE (OP-TEE) bus.
Main updates from version V18[2]:
--------------------------------
- rework documentation for the release_fw ops
- rework function documentation in remoteproc_tee.c
- replace spinlock by mutex and generalize usage in remoteproc_tee.c
Main updates from version V17[1]:
--------------------------------
- Fix: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h>
is missing
More details are available in each patch commit message.
[1] https://lore.kernel.org/linux-remoteproc/20250613091650.2337411-1-arnaud.po…
[2] https://lore.kernel.org/linux-remoteproc/20250616075530.4106090-1-arnaud.po…
[3] https://lore.kernel.org/linux-devicetree/20250625094028.758016-1-arnaud.pou…
Tested-on:
---------
commit 7d0a66e4bb90 ("Linux 6.18")
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact. The user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (6):
dt-bindings: firmware: Add TEE remoteproc service binding
dt-bindings: remoteproc: Add STM32 TEE-controlled rproc binding
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Introduce optional release_fw operation
remoteproc: Add TEE support
remoteproc: stm32: Add TEE-controlled STM32 driver
.../arm/firmware/linaro,optee-tz.yaml | 6 +
.../bindings/remoteproc/remoteproc-tee.yaml | 47 ++
.../remoteproc/st,stm32-rproc-tee.yaml | 100 +++
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 3 +-
drivers/remoteproc/remoteproc_core.c | 52 ++
drivers/remoteproc/remoteproc_internal.h | 6 +
drivers/remoteproc/remoteproc_tee.c | 771 ++++++++++++++++++
drivers/remoteproc/stm32_rproc_tee.c | 526 ++++++++++++
include/linux/remoteproc.h | 6 +
include/linux/remoteproc_tee.h | 89 ++
11 files changed, 1615 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/remoteproc-tee.yaml
create mode 100644 Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
create mode 100644 drivers/remoteproc/remoteproc_tee.c
create mode 100644 drivers/remoteproc/stm32_rproc_tee.c
create mode 100644 include/linux/remoteproc_tee.h
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
--
2.43.0
When we do SCMI on OP-TEE, the in buffer and out buffer are the same buffer.
I added some debug code to confirm this:
diff --git a/module/msg_smt/src/mod_msg_smt.c b/module/msg_smt/src/mod_msg_smt.c
index 853fe66b8d27..1e92dcd49c29 100644
--- a/module/msg_smt/src/mod_msg_smt.c
+++ b/module/msg_smt/src/mod_msg_smt.c
@@ -175,6 +175,11 @@ static int smt_write_payload(fwk_id_t channel_id,
if (!channel_ctx->locked)
return FWK_E_ACCESS;
+ FWK_LOG_ERR("OUT=%p IN=%p %s",
+ channel_ctx->out->payload,
+ channel_ctx->in->payload,
+ (channel_ctx->out->payload == channel_ctx->in->payload) ? "equal" : "different");
+
memcpy(((uint8_t*)channel_ctx->out->payload) + offset, payload, size);
return FWK_SUCCESS;
And it's true:
[ 0.000000] OUT=0x9c401004 IN=0x9c401004 equal
This normally isn't a problem because we read a few inputs at the
start of the function and then write out the result to the output at the
end.
But in the scmi_pin_control_list_associations_handler() it does a loop
where each iteration reads from parameters->index which is input and
writes to the output with scmi_pin_control_ctx.scmi_api->write_payload()
and that corrupts the input data.
Copying the input buffer to a the stack the issue for me, but I feel
like it is a hack. It would be better to use separate buffers for
input and output.
I think this comes from:
https://github.com/OP-TEE/optee_os/blob/master/core/kernel/pseudo_ta.c#L93
I added a print statement to there as well:
diff --git a/core/kernel/pseudo_ta.c b/core/kernel/pseudo_ta.c
index 587faa41a770..426870fb934c 100644
--- a/core/kernel/pseudo_ta.c
+++ b/core/kernel/pseudo_ta.c
@@ -90,6 +90,7 @@ static TEE_Result copy_in_param(struct ts_session *s __maybe_unused,
va = NULL;
}
+ EMSG("n=%lu va=%p", n, va);
tee_param[n].memref.buffer = va;
tee_param[n].memref.size = mem->size;
break;
E/TC:? 0 copy_in_param:93 n=1 va=0x9c401000
E/TC:? 0 copy_in_param:93 n=2 va=0x9c401000
Here is the patch to save "parameters" to a different buffer.
---
.../scmi_pin_control/src/mod_scmi_pin_control.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/module/scmi_pin_control/src/mod_scmi_pin_control.c b/module/scmi_pin_control/src/mod_scmi_pin_control.c
index a0b90dd2b73f..54e613b70f69 100644
--- a/module/scmi_pin_control/src/mod_scmi_pin_control.c
+++ b/module/scmi_pin_control/src/mod_scmi_pin_control.c
@@ -344,7 +344,7 @@ static int scmi_pin_control_list_associations_handler(
fwk_id_t service_id,
const uint32_t *payload)
{
- const struct scmi_pin_control_list_associations_a2p *parameters;
+ const struct scmi_pin_control_list_associations_a2p parameters;
uint32_t payload_size;
uint16_t identifiers_count;
uint16_t total_number_of_associations;
@@ -362,8 +362,9 @@ static int scmi_pin_control_list_associations_handler(
payload_size = (uint32_t)sizeof(return_values);
parameters = (const struct scmi_pin_control_list_associations_a2p *)payload;
+ memcpy(¶meters, payload, sizeof(parameters));
- status = map_identifier(parameters->identifier, &mapped_identifier);
+ status = map_identifier(parameters.identifier, &mapped_identifier);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
@@ -371,7 +372,7 @@ static int scmi_pin_control_list_associations_handler(
}
status = scmi_pin_control_ctx.pinctrl_api->get_total_number_of_associations(
- mapped_identifier, parameters->flags, &total_number_of_associations);
+ mapped_identifier, parameters.flags, &total_number_of_associations);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
goto exit;
@@ -388,11 +389,11 @@ static int scmi_pin_control_list_associations_handler(
identifiers_count = (uint16_t)FWK_MIN(
buffer_allowed_identifiers,
- (uint16_t)(total_number_of_associations - parameters->index));
+ (uint16_t)(total_number_of_associations - parameters.index));
return_values.flags = identifiers_count;
return_values.flags |= SHIFT_LEFT_BY_POS(
- (total_number_of_associations - parameters->index - identifiers_count),
+ (total_number_of_associations - parameters.index - identifiers_count),
NUM_OF_REMAINING_ELEMENTS_POS);
for (identifier_index = 0; identifier_index < identifiers_count;
@@ -401,8 +402,8 @@ static int scmi_pin_control_list_associations_handler(
status = scmi_pin_control_ctx.pinctrl_api->get_list_associations(
mapped_identifier,
- parameters->flags,
- (parameters->index + identifier_index),
+ parameters.flags,
+ (parameters.index + identifier_index),
&object_id);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
--
2.51.0
All Qualcomm SoCs starting from SM8650 provide access to the Qualcomm
Trusted Execution Environment (QTEE) through the SMCInvoke interface,
implemented by the QCOMTEE driver. QTEE runs in the Secure World domain
on ARM64 CPUs and exposes secure services to Linux running in the Normal
World domain.
This change enables the QCOMTEE driver as a module to support
communication with QTEE.
QCOMTEE has been tested on a Qualcomm RB3Gen2 board by loading and
executing a Trusted Application via tests hosted at
github.com/qualcomm/minkipc.
Signed-off-by: Harshal Dev <harshal.dev(a)oss.qualcomm.com>
---
Changes in v4:
- Updated the commit message as per discussion to clarify the following:
- Why we are enabling QCOMTEE for all arm64 boards.
- From which Qualcomm SoC onwards the driver is applicable.
- What functionality the driver provides.
- How the functionality has been tested and on which board.
- Link to v3: https://lore.kernel.org/r/20251208-qcom_qcomtee_defconfig-v3-1-b50dcf8ab45e…
Changes in v3:
- Updated the commit message to reflect the supported Qualcomm platforms.
- Link to v2: https://lore.kernel.org/r/20251205-qcom_qcomtee_defconfig-v2-1-c92560b0346e…
Changes in v2:
- Updated CONFIG_QCOMTEE flag to 'm' since QCOMTEE can be built as a module.
- Link to v1: https://lore.kernel.org/r/20251202-qcom_qcomtee_defconfig-v1-1-11bfe40a8ea4…
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index cdb7d69e3b24..e952d24bef77 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1789,6 +1789,7 @@ CONFIG_FPGA_MGR_ZYNQMP_FPGA=m
CONFIG_FPGA_MGR_VERSAL_FPGA=m
CONFIG_TEE=y
CONFIG_OPTEE=y
+CONFIG_QCOMTEE=m
CONFIG_MUX_GPIO=m
CONFIG_MUX_MMIO=y
CONFIG_SLIMBUS=m
---
base-commit: 47b7b5e32bb7264b51b89186043e1ada4090b558
change-id: 20251202-qcom_qcomtee_defconfig-8dc0fed1411b
Best regards,
--
Harshal Dev <harshal.dev(a)oss.qualcomm.com>
Hi,
I've just rebased the linaro-swg/kernel optee branch on v6.18 from
v6.14. By rebasing, we eliminated a few workarounds on the optee
branch and gained FF-A version 1.2 support in the kernel.
Cheers,
Jens
Hello arm-soc maintainers,
Please pull these two patches adding a generic TEE revision sysfs
attribute and implement support for OP-TEE.
Thanks,
Jens
The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-sysfs-for-6.20
for you to fetch changes up to c19faf5a62315d5e0e65dde49b7b59e30330b9c2:
tee: optee: store OS revision for TEE core (2026-01-15 10:35:14 +0100)
----------------------------------------------------------------
TEE sysfs for 6.20
- Add an optional generic sysfs attribute for TEE revision
- Implement revision reporting for OP-TEE using both SMC and FF-A ABIs
----------------------------------------------------------------
Aristo Chen (2):
tee: add revision sysfs attribute
tee: optee: store OS revision for TEE core
Documentation/ABI/testing/sysfs-class-tee | 10 ++++++
drivers/tee/optee/core.c | 23 +++++++++++++
drivers/tee/optee/ffa_abi.c | 54 +++++++++++++++++++++++--------
drivers/tee/optee/optee_private.h | 19 +++++++++++
drivers/tee/optee/smc_abi.c | 15 +++++++--
drivers/tee/tee_core.c | 51 ++++++++++++++++++++++++++++-
include/linux/tee_core.h | 9 ++++++
7 files changed, 163 insertions(+), 18 deletions(-)