Re: [PATCH V3 4/8] remoteproc: qcom: add hexagon based WCSS secure PIL driver

[Sricharan Ramabadhran <quic_srichara@quicinc.com>]

On 1/8/2025 11:59 AM, Sricharan Ramabadhran wrote:
> [..]
> 
>>> +#include <linux/firmware/qcom/qcom_scm.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/io.h>
>>> +#include <linux/iopoll.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/of_reserved_mem.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/reset.h>
>>> +#include <linux/soc/qcom/mdt_loader.h>
>>> +#include <linux/soc/qcom/smem.h>
>>> +#include <linux/soc/qcom/smem_state.h>
>>> +#include <linux/mailbox_client.h>
>>> +#include <linux/mailbox/tmelcom-qmp.h>
>>
>> This will require mailbox maintainer to first accept the tmelcom mailbox
>> driver, and share a immutable branch with me (or we have to wait until
>> this include file trickles in).
>>
>> Please ensure that mailbox maintainer is aware of this request.
> 
> Hi Bjorn,
>   The plan is, in the next spin of TMEL[V3], tmel driver will take care
>   of routing the request to either SCM(or)TMEL, so that client drivers
>   like rproc/crypto etc which requires those secure services can be
>   abstract (ie) just do a mbox_send_message with a SCM cmd id. That way
>   for adding any future secure services in client drivers, nothing
>   extra needs to be done and this will avoid this header dependency
>   as well. Is that approach fine ?

Ok, with more thought, i guess this approach will not work. Will stick
to what you are suggesting, just use mbox->chan available in client
itself to take the decision.

Regards,
  Sricharan