On 7/22/26 16:35, Jorge Ramirez wrote:
On 22/07/26 15:10:16, Neil Armstrong wrote:
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?
yeah, Neil addressed this below. I agree with you Peter but sometimes
legacy can be appropiately used (I believed that this to be one of
those binary instances).
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.
I'll push back (one last time), my point being that I expect rpmb_legacy
to disappear where as rpmb_mmc or rpmb_ufs will not (and I see no reason
to keep them in separate files): hence the pursue of a single rpmb.c
if after this you still want to separate rpmb_ufs and rpmb_mmc I'll go
ahead (but we will lose that temporary hint to the op-tee dependency)
Well I'm not sure it's "legacy" as we speak because it's very probable
some OP-TEE binaries used in production right now uses the OPTEE_RPC_CMD_RPMB,
so ultimately we need to support both on any storages to support any OP-TEE
versions.
My point is after your changeset, one file is hardcoding eMMC support and
the other is hardcoding UFS and there's no dynamic Device Model way to
dynamically register an RPMB partition for any storage.
So ultimately, this should be implemented using Driver Model and the
eMMC code should live in eMMC subsystem, same for UFS, by registering
an RPMB subdevice like this is done on the Linux side.
But for now, rename the file relative to it's content to avoid any confusion.
Neil
