On 17.09.26 16:57, Ilias Apalodimas wrote: > On Thu, Sep 17, 2026, 15:04 Jan Kiszka <[email protected]> wrote: >> >> On 17.09.26 15:01, Ilias Apalodimas wrote: >>> Hi Jan >>> >>> I pinged Jens for some help with the OP-TEE path. >>> >>> [...] >>> >>>> --- a/drivers/tee/optee/rpmb.c >>>> +++ b/drivers/tee/optee/rpmb.c >>>> @@ -191,3 +191,23 @@ void optee_suppl_rpmb_release(struct udevice *dev) >>>> { >>>> release_mmc(dev_get_priv(dev)); >>>> } >>>> + >>>> +void optee_rpmb_available(void) >>>> +{ >>>> + struct udevice *dev; >>>> + struct uclass *uc; >>>> + u32 tee_sess; >>>> + >>>> + uclass_id_foreach_dev(UCLASS_TEE, dev, uc) { >>>> + if (strcmp(dev->driver->name, "optee") != 0 || >>>> + !device_active(dev)) >>>> + continue; >>>> + >>>> + if (optee_open_enum_session(dev, &tee_sess) != 0) >>>> + continue; >>>> + >>>> + optee_bind_services(dev, tee_sess, >>>> PTA_CMD_GET_DEVICES_RPMB); >>> >>> so both optee_probe() and this function will now call >>> optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES_RPMB);. >>> In OP-TEE that ends up holding a mutex in tee_rpmb_reinit(), but I >>> don't know OP-TEE that well to figure out if this can deadlock. >>> >> >> I was developing this under the assumption that probing and init paths >> are single-threaded in U-Boot - aren't they? > > > They are but iirc the responses from OP-TEE are RPC calls in the RPMB > case, they aren't guaranteed to run to completion. >
Maybe it would help (at least me) if you can sketch a control flow you are concerned about. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
