Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Peng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Peng-Fan/mailbox-arm-introduce-smc-triggered-mailbox/20190924-091652
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from :0:0:
>> include/linux/mailbox/arm-smccc-mbox.h:17:3: error: unknown type name 'u32'
u32 args_smccc32[6];
^~~
>> include/linux/mailbox/arm-smccc-mbox.h:18:3: error: unknown type name 'u64'
u64 args_smccc64[6];
^~~
vim +/u32 +17 include/linux/mailbox/arm-smccc-mbox.h
5
6 /**
7 * struct arm_smccc_mbox_cmd - ARM SMCCC message structure
8 * @function_id:function id passed from client, If mbox
9 * DT has arm,func-id property, the driver will use
10 * that one.
11 * @args_smccc32/64:actual usage of registers is up to the protocol
12 * (within the SMCCC limits)
13 */
14 struct arm_smccc_mbox_cmd {
15 unsigned int function_id;
16 union {
> 17 u32 args_smccc32[6];
> 18 u64 args_smccc64[6];
19 };
20 };
21
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
RE: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Florian > Subject: Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox > > Hi Peng, > > On 9/23/2019 6:14 PM, Peng Fan wrote: > > From: Peng Fan > > > > 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%2Fdata=02%7C01%7 > Cpeng.fa > > > n%40nxp.com%7C296c7cd2225e4ca32bb808d74099afb2%7C686ea1d3bc2b4 > c6fa92cd > > > 99c5c301635%7C0%7C0%7C637048901144091126sdata=JDo%2Be7Tt > hoi4jve0O > > S8qe3%2Fpji4g8CgRxL7ntCQx3Fg%3Dreserved=0 > > > > Cc: Andre Przywara > > Signed-off-by: Peng Fan > > --- > > [snip] > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long); > > +static smc_mbox_fn *invoke_smc_mbox_fn; > > Sorry for spotting this so late, the only thing that concerns me here with > this > singleton is if we happen to have both an arm,smc-mbox and arm,hvc-mbox > configured in the system, this would not work. Yes. Thanks for spotting this. I do not believe this could be a > functional use case, but we should probably guard against that or better yet, > move that into the arm_smc_chan_data private structure? Agree. Will Fix in v9. Thanks, Peng. > -- > Florian
Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Peng, On 9/23/2019 6:14 PM, Peng Fan wrote: > From: Peng Fan > > 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/ > > Cc: Andre Przywara > Signed-off-by: Peng Fan > --- [snip] > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > + unsigned long, unsigned long, > + unsigned long, unsigned long, > + unsigned long); > +static smc_mbox_fn *invoke_smc_mbox_fn; Sorry for spotting this so late, the only thing that concerns me here with this singleton is if we happen to have both an arm,smc-mbox and arm,hvc-mbox configured in the system, this would not work. I do not believe this could be a functional use case, but we should probably guard against that or better yet, move that into the arm_smc_chan_data private structure? -- Florian
[PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
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/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig| 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 168 +
include/linux/mailbox/arm-smccc-mbox.h | 22 +
4 files changed, 199 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 ..664c8b4a0ed0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+static 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;
+ u32 function_id;
+
+ function_id = chan_data->function_id;
+ if (!function_id)
+ function_id = cmd->function_id;
+
+ if (ARM_SMCCC_IS_64(function_id)) {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+cmd->args_smccc64[1],
+cmd->args_smccc64[2],
+cmd->args_smccc64[3],
+cmd->args_smccc64[4],
+cmd->args_smccc64[5]);
+ } else {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+cmd->args_smccc32[1],
+cmd->args_smccc32[2],
+cmd->args_smccc32[3],
+cmd->args_smccc32[4],
+cmd->args_smccc32[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, );
+ 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;
+
+
