[..]
+#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
