On Tue, 29 Sept 2026 at 19:44, Jan Kiszka <[email protected]> wrote: > > 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.
It blows up in SPL, so I probably triggered that from switching CONFIG_IS_ENABLED to IS_ENABLED. I'll requeue it on the CI with that change Cheers /Ilias > > 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
