Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Etienne Carriere]

Hello Peng and all,


> From: Peng Fan <peng.fan@nxp.com>
>
> This mailbox driver implements a mailbox which signals transmitted data
> via an ARM smc (secure monitor call) instruction. The mailbox receiver
> is implemented in firmware and can synchronously return data when it
> returns execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs
> which either don't have a separate management processor or on which such
> a core is not available. A user of this mailbox could be the SCP
> interface.
>
> Modified from Andre Przywara's v2 patch
> https://lore.kernel.org/patchwork/patch/812999/
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>

I've successfully tested your change on my board. It is a stm32mp1
with TZ secure hardening and I run an OP-TEE firmware (possibly a TF-A
sp_min) with a SCMI server for clock and reset. Upstream in progress.
The platform uses 2 instances of your SMC based mailbox device driver
(2 mailboxes). Works nice with your change.

You can add my T-b tag: Tested-by: Etienne Carriere
<etienne.carriere@linaro.org>

FYI, I'll (hopefully soon) post a change proposal in U-Boot ML for an
equvalent 'SMC based mailbox' driver and SCMI agent protocol/device
drivers for clock and reset controllers.
I'm also working on getting this SCMI server upstream in TF-A and
OP-TEE. Your SMC based mailbox driver is a valuable notification
scheme for our SCMI services support in Arm TZ secure world.

Regards,
Etienne

RE: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

> Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox
> 
> Hello Peng and all,
> 
> 
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&amp;data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C735cc6cd00404082bf8c08d79f67b93a%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637153140140878278&amp;sdata=m0lcAEIr0ZP
> tyPHorSW
> > NYgjfI5p0genJLlhqHMIHBg0%3D&amp;reserved=0
> >
> > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> 
> I've successfully tested your change on my board. It is a stm32mp1 with TZ
> secure hardening and I run an OP-TEE firmware (possibly a TF-A
> sp_min) with a SCMI server for clock and reset. Upstream in progress.
> The platform uses 2 instances of your SMC based mailbox device driver
> (2 mailboxes). Works nice with your change.
> 
> You can add my T-b tag: Tested-by: Etienne Carriere
> <etienne.carriere@linaro.org>

Thanks, but this patch has been dropped.

Per Sudeep, we all use smc transport, not smc mailbox ,
I'll post patch in a few days based on the transport split patch.

> 
> FYI, I'll (hopefully soon) post a change proposal in U-Boot ML for an equvalent
> 'SMC based mailbox' driver and SCMI agent protocol/device drivers for clock
> and reset controllers.

Great to know you did scmi agent code in U-Boot. Do you have some public repo
for access?

Thanks,
Peng.

> I'm also working on getting this SCMI server upstream in TF-A and OP-TEE.
> Your SMC based mailbox driver is a valuable notification scheme for our SCMI
> services support in Arm TZ secure world.
> 
> Regards,
> Etienne

Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Sudeep Holla]

On Mon, Jan 27, 2020 at 12:58:12PM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox
> >
> > Hello Peng and all,
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > This mailbox driver implements a mailbox which signals transmitted
> > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > receiver is implemented in firmware and can synchronously return data
> > > when it returns execution to the non-secure world again.
> > > An asynchronous receive path is not implemented.
> > > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > > which either don't have a separate management processor or on which
> > > such a core is not available. A user of this mailbox could be the SCP
> > > interface.
> > >

[...]

> > I've successfully tested your change on my board. It is a stm32mp1 with TZ
> > secure hardening and I run an OP-TEE firmware (possibly a TF-A
> > sp_min) with a SCMI server for clock and reset. Upstream in progress.
> > The platform uses 2 instances of your SMC based mailbox device driver
> > (2 mailboxes). Works nice with your change.
> >
> > You can add my T-b tag: Tested-by: Etienne Carriere
> > <etienne.carriere@linaro.org>
>
> Thanks, but this patch has been dropped.
>
> Per Sudeep, we all use smc transport, not smc mailbox ,
>
Yes, I asked if there are any other users of SMC mailbox other than
SCMI. We are planning to separate the transport from the SCMI driver[1]
to enable transport other than mailbox. SMC can be one of them and the
other one planned is virtio. Please feel free to add to the discussion
or review.

--
Regards,
Sudeep

