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)
