[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81c59da1dc2a255c58e7e338f30285e68b4664d6.camel@linux.intel.com>
Date: Wed, 27 May 2020 22:42:03 +0300
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To: Maxim Uvarov <maxim.uvarov@...aro.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"tee-dev @ lists . linaro . org" <tee-dev@...ts.linaro.org>,
peterhuewe@....de, jgg@...pe.ca,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jens Wiklander <jens.wiklander@...aro.org>,
linux-integrity@...r.kernel.org, Arnd Bergmann <arnd@...aro.org>,
Sumit Garg <sumit.garg@...aro.org>
Subject: Re: [PATCHv2 2/2] tpm_ftpm_tee: register driver on TEE bus
On Mon, 2020-05-25 at 09:50 +0300, Maxim Uvarov wrote:
> Jakko,
> tee-supplicant application provides state machine over callbacks with
> RPC messages.
> https://github.com/OP-TEE/optee_client/blob/master/tee-supplicant/src/tee_supplicant.c#L614
> It also allocates shm. Without running tee-supplicant
> tee_client_open_session() will fail.
> optee_open_session()->get_msg_arg()->tee_shm_alloc()->...
> Optee team wanted to remove some dependencies from tee-supplicant with
> moving code
> to the kernel. But for now I think that should be out of the scope of
> current patches due to
> they fix driver initialization on tee bus without breaking current
> functionality.
So what is the role in high-level for tee-supplicant? Why does it
exist? No time to dive into code unfortunately.
These kernel commits do not explain in simple terms enough how all
of these entities connect with each other, if you don't have that
understanding beforehand.
/Jarkko
Powered by blists - more mailing lists