[1] https://lore.kernel.org/lkml/f170b33989b426ac095952634fcd1bf45b86a7a3.1580208329.git.viresh.kumar@linaro.org

Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Etienne Carriere]

Hello Peng,

On Mon, 27 Jan 2020 at 13:58, Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox
> >
> > Hello Peng and all,
> >
> >
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > This mailbox driver implements a mailbox which signals transmitted
> > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > receiver is implemented in firmware and can synchronously return data
> > > when it returns execution to the non-secure world again.
> > > An asynchronous receive path is not implemented.
> > > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > > which either don't have a separate management processor or on which
> > > such a core is not available. A user of this mailbox could be the SCP
> > > interface.
> > >
> > > Modified from Andre Przywara's v2 patch
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&amp;data=02%7C01%7
> > Cpeng.fa
> > >
> > n%40nxp.com%7C735cc6cd00404082bf8c08d79f67b93a%7C686ea1d3bc2b4
> > c6fa92cd
> > >
> > 99c5c301635%7C0%7C0%7C637153140140878278&amp;sdata=m0lcAEIr0ZP
> > tyPHorSW
> > > NYgjfI5p0genJLlhqHMIHBg0%3D&amp;reserved=0
> > >
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >
> > I've successfully tested your change on my board. It is a stm32mp1 with TZ
> > secure hardening and I run an OP-TEE firmware (possibly a TF-A
> > sp_min) with a SCMI server for clock and reset. Upstream in progress.
> > The platform uses 2 instances of your SMC based mailbox device driver
> > (2 mailboxes). Works nice with your change.
> >
> > You can add my T-b tag: Tested-by: Etienne Carriere
> > <etienne.carriere@linaro.org>
>
> Thanks, but this patch has been dropped.
>
> Per Sudeep, we all use smc transport, not smc mailbox ,
> I'll post patch in a few days based on the transport split patch.

Ok, i am syncing.

> >
> > FYI, I'll (hopefully soon) post a change proposal in U-Boot ML for an equvalent
> > 'SMC based mailbox' driver and SCMI agent protocol/device drivers for clock
> > and reset controllers.
>
> Great to know you did scmi agent code in U-Boot. Do you have some public repo
> for access?

I've created a P-R on my github repo to share until I submit to u-boot:
 https://github.com/etienne-lms/u-boot/pull/3

I guess I will change my u-boot proposal and get a SMC SCMI transport
outside of the mailbox framework.

Regards,
Etienne


>
> Thanks,
> Peng.
>
> > I'm also working on getting this SCMI server upstream in TF-A and OP-TEE.
> > Your SMC based mailbox driver is a valuable notification scheme for our SCMI
> > services support in Arm TZ secure world.
> >
> > Regards,
> > Etienne

Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Sudeep Holla]

On Wed, Jan 29, 2020 at 04:01:07PM +0100, Etienne Carriere wrote:
> Hello Peng,
>
> On Mon, 27 Jan 2020 at 13:58, Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox
> > >
> > > Hello Peng and all,
> > >
> > >
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > This mailbox driver implements a mailbox which signals transmitted
> > > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > > receiver is implemented in firmware and can synchronously return data
> > > > when it returns execution to the non-secure world again.
> > > > An asynchronous receive path is not implemented.
> > > > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > > > which either don't have a separate management processor or on which
> > > > such a core is not available. A user of this mailbox could be the SCP
> > > > interface.
> > > >
> > > > Modified from Andre Przywara's v2 patch
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&amp;data=02%7C01%7
> > > Cpeng.fa
> > > >
> > > n%40nxp.com%7C735cc6cd00404082bf8c08d79f67b93a%7C686ea1d3bc2b4
> > > c6fa92cd
> > > >
> > > 99c5c301635%7C0%7C0%7C637153140140878278&amp;sdata=m0lcAEIr0ZP
> > > tyPHorSW
> > > > NYgjfI5p0genJLlhqHMIHBg0%3D&amp;reserved=0
> > > >
> > > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > >
> > > I've successfully tested your change on my board. It is a stm32mp1 with TZ
> > > secure hardening and I run an OP-TEE firmware (possibly a TF-A
> > > sp_min) with a SCMI server for clock and reset. Upstream in progress.
> > > The platform uses 2 instances of your SMC based mailbox device driver
> > > (2 mailboxes). Works nice with your change.
> > >
> > > You can add my T-b tag: Tested-by: Etienne Carriere
> > > <etienne.carriere@linaro.org>
> >
> > Thanks, but this patch has been dropped.
> >
> > Per Sudeep, we all use smc transport, not smc mailbox ,
> > I'll post patch in a few days based on the transport split patch.
>
> Ok, i am syncing.
>
> > >
> > > FYI, I'll (hopefully soon) post a change proposal in U-Boot ML for an equvalent
> > > 'SMC based mailbox' driver and SCMI agent protocol/device drivers for clock
> > > and reset controllers.
> >
> > Great to know you did scmi agent code in U-Boot. Do you have some public repo
> > for access?
>
> I've created a P-R on my github repo to share until I submit to u-boot:
>  https://github.com/etienne-lms/u-boot/pull/3
>
> I guess I will change my u-boot proposal and get a SMC SCMI transport
> outside of the mailbox framework.
>

