Hi,
On 7/22/26 14:33, Peter Robinson wrote:
On Wed, 22 Jul 2026 at 10:46, Jorge Ramirez via U-Boot
<[email protected]> wrote:
On 22/07/26 10:27:22, [email protected] wrote:
On 7/22/26 08:07, Jorge Ramirez-Ortiz wrote:
This file implements the legacy single-command OPTEE_MSG_RPC_CMD_RPMB
supplicant (eMMC only). Rename it to rpmb_legacy.c so the primary rpmb.c
name is free for the RPMB subsystem interface added next; pure rename plus
its Makefile object, no functional change.
Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>
---
drivers/tee/optee/Makefile | 2 +-
drivers/tee/optee/{rpmb.c => rpmb_legacy.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/tee/optee/{rpmb.c => rpmb_legacy.c} (100%)
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index 36ac085ef42..8321cf53a19 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -3,4 +3,4 @@
obj-$(CONFIG_OPTEE) += core.o
obj-y += supplicant.o
obj-$(CONFIG_DM_I2C) += i2c.o
-obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
+obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb_legacy.o
diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb_legacy.c
similarity index 100%
rename from drivers/tee/optee/rpmb.c
rename to drivers/tee/optee/rpmb_legacy.c
Why not rpmb_emmc ?
Neil
right this is what is confusing about the current abstraction; op-tee has two
modes:
1. Legacy mode (legacy_operation = true)
Does the spec refer to this as legacy mode? Presumably it's RPMB on
eMMC vs RPMB on UFS (or presumably also NVME) or the revisions have
actual version numbers. Maybe name it after the interface that
supports the revision, or the actual revision of the RPMB spec, as
opposed to just legacy. What happens when next version comes along, to
we rename legacy to old_legacy so we can have new, legacy and
old_legacy?
So I did a small dig and both commands are still referenced in OP-TEE
and the TEE supplicant.
But indeed the OPTEE_RPC_CMD_RPMB command is only used in the userspace
TEE supplicant _and_ U-Boot, while Linux uses the other RPMB Frames
command like this implementation.
In OPTEE the usage of OPTEE_RPC_CMD_RPMB it's explicited as "legacy" in
https://github.com/OP-TEE/optee_os/blob/991587c721a603e831cad228626078289adad159/core/tee/tee_rpmb_fs.c#L486
so we can describe it as "Legacy", even if it's not described as legacy
on in the OP-TEE headers nor in the TEE supplicant.
But, I'll stick to my proposal to rename as rpmb_emmc and rpmb_ufs and
add a comment in the rpmb_emmc explaining it uses the OPTEE_RPC_CMD_RPMB
and may need to be add support for the FRAMES commands.
And the other way around add a small comment in the UFS implementation
explaining it only supports the FRAMES commands.
Neil
- Uses the original RPC command OPTEE_RPC_CMD_RPMB.
- No device enumeration — assumes a single, fixed eMMC RPMB device at
- CFG_RPMB_FS_DEV_ID (dev_type = OPTEE_RPC_RPMB_EMMC).
- This is the fallback for older supplicants that don't understand the
probe protocol
2. Probe / new mode (legacy_operation = false)
- Uses OPTEE_RPC_CMD_RPMB_PROBE_RESET + OPTEE_RPC_CMD_RPMB_PROBE_NEXT
to enumerate RPMB devices, then OPTEE_RPC_CMD_RPMB_FRAMES for the
actual frame I/O.
- Supports multiple RPMB devices
- OP-TEE probes all devices first, deferring key provisioning until
every device is examined.
This PR adds supports for UFS using the new mode of operation that
enumerates devices instead of the legacy mode.
In the meantime eMMC continues to use the legacy mode.
So the super-sets are legacy (for emmc) and probe/default (for UFS and
eventually eMMC/NVMe and so on).
