On 09.09.26 12:04, Ilias Apalodimas wrote: > 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?
Hmm, let me check... Jan -- Siemens AG, Foundational Technologies Linux Expert Center
