Re: [PATCH v2 4/5] optee: rename rpmb.c to rpmb_legacy.c

[Jorge Ramirez via U-Boot <u-boot@lists.u-boot-project.org>]

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
> > <u-boot@lists.u-boot-project.org> wrote:
> > > 
> > > On 22/07/26 10:27:22, neil.armstrong@linaro.org 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 <jorge.ramirez@oss.qualcomm.com>
> > > > > ---
> > > > >    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)