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?
> + QCOM_TEE_OBJECT_TYPE_ROOT,
> + QCOM_TEE_OBJECT_TYPE_NULL,
> +};
[snip]
Cheers,
Jens
