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

[Sricharan Ramabadhran <quic_srichara@quicinc.com>]

[..]

>> +#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 ?

Regards,
Sricharan