On 12/10/2024 9:24 PM, Jens Wiklander wrote:
> On Tue, Dec 3, 2024 at 5:20 AM Amirreza Zarrabi
> <quic_azarrabi@xxxxxxxxxxx> wrote:
>>
>> Introduce qcom_tee_object, which represents an object in both QTEE and
>> the kernel. QTEE clients can invoke an instance of qcom_tee_object to
>> access QTEE services. If this invocation produces a new object in QTEE,
>> an instance of qcom_tee_object will be returned.
>>
>> Similarly, QTEE can request services from the kernel by issuing a callback
>> request, which invokes an instance of qcom_tee_object in the kernel.
>> Any subsystem that exposes a service to QTEE should allocate and initialize
>> an instance of qcom_tee_object with a dispatcher callback that is called
>> when the object is invoked.
>>
>> Signed-off-by: Amirreza Zarrabi <quic_azarrabi@xxxxxxxxxxx>
>> ---
>> drivers/tee/Kconfig | 1 +
>> drivers/tee/Makefile | 1 +
>> drivers/tee/qcomtee/Kconfig | 10 +
>> drivers/tee/qcomtee/Makefile | 6 +
>> drivers/tee/qcomtee/async.c | 153 ++++++
>> drivers/tee/qcomtee/core.c | 928 +++++++++++++++++++++++++++++++++
>> drivers/tee/qcomtee/qcom_scm.c | 36 ++
>> drivers/tee/qcomtee/qcomtee_msg.h | 217 ++++++++
>> drivers/tee/qcomtee/qcomtee_private.h | 47 ++
>> drivers/tee/qcomtee/release.c | 66 +++
>> include/linux/firmware/qcom/qcom_tee.h | 284 ++++++++++
>> 11 files changed, 1749 insertions(+)
>>
> [snip]
>
>> +/**
>> + * DOC: Overview
>> + *
>> + * qcom_tee_object provides object ref-counting, id allocation for objects hosted in
>> + * REE, and necessary message marshaling for Qualcomm TEE (QTEE).
>> + *
>> + * To invoke an object in QTEE, user calls qcom_tee_object_do_invoke() while passing
>> + * an instance of &struct qcom_tee_object and the requested operation + arguments.
>> + *
>> + * After the boot, QTEE provides a static object %ROOT_QCOM_TEE_OBJECT (type of
>> + * %QCOM_TEE_OBJECT_TYPE_ROOT). The root object is invoked to pass user's credentials and
>> + * obtain other instances of &struct qcom_tee_object (type of %QCOM_TEE_OBJECT_TYPE_TEE)
>> + * that represents services and TAs in QTEE, see &enum qcom_tee_object_type.
>> + *
>> + * The object received from QTEE are refcounted. So the owner of these objects can
>> + * issue qcom_tee_object_get(), to increase the refcount, and pass objects to other
>> + * clients, or issue qcom_tee_object_put() to decrease the refcount, and releasing
>> + * the resources in QTEE.
>> + *
>> + * REE can host services accessible to QTEE. A driver should embed an instance of
>> + * &struct qcom_tee_object in the struct it wants to export to QTEE (it is called
>> + * callback object). It issues qcom_tee_object_user_init() to set the dispatch()
>> + * operation for the callback object and set its type to %QCOM_TEE_OBJECT_TYPE_CB_OBJECT.
>> + *
>> + * core.c holds an object table for callback objects. An object id is assigned
>> + * to each callback object which is an index to the object table. QTEE uses these ids
>> + * to reference or invoke callback objects.
>> + *
>> + * If QTEE invoke a callback object in REE, the dispatch() operation is called in the
>> + * context of thread that called qcom_tee_object_do_invoke(), originally.
>> + */
>> +
>> +/**
>> + * enum qcom_tee_object_typ - Object types.
>> + * @QCOM_TEE_OBJECT_TYPE_TEE: object hosted on QTEE.
>> + * @QCOM_TEE_OBJECT_TYPE_CB_OBJECT: object hosted on REE.
>> + * @QCOM_TEE_OBJECT_TYPE_ROOT: 'primordial' object.
>> + * @QCOM_TEE_OBJECT_TYPE_NULL: NULL object.
>> + *
>> + * Primordial object is used for bootstrapping the IPC connection between a REE
>> + * and QTEE. It is invoked by REE when it wants to get a 'client env'.
>> + */
>> +enum qcom_tee_object_type {
>> + QCOM_TEE_OBJECT_TYPE_TEE,
>> + QCOM_TEE_OBJECT_TYPE_CB_OBJECT,
>
> The second OBJECT seems redundant. How about QCOM_TEE_OBJECT_TYPE_CB
> or QCOM_TEE_OBJECT_TYPE_CALLBACK instead?
>
Sure. I'll rename to QCOM_TEE_OBJECT_TYPE_CALLBACK.
Best Regards,
Amir
>> + QCOM_TEE_OBJECT_TYPE_ROOT,
>> + QCOM_TEE_OBJECT_TYPE_NULL,
>> +};
> [snip]
>
> Cheers,
> Jens
