On Wed, 9 Sept 2026 at 12:12, Jan Kiszka <[email protected]> wrote: > > On 09.09.26 09:50, Ilias Apalodimas wrote: > > Hi Jan > > > > [...] > > > >> --- a/drivers/mmc/mmc.c > >> +++ b/drivers/mmc/mmc.c > >> @@ -27,6 +27,7 @@ > >> #include <linux/list.h> > >> #include <linux/printk.h> > >> #include <div64.h> > >> +#include <tee/optee.h> > >> #include "mmc_private.h" > >> > >> #define DEFAULT_CMD6_TIMEOUT_MS 500 > >> @@ -3168,6 +3169,9 @@ int mmc_init(struct mmc *mmc) > >> mmc->cfg->name); > >> } > >> > >> + if (CONFIG_IS_ENABLED(OPTEE) && mmc->capacity_rpmb > 0) > >> + optee_rpmb_available(); > > > > With this we'll end up calling the optee bind methods again for > > discovered devices calling bind_service_list(). I haven't tested this > > locally yet, but is there any chance this ends up binding the devices > > that depend on an RPMB twice? > > I don't think we will have an issue here: Either OP-TEE isn't ready yet, > or RPMB wasn't yet when we called it first. So I do not see yet who > actual successful listing could be done twice.
The question is what happens if OP-TEE & the RPMB is ready and you issue an mmc rescan. That will force optee_rpmb_available() to re-run and rediscover all the devices no? Thanks /Ilias > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center
