On 09.09.26 13:46, Jan Kiszka wrote: > 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... >
It's a problem. Is there a helper/service to check the binding state, or should we track that via a static flag in optee_rpmb_available? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
