Hi Jan The CI seems to complain again unfortunately. https://git.u-boot-project.org/u-boot/custodians/u-boot-tpm/-/jobs/96289#L2649
I didnt check yet, but it seems like a missing header somewhere! Cheers /Ilias On Fri, 18 Sept 2026 at 10:11, Ilias Apalodimas <[email protected]> wrote: > > Hi Jan, > > > On Thu, 17 Sept 2026 at 18:24, Jan Kiszka <[email protected]> wrote: > > > > 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. > > I didn't have a specific sequence in mind. I just noticed the mutex > locks in op-tee and was wondering if there's a chance we can re-enter > on a different OP-TEE thread while holding the mutex. But I can't > reprocude it locally with or without CONFIG_OPTEE_SERVICE_DISCOVERY > (which changes how the device is bound). > > Reviewed-by: Ilias Apalodimas <[email protected]> > > P.S: I'll fixup is IS_ENABLED() during merge > > Thanks! > /Ilias > > > > Jan > > > > -- > > Siemens AG, Foundational Technologies > > Linux Expert Center
