On 7/4/2024 5:34 PM, Dmitry Baryshkov wrote: > On Thu, 4 Jul 2024 at 00:40, Amirreza Zarrabi <quic_azarrabi@xxxxxxxxxxx> wrote: >> >> >> >> On 7/3/2024 10:13 PM, Dmitry Baryshkov wrote: >>> On Tue, Jul 02, 2024 at 10:57:36PM GMT, Amirreza Zarrabi wrote: >>>> Qualcomm TEE hosts Trusted Applications and Services that run in the >>>> secure world. Access to these resources is provided using object >>>> capabilities. A TEE client with access to the capability can invoke >>>> the object and request a service. Similarly, TEE can request a service >>>> from nonsecure world with object capabilities that are exported to secure >>>> world. >>>> >>>> We provide qcom_tee_object which represents an object in both secure >>>> and nonsecure world. TEE clients can invoke an instance of qcom_tee_object >>>> to access TEE. TEE can issue a callback request to nonsecure world >>>> by invoking an instance of qcom_tee_object in nonsecure world. >>> >>> Please see Documentation/process/submitting-patches.rst on how to write >>> commit messages. >> >> Ack. >> >>> >>>> >>>> Any driver in nonsecure world that is interested to export a struct (or a >>>> service object) to TEE, requires to embed an instance of qcom_tee_object in >>>> the relevant struct and implements the dispatcher function which is called >>>> when TEE invoked the service object. >>>> >>>> We also provids simplified API which implements the Qualcomm TEE transport >>>> protocol. The implementation is independent from any services that may >>>> reside in nonsecure world. >>> >>> "also" usually means that it should go to a separate commit. >> >> I will split this patch to multiple smaller ones. >> > > [...] > >>> >>>> + } in, out; >>>> +}; >>>> + >>>> +int qcom_tee_object_do_invoke(struct qcom_tee_object_invoke_ctx *oic, >>>> + struct qcom_tee_object *object, unsigned long op, struct qcom_tee_arg u[], int *result); >>> >>> What's the difference between a result that gets returned by the >>> function and the result that gets retuned via the pointer? >> >> The function result, is local to kernel, for instance memory allocation failure, >> or failure to issue the smc call. The result in pointer, is the remote result, >> for instance return value from TA, or the TEE itself. >> >> I'll use better name, e.g. 'remote_result'? > > See how this is handled by other parties. For example, PSCI. If you > have a standard set of return codes, translate them to -ESOMETHING in > your framework and let everybody else see only the standard errors. > > I can not hide this return value, they are TA dependent. The client to a TA needs to see it, just knowing that something has failed is not enough in case they need to do something based on that. I can not even translate them as they are TA related so the range is unknown.
