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
