Messages in this thread | | | Date | Thu, 9 Mar 2023 21:54:32 +0100 | Subject | Re: [PATCH v3 2/4] firmware: Add support for Qualcomm Secure Execution Environment SCM interface | From | Maximilian Luz <> |
| |
On 3/9/23 09:45, Dmitry Baryshkov wrote: > On 08/03/2023 15:59, Maximilian Luz wrote: >> On 3/7/23 16:32, Dmitry Baryshkov wrote: >>> On 05/03/2023 04:21, Maximilian Luz wrote:
[...]
>>>> +int qseecom_scm_call(struct qseecom_device *qsee, const struct qcom_scm_desc *desc, >>>> + struct qseecom_scm_resp *res); >>>> + >>>> + >>>> +/* -- Secure App interface. ------------------------------------------------- */ >>>> + >>>> +#define QSEECOM_MAX_APP_NAME_SIZE 64 >>>> + >>>> +int qseecom_app_get_id(struct qseecom_device *qsee, const char *app_name, u32 *app_id); >>>> +int qseecom_app_send(struct qseecom_device *qsee, u32 app_id, struct qseecom_dma *req, >>>> + struct qseecom_dma *rsp); >>> >>> I think that only these calls should be made public / available to other modules. qseecom_scm_call also is an internal helper. >> >> So move all calls to qcom_scm and only make these two public? Or move only >> qseecom_scm_call() to qcom_scm (which would require to make it public there, >> however). Or how would you want this to look? > > I think we can make it with just these calls being public. Or even with just the second one being public and available to other drivers. If the app_id is a part of qseecom_app_device, we can pass that device to the qseecom_app_send(). And qseecom_app_get_id() becomes a part of app registration.
Right, with the bus structure, we only really need qseecom_app_send().
I'm still a bit concerned about things maybe getting too complex for qcom_scm with the blocking/re-entrant calls (and maybe other future stuff), but I guess we can always try to break things up when/if we get around to that.
I'll try to implement that and your other suggestions and see how that goes. I think that should work quite well overall.
Thanks again for your review and comments.
Regards, Max
| |