On 18.09.26 14:36, Ilias Apalodimas wrote: > 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! >
Where you able to find the reason, or do you need support? I tried to read the CI log, but it is very hard for me to correlate the output with the configuration that might have been involved. Jan > 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 -- Siemens AG, Foundational Technologies Linux Expert Center
