Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support

[Amirreza Zarrabi <quic_azarrabi@quicinc.com>]

On 7/4/2024 5:34 PM, Dmitry Baryshkov wrote:
> On Thu, 4 Jul 2024 at 00:40, Amirreza Zarrabi <quic_azarrabi@quicinc.com> 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.