Unless U-boot has mailbox framework or you are importing it, it's better
to keep U-boot implementation simple as SMC transport which I think you
already do. I had a look at the implementation[1], it shouldn't change
much other than if you prefer not to use "mailbox" terminology. I don't
understand the reason for even using the mailbox term there in the first
place.

--
Regards,
Sudeep

[1] https://github.com/etienne-lms/u-boot/pull/3/commits/34812c9175436f6a082f77347c5384393757c233

RE: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

> Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox
> 
> (+Viresh,Arnd)
> 
> On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> 
> I would like to know all the use-cases for this driver ? 

Currently my usecase is SCMI.

Is this only for SCMI or
> will this get used with other protocols on the top. I assume the latter and
> hence it is preferred to keep this as a mailbox driver.
> 
> I am not against this approach but the reason I ask is to avoid duplication.
> Viresh has suggested abstraction of transport from SCMI driver to enable
> other transports[1]. Couple of transports that I am aware of is this SMC/HVC
> and the new(still in-concept) SPCI.
> 
> So I am looking for opinions on that approach. Please feel free to comment
> here or as part of that patch.

If we want to use SMC as transports, smc mailbox or smc transports(non-mailbox)
could be used. Both ok for me, smc transports just need write a new driver
under scmi folder.

I left the decision to you(scmi maintainer) and Jassi(mailbox maintainer),
Just hope the smc/hvc used as transports could be landed in upstream soon.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flkml%2F5c545c2866ba075ddb44907940a1dae1d823b8a1.15750
> 19719.git.viresh.kumar%40linaro.org&amp;data=02%7C01%7Cpeng.fan%40n
> xp.com%7C06edb0c37371419db3cd08d777e66780%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C1%7C637109703766574454&amp;sdata=nInLSUu
> mwzBvl%2FcmckQkpZbJT4JAtVkzr1TSWkmz6qo%3D&amp;reserved=0

Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Sudeep Holla]

(+Viresh,Arnd)

On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> This mailbox driver implements a mailbox which signals transmitted data
> via an ARM smc (secure monitor call) instruction. The mailbox receiver
> is implemented in firmware and can synchronously return data when it
> returns execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs
> which either don't have a separate management processor or on which such
> a core is not available. A user of this mailbox could be the SCP
> interface.
>

I would like to know all the use-cases for this driver ? Is this only for
SCMI or will this get used with other protocols on the top. I assume the
latter and hence it is preferred to keep this as a mailbox driver.

I am not against this approach but the reason I ask is to avoid duplication.
Viresh has suggested abstraction of transport from SCMI driver to enable
other transports[1]. Couple of transports that I am aware of is this SMC/HVC
and the new(still in-concept) SPCI.

So I am looking for opinions on that approach. Please feel free to comment
here or as part of that patch.

--
Regards,
Sudeep

[1] https://lore.kernel.org/lkml/5c545c2866ba075ddb44907940a1dae1d823b8a1.1575019719.git.viresh.kumar@linaro.org

[PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan <peng.fan@nxp.com>

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/mailbox/Kconfig                |   7 ++
 drivers/mailbox/Makefile               |   2 +
 drivers/mailbox/arm-smc-mailbox.c      | 156 +++++++++++++++++++++++++++++++++
 include/linux/mailbox/arm-smccc-mbox.h |  17 ++++
 4 files changed, 182 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smccc-mbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
 	  The controller has 3 mailbox channels, the last of which can be
 	  used in Secure mode only.
 
+config ARM_SMC_MBOX
+	tristate "Generic ARM smc mailbox"
+	depends on OF && HAVE_ARM_SMCCC
+	help
+	  Generic mailbox driver which uses ARM smc calls to call into
+	  firmware for triggering mailboxes.
+
 config IMX_MBOX
 	tristate "i.MX Mailbox"
 	depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)	+= mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)	+= arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX)	+= arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX)	+= imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)	+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 000000000000..223d46fe6513
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox/arm-smccc-mbox.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+				    unsigned long, unsigned long,
+				    unsigned long, unsigned long,
+				    unsigned long);
+
+struct arm_smc_chan_data {
+	unsigned int function_id;
+	smc_mbox_fn *invoke_smc_mbox_fn;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+	struct arm_smc_chan_data *chan_data = link->con_priv;
+	struct arm_smccc_mbox_cmd *cmd = data;
+	unsigned long ret;
+
+	ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id,
+					    cmd->args_smccc[0],
+					    cmd->args_smccc[1],
+					    cmd->args_smccc[2],
+					    cmd->args_smccc[3],
+					    cmd->args_smccc[4],
+					    cmd->args_smccc[5]);
+
+	mbox_chan_received_data(link, (void *)ret);
+
+	return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+				     unsigned long arg0, unsigned long arg1,
+				     unsigned long arg2, unsigned long arg3,
+				     unsigned long arg4, unsigned long arg5)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+		      arg5, 0, &res);
+	return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+				     unsigned long arg0, unsigned long arg1,
+				     unsigned long arg2, unsigned long arg3,
+				     unsigned long arg4, unsigned long arg5)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+		      arg5, 0, &res);
+	return res.a0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+	.send_data	= arm_smc_send_data,
+};
+
+static struct mbox_chan *
+arm_smc_mbox_of_xlate(struct mbox_controller *mbox,
+		      const struct of_phandle_args *sp)
+{
+	return mbox->chans;
+}
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mbox_controller *mbox;
+	struct arm_smc_chan_data *chan_data;
+	int ret;
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->of_xlate = arm_smc_mbox_of_xlate;
+	mbox->num_chans = 1;
+	mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL);
+	if (!mbox->chans)
+		return -ENOMEM;
+
+	chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
+	if (!chan_data)
+		return -ENOMEM;
+
+	ret = of_property_read_u32(dev->of_node, "arm,func-id",
+				   &chan_data->function_id);
+	if (ret)
+		return ret;
+
+	if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
+		chan_data->invoke_smc_mbox_fn = __invoke_fn_smc;
+	else
+		chan_data->invoke_smc_mbox_fn = __invoke_fn_hvc;
+
+
+	mbox->chans->con_priv = chan_data;
+
+	mbox->txdone_poll = false;
+	mbox->txdone_irq = false;
+	mbox->ops = &arm_smc_mbox_chan_ops;
+	mbox->dev = dev;
+
+	platform_set_drvdata(pdev, mbox);
+
+	ret = devm_mbox_controller_register(dev, mbox);
+	if (ret)
+		return ret;
+
+	dev_info(dev, "ARM SMC mailbox enabled.\n");
+
+	return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+	struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(mbox);
+	return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+	{ .compatible = "arm,smc-mbox", },
+	{ .compatible = "arm,hvc-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+	.driver = {
+		.name = "arm-smc-mbox",
+		.of_match_table = arm_smc_mbox_of_match,
+	},
+	.probe		= arm_smc_mbox_probe,
+	.remove		= arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Peng Fan <peng.fan@nxp.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mailbox/arm-smccc-mbox.h b/include/linux/mailbox/arm-smccc-mbox.h
new file mode 100644
index 000000000000..244e09598c10
--- /dev/null
+++ b/include/linux/mailbox/arm-smccc-mbox.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_ARM_SMCCC_MBOX_H_
+#define _LINUX_ARM_SMCCC_MBOX_H_
+
+#include <linux/types.h>
+
+/**
+ * struct arm_smccc_mbox_cmd - ARM SMCCC message structure
+ * @args_smccc:	actual usage of registers is up to the protocol
+ *		(within the SMCCC limits)
+ */
+struct arm_smccc_mbox_cmd {
+	unsigned long args_smccc[6];
+};
+
+#endif /* _LINUX_ARM_SMCCC_MBOX_H_ */
-- 
2.16.4