tree 4cf5108b5791612b65d21fb649114345bee70a32
parent 52826293a760e7ae5fd48644764dba527ccf46bd
parent 4518a4dced5913c8cac56224e60c734a097fd324
author Tom Rini <trini@konsulko.com> 1713464020 -0600
committer Tom Rini <trini@konsulko.com> 1713464020 -0600

Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm

Igor says:
"The problem initially was in the TEE sandbox driver implementation
 (drivers/tee/sandbox.c) and it's limitations, which doesn't
 permit to have multiple simultaneous sessions with different TAs.
 This is what actually happened in this CI run [1], firstly "optee_rpmb"
 cmd was executed (and after execution we had one session open), and
 then "scp03", which also makes calls to OP-TEE, however it fails
 in sandbox_tee_open_session() because of this check:

 if (state->ta) {
     printf("A session is already open\n");
     return -EBUSY;
 }

 I had two ways in mind to address that:
 1. Close a session on each optee_rpmb cmd invocation.
 I don't see any reason to keep this session open, as obviously
 there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
 devices) to close it automatically before handing over control to
 Linux kernel. As a result we might end up with some orphaned sessions
 registered in OP-TEE OS core (obvious resource leak).
 2. Extend TEE sandbox driver, add support for multiple
 simultaneous sessions just to handle the case.

 I've chosen the first approach, as IMO it was "kill two birds with one stone",
 I could address resource leak in OP-TEE and bypass limitations of
 TEE sandbox driver."

Link: https://lore.kernel.org/u-boot/CAByghJZVRbnFUwJdgU534tvGA+DX2pArf0i7ySik=BrXgADe3Q@mail.gmail.com/

The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/20414
showed no problems