linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures
@ 2017-07-17 13:26 laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc laurentiu.tudor at nxp.com
                   ` (6 more replies)
  0 siblings, 7 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

Apart from a small change (first patch) which adds a missing comment,
this series make the bus driver compile on other architectures, as per
GregKH comment [1].
Compiled tested on:
 - booke powerpc (corenet{32,64}_smp_defconfig) with this ppc patch [2]
 - x86 (i386_defconfig, x86_64_defconfig, needs CONFIG_OF)
 - arm64 (defconfig)

[1] https://www.spinics.net/lists/linux-driver-devel/msg100585.html
[2] https://patchwork.ozlabs.org/patch/789474/

Laurentiu Tudor (7):
  staging: fsl-mc: add missing fsl_mc comment in struct msi_desc
  staging: fsl-mc: use generic memory barriers
  staging: fsl-mc: drop useless gic v3 related #include
  staging: fsl-mc: fix compilation with non-generic msi domain ops
  staging: fsl-mc: fix formating of phys_addr_t on 32 bits
  staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  staging: fsl-mc: allow the driver compile multi-arch

 drivers/staging/fsl-dpaa2/Kconfig                  |  2 +-
 drivers/staging/fsl-mc/bus/Kconfig                 |  4 +-
 drivers/staging/fsl-mc/bus/fsl-mc-msi.c            |  5 ++-
 .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c |  3 +-
 drivers/staging/fsl-mc/bus/mc-io.c                 |  8 ++--
 drivers/staging/fsl-mc/bus/mc-sys.c                | 45 +++++++++-------------
 include/linux/msi.h                                |  1 +
 7 files changed, 32 insertions(+), 36 deletions(-)

-- 
2.9.4

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

The mc-bus specific field, fsl_mc in struct msi_desc is missing its
comment so add it.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 include/linux/msi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index df6d592..80e3b56 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -66,6 +66,7 @@ struct fsl_mc_msi_desc {
  * @mask_pos:	[PCI MSI]   Mask register position
  * @mask_base:	[PCI MSI-X] Mask register base address
  * @platform:	[platform]  Platform device specific msi descriptor data
+ * @fsl_mc:	[fsl-mc]    FSL MC device specific msi descriptor data
  */
 struct msi_desc {
 	/* Shared device/bus type independent data */
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 2/7] staging: fsl-mc: use generic memory barriers
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:38   ` Robin Murphy
  2017-07-17 13:26 ` [PATCH 3/7] staging: fsl-mc: drop useless gic v3 related #include laurentiu.tudor at nxp.com
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

No need to use arch-specific memory barriers; switch to using generic
ones. The rmb()s were useless so drop them.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-mc/bus/mc-sys.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
index a1704c3..012abd5 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -127,7 +127,8 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
 	/* copy command parameters into the portal */
 	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
 		__raw_writeq(cmd->params[i], &portal->params[i]);
-	__iowmb();
+	/* ensure command params are committed before submitting it */
+	wmb();
 
 	/* submit the command by writing the header */
 	__raw_writeq(cmd->header, &portal->header);
@@ -150,9 +151,7 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
 	enum mc_cmd_status status;
 
 	/* Copy command response header from MC portal: */
-	__iormb();
 	resp->header = __raw_readq(&portal->header);
-	__iormb();
 	status = mc_cmd_hdr_read_status(resp);
 	if (status != MC_CMD_STATUS_OK)
 		return status;
@@ -160,7 +159,6 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
 	/* Copy command response data from MC portal: */
 	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
 		resp->params[i] = __raw_readq(&portal->params[i]);
-	__iormb();
 
 	return status;
 }
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 3/7] staging: fsl-mc: drop useless gic v3 related #include
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops laurentiu.tudor at nxp.com
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

Nothing from linux/irqchip/arm-gic-v3.h is used, so the #include can be
safely dropped.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-mc/bus/fsl-mc-msi.c                | 1 -
 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
index c04a2f2..ee6e3b7 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
@@ -11,7 +11,6 @@
 
 #include <linux/of_device.h>
 #include <linux/of_address.h>
-#include <linux/irqchip/arm-gic-v3.h>
 #include <linux/of_irq.h>
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index 865d385..e798ea4 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -11,7 +11,6 @@
 
 #include <linux/of_device.h>
 #include <linux/of_address.h>
-#include <linux/irqchip/arm-gic-v3.h>
 #include <linux/irq.h>
 #include <linux/msi.h>
 #include <linux/of.h>
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
                   ` (2 preceding siblings ...)
  2017-07-17 13:26 ` [PATCH 3/7] staging: fsl-mc: drop useless gic v3 related #include laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 5/7] staging: fsl-mc: fix formating of phys_addr_t on 32 bits laurentiu.tudor at nxp.com
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

The bus driver relies on generic msi domain ops.
Fix compilation for architectures that don't provide it (e.g. x86_64).

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-mc/bus/fsl-mc-msi.c                | 4 ++++
 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
index ee6e3b7..18774ee 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
@@ -17,6 +17,7 @@
 #include <linux/msi.h>
 #include "fsl-mc-private.h"
 
+#ifdef GENERIC_MSI_DOMAIN_OPS
 /*
  * Generate a unique ID identifying the interrupt (only used within the MSI
  * irqdomain.  Combine the icid with the interrupt index.
@@ -38,6 +39,9 @@ static void fsl_mc_msi_set_desc(msi_alloc_info_t *arg,
 	arg->hwirq = fsl_mc_domain_calc_hwirq(to_fsl_mc_device(desc->dev),
 					      desc);
 }
+#else
+#define fsl_mc_msi_set_desc NULL
+#endif
 
 static void fsl_mc_msi_update_dom_ops(struct msi_domain_info *info)
 {
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index e798ea4..cd73c58 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -45,7 +45,9 @@ static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
 	 * NOTE: This device id corresponds to the IOMMU stream ID
 	 * associated with the DPRC object (ICID).
 	 */
+#ifdef GENERIC_MSI_DOMAIN_OPS
 	info->scratchpad[0].ul = mc_bus_dev->icid;
+#endif
 	msi_info = msi_get_domain_info(msi_domain->parent);
 	return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, info);
 }
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 5/7] staging: fsl-mc: fix formating of phys_addr_t on 32 bits
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
                   ` (3 preceding siblings ...)
  2017-07-17 13:26 ` [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
  2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
  6 siblings, 0 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

Use correct format specifier for phys_addr_t variables (%pa) instead
of %llx. This fixes these warnings on 32 bit targets:
 "format '%llx' expects argument of type 'long long unsigned int',
  but argument 4 has type 'phys_addr_t' [-Wformat=]"

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-mc/bus/mc-io.c  |  8 ++++----
 drivers/staging/fsl-mc/bus/mc-sys.c | 12 ++++++------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-io.c b/drivers/staging/fsl-mc/bus/mc-io.c
index 35221a17..4e6f99a 100644
--- a/drivers/staging/fsl-mc/bus/mc-io.c
+++ b/drivers/staging/fsl-mc/bus/mc-io.c
@@ -129,8 +129,8 @@ int __must_check fsl_create_mc_io(struct device *dev,
 				      "mc_portal");
 	if (!res) {
 		dev_err(dev,
-			"devm_request_mem_region failed for MC portal %#llx\n",
-			mc_portal_phys_addr);
+			"devm_request_mem_region failed for MC portal %pa\n",
+			&mc_portal_phys_addr);
 		return -EBUSY;
 	}
 
@@ -139,8 +139,8 @@ int __must_check fsl_create_mc_io(struct device *dev,
 						   mc_portal_size);
 	if (!mc_portal_virt_addr) {
 		dev_err(dev,
-			"devm_ioremap_nocache failed for MC portal %#llx\n",
-			mc_portal_phys_addr);
+			"devm_ioremap_nocache failed for MC portal %pa\n",
+			&mc_portal_phys_addr);
 		return -ENXIO;
 	}
 
diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
index 012abd5..195d9f3 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -196,8 +196,8 @@ static int mc_polling_wait_preemptible(struct fsl_mc_io *mc_io,
 
 		if (time_after_eq(jiffies, jiffies_until_timeout)) {
 			dev_dbg(mc_io->dev,
-				"MC command timed out (portal: %#llx, dprc handle: %#x, command: %#x)\n",
-				 mc_io->portal_phys_addr,
+				"MC command timed out (portal: %pa, dprc handle: %#x, command: %#x)\n",
+				 &mc_io->portal_phys_addr,
 				 (unsigned int)mc_cmd_hdr_read_token(cmd),
 				 (unsigned int)mc_cmd_hdr_read_cmdid(cmd));
 
@@ -236,8 +236,8 @@ static int mc_polling_wait_atomic(struct fsl_mc_io *mc_io,
 		timeout_usecs -= MC_CMD_COMPLETION_POLLING_MAX_SLEEP_USECS;
 		if (timeout_usecs == 0) {
 			dev_dbg(mc_io->dev,
-				"MC command timed out (portal: %#llx, dprc handle: %#x, command: %#x)\n",
-				 mc_io->portal_phys_addr,
+				"MC command timed out (portal: %pa, dprc handle: %#x, command: %#x)\n",
+				 &mc_io->portal_phys_addr,
 				 (unsigned int)mc_cmd_hdr_read_token(cmd),
 				 (unsigned int)mc_cmd_hdr_read_cmdid(cmd));
 
@@ -290,8 +290,8 @@ int mc_send_command(struct fsl_mc_io *mc_io, struct mc_command *cmd)
 
 	if (status != MC_CMD_STATUS_OK) {
 		dev_dbg(mc_io->dev,
-			"MC command failed: portal: %#llx, dprc handle: %#x, command: %#x, status: %s (%#x)\n",
-			 mc_io->portal_phys_addr,
+			"MC command failed: portal: %pa, dprc handle: %#x, command: %#x, status: %s (%#x)\n",
+			 &mc_io->portal_phys_addr,
 			 (unsigned int)mc_cmd_hdr_read_token(cmd),
 			 (unsigned int)mc_cmd_hdr_read_cmdid(cmd),
 			 mc_status_to_string(status),
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
                   ` (4 preceding siblings ...)
  2017-07-17 13:26 ` [PATCH 5/7] staging: fsl-mc: fix formating of phys_addr_t on 32 bits laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-17 13:43   ` Robin Murphy
  2017-07-17 13:45   ` Arnd Bergmann
  2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
  6 siblings, 2 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

Split the 64-bit accesses in 32-bit accesses because there's no real
constrain in MC to do only atomic 64-bit. There's only one place
where ordering is important: when writing the MC command header the
first 32-bit part of the header must be written last.
We do this switch in order to allow compiling the driver on 32-bit.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
index 195d9f3..dd2828e 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
 {
 	int i;
 
-	/* copy command parameters into the portal */
-	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
-		__raw_writeq(cmd->params[i], &portal->params[i]);
-	/* ensure command params are committed before submitting it */
-	wmb();
-
-	/* submit the command by writing the header */
-	__raw_writeq(cmd->header, &portal->header);
+	/*
+	 * copy command parameters into the portal. Final write
+	 * triggers the submission of the command.
+	 */
+	for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
+		__raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
+		/* ensure command params are committed before submitting it */
+		wmb();
+	}
 }
 
 /**
@@ -148,19 +149,11 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
 						  struct mc_command *resp)
 {
 	int i;
-	enum mc_cmd_status status;
-
-	/* Copy command response header from MC portal: */
-	resp->header = __raw_readq(&portal->header);
-	status = mc_cmd_hdr_read_status(resp);
-	if (status != MC_CMD_STATUS_OK)
-		return status;
 
-	/* Copy command response data from MC portal: */
-	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
-		resp->params[i] = __raw_readq(&portal->params[i]);
+	for (i = 0; i < sizeof(struct mc_command) / sizeof(u32); i++)
+		((u32 *)resp)[i] = __raw_readl(&((u32 *)portal)[i]);
 
-	return status;
+	return mc_cmd_hdr_read_status(resp);
 }
 
 /**
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch
  2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
                   ` (5 preceding siblings ...)
  2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
@ 2017-07-17 13:26 ` laurentiu.tudor at nxp.com
  2017-07-19 16:09   ` kbuild test robot
  2017-07-19 17:31   ` kbuild test robot
  6 siblings, 2 replies; 20+ messages in thread
From: laurentiu.tudor at nxp.com @ 2017-07-17 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>

Drop dependency on ARCH_LAYERSCAPE (which in turn depends on ARM64),
thus leaving this driver compile on other architectures.
Also, other drivers depending on the bus are updated to depend
on ARCH_LAYERSCAPE until they'll also be made multi-arch.
This was compiled tested on:
 - booke powerpc (corenet{32,64}_smp_defconfig)
 - x86 (i386_defconfig, x86_64_defconfig, needs CONFIG_OF)
 - arm64 (defconfig)

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
 drivers/staging/fsl-dpaa2/Kconfig  | 2 +-
 drivers/staging/fsl-mc/bus/Kconfig | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/Kconfig b/drivers/staging/fsl-dpaa2/Kconfig
index 730fd6d..dfff675 100644
--- a/drivers/staging/fsl-dpaa2/Kconfig
+++ b/drivers/staging/fsl-dpaa2/Kconfig
@@ -4,7 +4,7 @@
 
 config FSL_DPAA2
 	bool "Freescale DPAA2 devices"
-	depends on FSL_MC_BUS
+	depends on FSL_MC_BUS && ARCH_LAYERSCAPE
 	---help---
 	  Build drivers for Freescale DataPath Acceleration
 	  Architecture (DPAA2) family of SoCs.
diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig
index a10aaf0..c0acc97 100644
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ b/drivers/staging/fsl-mc/bus/Kconfig
@@ -8,7 +8,7 @@
 
 config FSL_MC_BUS
 	bool "QorIQ DPAA2 fsl-mc bus driver"
-	depends on OF && ARCH_LAYERSCAPE
+	depends on OF
 	select GENERIC_MSI_IRQ_DOMAIN
 	help
 	  Driver to enable the bus infrastructure for the QorIQ DPAA2
@@ -18,7 +18,7 @@ config FSL_MC_BUS
 
 config FSL_MC_DPIO
         tristate "QorIQ DPAA2 DPIO driver"
-        depends on FSL_MC_BUS
+        depends on FSL_MC_BUS && ARCH_LAYERSCAPE
         help
 	  Driver for the DPAA2 DPIO object.  A DPIO provides queue and
 	  buffer management facilities for software to interact with
-- 
2.9.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH 2/7] staging: fsl-mc: use generic memory barriers
  2017-07-17 13:26 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
@ 2017-07-17 13:38   ` Robin Murphy
  2017-07-17 13:46     ` Laurentiu Tudor
  0 siblings, 1 reply; 20+ messages in thread
From: Robin Murphy @ 2017-07-17 13:38 UTC (permalink / raw)
  To: linux-arm-kernel

On 17/07/17 14:26, laurentiu.tudor at nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> 
> No need to use arch-specific memory barriers; switch to using generic
> ones. The rmb()s were useless so drop them.
> 
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
>  drivers/staging/fsl-mc/bus/mc-sys.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
> index a1704c3..012abd5 100644
> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
> @@ -127,7 +127,8 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>  	/* copy command parameters into the portal */
>  	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>  		__raw_writeq(cmd->params[i], &portal->params[i]);
> -	__iowmb();
> +	/* ensure command params are committed before submitting it */
> +	wmb();
>  
>  	/* submit the command by writing the header */
>  	__raw_writeq(cmd->header, &portal->header);

AFAICS, just using writeq() here should ensure sufficient order against
the previous iomem accessors, without the need for explicit barriers.

Also, note that the __raw_*() variants aren't endian-safe, so consider
updating things to *_relaxed() where ordering doesn't matter.

Robin.

> @@ -150,9 +151,7 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
>  	enum mc_cmd_status status;
>  
>  	/* Copy command response header from MC portal: */
> -	__iormb();
>  	resp->header = __raw_readq(&portal->header);
> -	__iormb();
>  	status = mc_cmd_hdr_read_status(resp);
>  	if (status != MC_CMD_STATUS_OK)
>  		return status;
> @@ -160,7 +159,6 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
>  	/* Copy command response data from MC portal: */
>  	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>  		resp->params[i] = __raw_readq(&portal->params[i]);
> -	__iormb();
>  
>  	return status;
>  }
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
@ 2017-07-17 13:43   ` Robin Murphy
  2017-07-17 14:53     ` Laurentiu Tudor
  2017-07-17 13:45   ` Arnd Bergmann
  1 sibling, 1 reply; 20+ messages in thread
From: Robin Murphy @ 2017-07-17 13:43 UTC (permalink / raw)
  To: linux-arm-kernel

On 17/07/17 14:26, laurentiu.tudor at nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> 
> Split the 64-bit accesses in 32-bit accesses because there's no real
> constrain in MC to do only atomic 64-bit. There's only one place
> where ordering is important: when writing the MC command header the
> first 32-bit part of the header must be written last.
> We do this switch in order to allow compiling the driver on 32-bit.

#include <linux/io-64-nonatomic-hi-lo.h>

Then you can just use writeq()/writeq_relaxed()/readq_relaxed() on
32-bit platforms as well.

Robin.

> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
>  drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>  1 file changed, 12 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
> index 195d9f3..dd2828e 100644
> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>  {
>  	int i;
>  
> -	/* copy command parameters into the portal */
> -	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
> -		__raw_writeq(cmd->params[i], &portal->params[i]);
> -	/* ensure command params are committed before submitting it */
> -	wmb();
> -
> -	/* submit the command by writing the header */
> -	__raw_writeq(cmd->header, &portal->header);
> +	/*
> +	 * copy command parameters into the portal. Final write
> +	 * triggers the submission of the command.
> +	 */
> +	for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
> +		__raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
> +		/* ensure command params are committed before submitting it */
> +		wmb();
> +	}
>  }
>  
>  /**
> @@ -148,19 +149,11 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
>  						  struct mc_command *resp)
>  {
>  	int i;
> -	enum mc_cmd_status status;
> -
> -	/* Copy command response header from MC portal: */
> -	resp->header = __raw_readq(&portal->header);
> -	status = mc_cmd_hdr_read_status(resp);
> -	if (status != MC_CMD_STATUS_OK)
> -		return status;
>  
> -	/* Copy command response data from MC portal: */
> -	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
> -		resp->params[i] = __raw_readq(&portal->params[i]);
> +	for (i = 0; i < sizeof(struct mc_command) / sizeof(u32); i++)
> +		((u32 *)resp)[i] = __raw_readl(&((u32 *)portal)[i]);
>  
> -	return status;
> +	return mc_cmd_hdr_read_status(resp);
>  }
>  
>  /**
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
  2017-07-17 13:43   ` Robin Murphy
@ 2017-07-17 13:45   ` Arnd Bergmann
  2017-07-17 14:27     ` Laurentiu Tudor
  1 sibling, 1 reply; 20+ messages in thread
From: Arnd Bergmann @ 2017-07-17 13:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> Split the 64-bit accesses in 32-bit accesses because there's no real
> constrain in MC to do only atomic 64-bit. There's only one place
> where ordering is important: when writing the MC command header the
> first 32-bit part of the header must be written last.
> We do this switch in order to allow compiling the driver on 32-bit.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
>  drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>  1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
> index 195d9f3..dd2828e 100644
> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>  {
>         int i;
>
> -       /* copy command parameters into the portal */
> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
> -               __raw_writeq(cmd->params[i], &portal->params[i]);
> -       /* ensure command params are committed before submitting it */
> -       wmb();
> -
> -       /* submit the command by writing the header */
> -       __raw_writeq(cmd->header, &portal->header);
> +       /*
> +        * copy command parameters into the portal. Final write
> +        * triggers the submission of the command.
> +        */
> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
> +               /* ensure command params are committed before submitting it */
> +               wmb();
> +       }
>  }

What is the byte order requirement on this buffer? If this is a byte string
rather than individual registers, you should probably just use
memcpy_toio(), but if these are separate registers, then using the
__raw_* accessors is still wrong, at least on kernels that have a
different byteorder from the hardware.

Also, are you sure that adding those six extra barriers has no
performance impact?

      Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 2/7] staging: fsl-mc: use generic memory barriers
  2017-07-17 13:38   ` Robin Murphy
@ 2017-07-17 13:46     ` Laurentiu Tudor
  0 siblings, 0 replies; 20+ messages in thread
From: Laurentiu Tudor @ 2017-07-17 13:46 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/17/2017 04:38 PM, Robin Murphy wrote:
> On 17/07/17 14:26, laurentiu.tudor at nxp.com wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> No need to use arch-specific memory barriers; switch to using generic
>> ones. The rmb()s were useless so drop them.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>>   drivers/staging/fsl-mc/bus/mc-sys.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>> index a1704c3..012abd5 100644
>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>> @@ -127,7 +127,8 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>   	/* copy command parameters into the portal */
>>   	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>>   		__raw_writeq(cmd->params[i], &portal->params[i]);
>> -	__iowmb();
>> +	/* ensure command params are committed before submitting it */
>> +	wmb();
>>
>>   	/* submit the command by writing the header */
>>   	__raw_writeq(cmd->header, &portal->header);
>
> AFAICS, just using writeq() here should ensure sufficient order against
> the previous iomem accessors, without the need for explicit barriers.

Endianess is handled in the callers, this function should leave the raw 
data unchanged. So the raw version was chosen on purpose.

> Also, note that the __raw_*() variants aren't endian-safe, so consider
> updating things to *_relaxed() where ordering doesn't matter.
>

That's what i tried in the first place but encountered compilation 
errors on 32-bit powerpc & 32-bit x86 having to do with writeq/readq 
variants not being available (IIRC). So that's why i switched to the 
32-bit variants in the end.

---
Thanks & Best Regards, Laurentiu

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 13:45   ` Arnd Bergmann
@ 2017-07-17 14:27     ` Laurentiu Tudor
  2017-07-17 15:00       ` Arnd Bergmann
  0 siblings, 1 reply; 20+ messages in thread
From: Laurentiu Tudor @ 2017-07-17 14:27 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Arnd,

On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Split the 64-bit accesses in 32-bit accesses because there's no real
>> constrain in MC to do only atomic 64-bit. There's only one place
>> where ordering is important: when writing the MC command header the
>> first 32-bit part of the header must be written last.
>> We do this switch in order to allow compiling the driver on 32-bit.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>>   drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>   1 file changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>> index 195d9f3..dd2828e 100644
>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>   {
>>          int i;
>>
>> -       /* copy command parameters into the portal */
>> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> -               __raw_writeq(cmd->params[i], &portal->params[i]);
>> -       /* ensure command params are committed before submitting it */
>> -       wmb();
>> -
>> -       /* submit the command by writing the header */
>> -       __raw_writeq(cmd->header, &portal->header);
>> +       /*
>> +        * copy command parameters into the portal. Final write
>> +        * triggers the submission of the command.
>> +        */
>> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>> +               /* ensure command params are committed before submitting it */
>> +               wmb();
>> +       }
>>   }
>
> What is the byte order requirement on this buffer?

Endianness is handled by the callers so this function must leave
the binary blob intact.

> If this is a byte string
> rather than individual registers, you should probably just use
> memcpy_toio()

It's a header followed by an opaque command. The protocol for queueing a 
command says that the first 32-bit half of the header must be written 
last, this triggering the command handling in the MC.

> but if these are separate registers, then using the
> __raw_* accessors is still wrong, at least on kernels that have a
> different byteorder from the hardware.

As mentioned above, endianness is handled by the caller. This function
takes raw data and must leave it unchanged.

> Also, are you sure that adding those six extra barriers has no
> performance impact?

This is a slow interface used in slow paths, so i don't think those 
extra barriers will have any performance impact.

---
Thanks & Best Regards, Laurentiu

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 13:43   ` Robin Murphy
@ 2017-07-17 14:53     ` Laurentiu Tudor
  0 siblings, 0 replies; 20+ messages in thread
From: Laurentiu Tudor @ 2017-07-17 14:53 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Robin,

On 07/17/2017 04:43 PM, Robin Murphy wrote:
> On 17/07/17 14:26, laurentiu.tudor at nxp.com wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Split the 64-bit accesses in 32-bit accesses because there's no real
>> constrain in MC to do only atomic 64-bit. There's only one place
>> where ordering is important: when writing the MC command header the
>> first 32-bit part of the header must be written last.
>> We do this switch in order to allow compiling the driver on 32-bit.
>
> #include <linux/io-64-nonatomic-hi-lo.h>
>
> Then you can just use writeq()/writeq_relaxed()/readq_relaxed() on
> 32-bit platforms as well.
>

Thanks, didn't knew of the header. This should take care of the 
compilation errors i was seeing. There's one problem though: these 
handle byte-ordering and i need raw accessors. :-(

---
Best Regards, Laurentiu

>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>>   drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>   1 file changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>> index 195d9f3..dd2828e 100644
>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>   {
>>   	int i;
>>
>> -	/* copy command parameters into the portal */
>> -	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> -		__raw_writeq(cmd->params[i], &portal->params[i]);
>> -	/* ensure command params are committed before submitting it */
>> -	wmb();
>> -
>> -	/* submit the command by writing the header */
>> -	__raw_writeq(cmd->header, &portal->header);
>> +	/*
>> +	 * copy command parameters into the portal. Final write
>> +	 * triggers the submission of the command.
>> +	 */
>> +	for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>> +		__raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>> +		/* ensure command params are committed before submitting it */
>> +		wmb();
>> +	}
>>   }
>>
>>   /**
>> @@ -148,19 +149,11 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
>>   						  struct mc_command *resp)
>>   {
>>   	int i;
>> -	enum mc_cmd_status status;
>> -
>> -	/* Copy command response header from MC portal: */
>> -	resp->header = __raw_readq(&portal->header);
>> -	status = mc_cmd_hdr_read_status(resp);
>> -	if (status != MC_CMD_STATUS_OK)
>> -		return status;
>>
>> -	/* Copy command response data from MC portal: */
>> -	for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> -		resp->params[i] = __raw_readq(&portal->params[i]);
>> +	for (i = 0; i < sizeof(struct mc_command) / sizeof(u32); i++)
>> +		((u32 *)resp)[i] = __raw_readl(&((u32 *)portal)[i]);
>>
>> -	return status;
>> +	return mc_cmd_hdr_read_status(resp);
>>   }
>>
>>   /**
>>
>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 14:27     ` Laurentiu Tudor
@ 2017-07-17 15:00       ` Arnd Bergmann
  2017-07-18 11:08         ` Laurentiu Tudor
  0 siblings, 1 reply; 20+ messages in thread
From: Arnd Bergmann @ 2017-07-17 15:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor
<laurentiu.tudor@nxp.com> wrote:
> Hi Arnd,
>
> On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
>> On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>
>>> Split the 64-bit accesses in 32-bit accesses because there's no real
>>> constrain in MC to do only atomic 64-bit. There's only one place
>>> where ordering is important: when writing the MC command header the
>>> first 32-bit part of the header must be written last.
>>> We do this switch in order to allow compiling the driver on 32-bit.
>>>
>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>> ---
>>>   drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>>   1 file changed, 12 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>>> index 195d9f3..dd2828e 100644
>>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>>   {
>>>          int i;
>>>
>>> -       /* copy command parameters into the portal */
>>> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>>> -               __raw_writeq(cmd->params[i], &portal->params[i]);
>>> -       /* ensure command params are committed before submitting it */
>>> -       wmb();
>>> -
>>> -       /* submit the command by writing the header */
>>> -       __raw_writeq(cmd->header, &portal->header);
>>> +       /*
>>> +        * copy command parameters into the portal. Final write
>>> +        * triggers the submission of the command.
>>> +        */
>>> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>>> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>>> +               /* ensure command params are committed before submitting it */
>>> +               wmb();
>>> +       }
>>>   }
>>
>> What is the byte order requirement on this buffer?
>
> Endianness is handled by the callers so this function must leave
> the binary blob intact.

Got it, the endianess looks correct indeed.

>> If this is a byte string
>> rather than individual registers, you should probably just use
>> memcpy_toio()
>
> It's a header followed by an opaque command. The protocol for queueing a
> command says that the first 32-bit half of the header must be written
> last, this triggering the command handling in the MC.

Strictly speaking the __raw_writel() won't guarantee that the
data is written as a single word, the compiler might decide to
split it up into byte-sized writes if it believes the destination pointer
is unaligned and the CPU has no efficient writes.

I think this cannot happen on arm or powerpc, as we go through
inline assembly for the store, but it's not completely portable.

Before your patch, both the compiler and the CPU could also
reorder the stores in theory (but normally won't), but the wmb()
will prevent that now.

>> but if these are separate registers, then using the
>> __raw_* accessors is still wrong, at least on kernels that have a
>> different byteorder from the hardware.
>
> As mentioned above, endianness is handled by the caller. This function
> takes raw data and must leave it unchanged.
>
>> Also, are you sure that adding those six extra barriers has no
>> performance impact?
>
> This is a slow interface used in slow paths, so i don't think those
> extra barriers will have any performance impact.

Ok.

One other problem remains: most developers looking at this
code like Robin and me will immediately think there might be
an endianess bug here. As this is a slow path, how about
using an explicit conversion using

     writeq(le64_to_cpup(buffer), pointer);

with a comment? That would explain what's going on and
escape people looking for incorrect __raw_writeq() uses.
I would expect that the compiler can actually drop the
double byteswap here by itself, and even if it doesn't,
the extra swaps won't cause noticeable overhead compared
to the barriers.

       Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-17 15:00       ` Arnd Bergmann
@ 2017-07-18 11:08         ` Laurentiu Tudor
  2017-07-18 11:39           ` Arnd Bergmann
  0 siblings, 1 reply; 20+ messages in thread
From: Laurentiu Tudor @ 2017-07-18 11:08 UTC (permalink / raw)
  To: linux-arm-kernel



On 07/17/2017 06:00 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor
> <laurentiu.tudor@nxp.com> wrote:
>> Hi Arnd,
>>
>> On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
>>> On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>
>>>> Split the 64-bit accesses in 32-bit accesses because there's no real
>>>> constrain in MC to do only atomic 64-bit. There's only one place
>>>> where ordering is important: when writing the MC command header the
>>>> first 32-bit part of the header must be written last.
>>>> We do this switch in order to allow compiling the driver on 32-bit.
>>>>
>>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>> ---
>>>>    drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>>>    1 file changed, 12 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>>>> index 195d9f3..dd2828e 100644
>>>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>>>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>>>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>>>    {
>>>>           int i;
>>>>
>>>> -       /* copy command parameters into the portal */
>>>> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>>>> -               __raw_writeq(cmd->params[i], &portal->params[i]);
>>>> -       /* ensure command params are committed before submitting it */
>>>> -       wmb();
>>>> -
>>>> -       /* submit the command by writing the header */
>>>> -       __raw_writeq(cmd->header, &portal->header);
>>>> +       /*
>>>> +        * copy command parameters into the portal. Final write
>>>> +        * triggers the submission of the command.
>>>> +        */
>>>> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>>>> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>>>> +               /* ensure command params are committed before submitting it */
>>>> +               wmb();
>>>> +       }
>>>>    }
>>>
>>> What is the byte order requirement on this buffer?
>>
>> Endianness is handled by the callers so this function must leave
>> the binary blob intact.
>
> Got it, the endianess looks correct indeed.
>
>>> If this is a byte string
>>> rather than individual registers, you should probably just use
>>> memcpy_toio()
>>
>> It's a header followed by an opaque command. The protocol for queueing a
>> command says that the first 32-bit half of the header must be written
>> last, this triggering the command handling in the MC.
>
> Strictly speaking the __raw_writel() won't guarantee that the
> data is written as a single word, the compiler might decide to
> split it up into byte-sized writes if it believes the destination pointer
> is unaligned and the CPU has no efficient writes.
>
> I think this cannot happen on arm or powerpc, as we go through
> inline assembly for the store, but it's not completely portable.

Should i worry about portability? Slim changes that this driver
will ever run on anything else other than ARM & ARM64.
My current goal was just to make it compile on other arches.

> Before your patch, both the compiler and the CPU could also
> reorder the stores in theory (but normally won't), but the wmb()
> will prevent that now.

Ok, thanks for the info.

>>> but if these are separate registers, then using the
>>> __raw_* accessors is still wrong, at least on kernels that have a
>>> different byteorder from the hardware.
>>
>> As mentioned above, endianness is handled by the caller. This function
>> takes raw data and must leave it unchanged.
>>
>>> Also, are you sure that adding those six extra barriers has no
>>> performance impact?
>>
>> This is a slow interface used in slow paths, so i don't think those
>> extra barriers will have any performance impact.
>
> Ok.
>
> One other problem remains: most developers looking at this
> code like Robin and me will immediately think there might be
> an endianess bug here. As this is a slow path, how about
> using an explicit conversion using
>
>       writeq(le64_to_cpup(buffer), pointer);

Sure, sounds perfect. I'll do that in the next respin.

---
Thanks & Best Regards, Laurentiu

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
  2017-07-18 11:08         ` Laurentiu Tudor
@ 2017-07-18 11:39           ` Arnd Bergmann
  0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2017-07-18 11:39 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jul 18, 2017 at 1:08 PM, Laurentiu Tudor
<laurentiu.tudor@nxp.com> wrote:
> On 07/17/2017 06:00 PM, Arnd Bergmann wrote:

>> Strictly speaking the __raw_writel() won't guarantee that the
>> data is written as a single word, the compiler might decide to
>> split it up into byte-sized writes if it believes the destination pointer
>> is unaligned and the CPU has no efficient writes.
>>
>> I think this cannot happen on arm or powerpc, as we go through
>> inline assembly for the store, but it's not completely portable.
>
> Should i worry about portability? Slim changes that this driver
> will ever run on anything else other than ARM & ARM64.
> My current goal was just to make it compile on other arches.

I always recommend writing any driver in the most portable way
out of principle, since you never know who looks at it for reference
when writing another driver.

I wouldn't expect the driver itself to be used on other architectures,
but of course you never know what CPU becomes fashionable
10 years from now.

        Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch
  2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
@ 2017-07-19 16:09   ` kbuild test robot
  2017-07-19 17:31   ` kbuild test robot
  1 sibling, 0 replies; 20+ messages in thread
From: kbuild test robot @ 2017-07-19 16:09 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Laurentiu,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc1 next-20170718]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/laurentiu-tudor-nxp-com/staging-fsl-mc-make-the-driver-compile-on-other-architectures/20170718-021715
config: cris-allyesconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 6.2.0
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=cris 

All errors (new ones prefixed by >>):

   In file included from drivers/staging/fsl-mc/bus/fsl-mc-bus.c:21:0:
>> include/linux/msi.h:196:21: fatal error: asm/msi.h: No such file or directory
    #include <asm/msi.h>
                        ^
   compilation terminated.

vim +196 include/linux/msi.h

d9109698 Jiang Liu 2014-11-15  194  
aeeb5965 Jiang Liu 2014-11-15  195  #include <linux/irqhandler.h>
d9109698 Jiang Liu 2014-11-15 @196  #include <asm/msi.h>
d9109698 Jiang Liu 2014-11-15  197  

:::::: The code at line 196 was first introduced by commit
:::::: d9109698be6e7439e6082aa00d79d4556114739b genirq: Introduce msi_domain_alloc/free_irqs()

:::::: TO: Jiang Liu <jiang.liu@linux.intel.com>
:::::: CC: Thomas Gleixner <tglx@linutronix.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43210 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170720/1d79ecc5/attachment-0001.gz>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch
  2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
  2017-07-19 16:09   ` kbuild test robot
@ 2017-07-19 17:31   ` kbuild test robot
  2017-07-20 13:47     ` Laurentiu Tudor
  1 sibling, 1 reply; 20+ messages in thread
From: kbuild test robot @ 2017-07-19 17:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Laurentiu,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc1 next-20170718]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/laurentiu-tudor-nxp-com/staging-fsl-mc-make-the-driver-compile-on-other-architectures/20170718-021715
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=sparc 

All error/warnings (new ones prefixed by >>):

   In file included from kernel/irq/chip.c:14:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
--
   In file included from kernel/irq/msi.c:16:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
   kernel/irq/msi.c: In function 'msi_domain_alloc':
>> kernel/irq/msi.c:126:29: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
     irq_hw_number_t hwirq = ops->get_hwirq(info, arg);
                                ^~
>> kernel/irq/msi.c:139:12: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
               ^~
   kernel/irq/msi.c: At top level:
>> kernel/irq/msi.c:201:11: error: unknown type name 'msi_alloc_info_t'
              msi_alloc_info_t *arg)
              ^~~~~~~~~~~~~~~~
>> kernel/irq/msi.c:221:2: error: unknown field 'get_hwirq' specified in initializer
     .get_hwirq = msi_domain_ops_get_hwirq,
     ^
>> kernel/irq/msi.c:222:2: error: unknown field 'msi_init' specified in initializer
     .msi_init = msi_domain_ops_init,
     ^
>> kernel/irq/msi.c:222:14: error: 'msi_domain_ops_init' undeclared here (not in a function)
     .msi_init = msi_domain_ops_init,
                 ^~~~~~~~~~~~~~~~~~~
>> kernel/irq/msi.c:224:2: error: unknown field 'msi_prepare' specified in initializer
     .msi_prepare = msi_domain_ops_prepare,
     ^
>> kernel/irq/msi.c:225:2: error: unknown field 'set_desc' specified in initializer
     .set_desc = msi_domain_ops_set_desc,
     ^
   In file included from include/uapi/linux/posix_types.h:4:0,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from kernel/irq/msi.c:12:
   include/linux/stddef.h:7:14: warning: excess elements in struct initializer
    #define NULL ((void *)0)
                 ^
>> kernel/irq/msi.c:195:34: note: in expansion of macro 'NULL'
    #define msi_domain_ops_set_desc  NULL
                                     ^~~~
>> kernel/irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
     .set_desc = msi_domain_ops_set_desc,
                 ^~~~~~~~~~~~~~~~~~~~~~~
   include/linux/stddef.h:7:14: note: (near initialization for 'msi_domain_ops_default')
    #define NULL ((void *)0)
                 ^
>> kernel/irq/msi.c:195:34: note: in expansion of macro 'NULL'
    #define msi_domain_ops_set_desc  NULL
                                     ^~~~
>> kernel/irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
     .set_desc = msi_domain_ops_set_desc,
                 ^~~~~~~~~~~~~~~~~~~~~~~
   kernel/irq/msi.c: In function 'msi_domain_update_dom_ops':
   kernel/irq/msi.c:237:9: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
     if (ops->get_hwirq == NULL)
            ^~
   kernel/irq/msi.c:238:6: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
      ops->get_hwirq = msi_domain_ops_default.get_hwirq;
         ^~
   kernel/irq/msi.c:238:42: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
      ops->get_hwirq = msi_domain_ops_default.get_hwirq;
                                             ^
   kernel/irq/msi.c:239:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
     if (ops->msi_init == NULL)
            ^~
   kernel/irq/msi.c:240:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ops->msi_init = msi_domain_ops_default.msi_init;
         ^~
   kernel/irq/msi.c:240:41: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ops->msi_init = msi_domain_ops_default.msi_init;
                                            ^
>> kernel/irq/msi.c:243:9: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
     if (ops->msi_prepare == NULL)
            ^~
   kernel/irq/msi.c:244:6: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
      ops->msi_prepare = msi_domain_ops_default.msi_prepare;
         ^~
   kernel/irq/msi.c:244:44: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
      ops->msi_prepare = msi_domain_ops_default.msi_prepare;
                                               ^
>> kernel/irq/msi.c:245:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
     if (ops->set_desc == NULL)
            ^~
   kernel/irq/msi.c:246:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
      ops->set_desc = msi_domain_ops_default.set_desc;
         ^~
   kernel/irq/msi.c:246:41: error: 'struct msi_domain_ops' has no member named 'set_desc'
      ops->set_desc = msi_domain_ops_default.set_desc;
                                            ^
   kernel/irq/msi.c: At top level:
   kernel/irq/msi.c:285:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *arg)
                     ^~~~~~~~~~~~~~~~
   kernel/irq/msi.c:299:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *arg)
                                ^~~~~~~~~~~~~~~~
   kernel/irq/msi.c: In function 'msi_domain_alloc_irqs':
   kernel/irq/msi.c:352:2: error: unknown type name 'msi_alloc_info_t'
     msi_alloc_info_t arg;
     ^~~~~~~~~~~~~~~~
>> kernel/irq/msi.c:356:8: error: implicit declaration of function 'msi_domain_prepare_irqs' [-Werror=implicit-function-declaration]
     ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
           ^~~~~~~~~~~~~~~~~~~~~~~
   kernel/irq/msi.c:361:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
      ops->set_desc(&arg, desc);
         ^~
>> kernel/irq/msi.c:370:11: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
       if (ops->msi_finish)
              ^~
   kernel/irq/msi.c:371:8: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
        ops->msi_finish(&arg, ret);
           ^~
   kernel/irq/msi.c:379:9: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
     if (ops->msi_finish)
            ^~
   kernel/irq/msi.c:380:6: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
      ops->msi_finish(&arg, 0);
         ^~
   cc1: some warnings being treated as errors
--
   In file included from drivers//staging/fsl-mc/bus/fsl-mc-msi.c:17:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
   drivers//staging/fsl-mc/bus/fsl-mc-msi.c: In function 'fsl_mc_msi_update_dom_ops':
>> drivers//staging/fsl-mc/bus/fsl-mc-msi.c:56:10: error: 'struct msi_domain_ops' has no member named 'set_desc'
     if (!ops->set_desc)
             ^~
   drivers//staging/fsl-mc/bus/fsl-mc-msi.c:57:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
      ops->set_desc = fsl_mc_msi_set_desc;
         ^~
--
   In file included from drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:15:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:30:17: error: unknown type name 'msi_alloc_info_t'
          int nvec, msi_alloc_info_t *info)
                    ^~~~~~~~~~~~~~~~
>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:56:2: error: unknown field 'msi_prepare' specified in initializer
     .msi_prepare = its_fsl_mc_msi_prepare,
     ^
>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:56:17: error: 'its_fsl_mc_msi_prepare' undeclared here (not in a function)
     .msi_prepare = its_fsl_mc_msi_prepare,
                    ^~~~~~~~~~~~~~~~~~~~~~
--
   In file included from drivers//base/platform-msi.c:24:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
>> drivers//base/platform-msi.c:37:2: error: unknown type name 'msi_alloc_info_t'
     msi_alloc_info_t arg;
     ^~~~~~~~~~~~~~~~
   drivers//base/platform-msi.c: In function 'platform_msi_update_dom_ops':
>> drivers//base/platform-msi.c:84:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
     if (ops->msi_init == NULL)
            ^~
   drivers//base/platform-msi.c:85:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ops->msi_init = platform_msi_init;
         ^~
>> drivers//base/platform-msi.c:86:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
     if (ops->set_desc == NULL)
            ^~
   drivers//base/platform-msi.c:87:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
      ops->set_desc = platform_msi_set_desc;
         ^~
   drivers//base/platform-msi.c: In function 'platform_msi_create_device_domain':
>> drivers//base/platform-msi.c:352:8: error: implicit declaration of function 'msi_domain_prepare_irqs' [-Werror=implicit-function-declaration]
     err = msi_domain_prepare_irqs(domain->parent, dev, nvec, &data->arg);
           ^~~~~~~~~~~~~~~~~~~~~~~
   drivers//base/platform-msi.c: In function 'platform_msi_domain_alloc':
>> drivers//base/platform-msi.c:410:8: error: implicit declaration of function 'msi_domain_populate_irqs' [-Werror=implicit-function-declaration]
     err = msi_domain_populate_irqs(domain->parent, data->dev,
           ^~~~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from kernel//irq/msi.c:16:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^~~~~~~~~~~~~~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^~~~~~~~~~~~~~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^~~~~~~~~~~~~~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^~~~~~~~~~~~~~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^~~~~~~~~~~~~~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^~~~~~~~~~~~~~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^~~~~~~~~~~~~~~~
   kernel//irq/msi.c: In function 'msi_domain_alloc':
   kernel//irq/msi.c:126:29: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
     irq_hw_number_t hwirq = ops->get_hwirq(info, arg);
                                ^~
   kernel//irq/msi.c:139:12: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
               ^~
   kernel//irq/msi.c: At top level:
   kernel//irq/msi.c:201:11: error: unknown type name 'msi_alloc_info_t'
              msi_alloc_info_t *arg)
              ^~~~~~~~~~~~~~~~
   kernel//irq/msi.c:221:2: error: unknown field 'get_hwirq' specified in initializer
     .get_hwirq = msi_domain_ops_get_hwirq,
     ^
   kernel//irq/msi.c:222:2: error: unknown field 'msi_init' specified in initializer
     .msi_init = msi_domain_ops_init,
     ^
   kernel//irq/msi.c:222:14: error: 'msi_domain_ops_init' undeclared here (not in a function)
     .msi_init = msi_domain_ops_init,
                 ^~~~~~~~~~~~~~~~~~~
   kernel//irq/msi.c:224:2: error: unknown field 'msi_prepare' specified in initializer
     .msi_prepare = msi_domain_ops_prepare,
     ^
   kernel//irq/msi.c:225:2: error: unknown field 'set_desc' specified in initializer
     .set_desc = msi_domain_ops_set_desc,
     ^
   In file included from include/uapi/linux/posix_types.h:4:0,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from kernel//irq/msi.c:12:
   include/linux/stddef.h:7:14: warning: excess elements in struct initializer
    #define NULL ((void *)0)
                 ^
   kernel//irq/msi.c:195:34: note: in expansion of macro 'NULL'
    #define msi_domain_ops_set_desc  NULL
                                     ^~~~
   kernel//irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
     .set_desc = msi_domain_ops_set_desc,
                 ^~~~~~~~~~~~~~~~~~~~~~~
   include/linux/stddef.h:7:14: note: (near initialization for 'msi_domain_ops_default')
    #define NULL ((void *)0)
                 ^
   kernel//irq/msi.c:195:34: note: in expansion of macro 'NULL'
    #define msi_domain_ops_set_desc  NULL
                                     ^~~~
   kernel//irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
     .set_desc = msi_domain_ops_set_desc,
                 ^~~~~~~~~~~~~~~~~~~~~~~
   kernel//irq/msi.c: In function 'msi_domain_update_dom_ops':
   kernel//irq/msi.c:237:9: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
     if (ops->get_hwirq == NULL)
            ^~
   kernel//irq/msi.c:238:6: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
      ops->get_hwirq = msi_domain_ops_default.get_hwirq;
         ^~
   kernel//irq/msi.c:238:42: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
      ops->get_hwirq = msi_domain_ops_default.get_hwirq;
                                             ^
   kernel//irq/msi.c:239:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
     if (ops->msi_init == NULL)
            ^~
   kernel//irq/msi.c:240:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ops->msi_init = msi_domain_ops_default.msi_init;
         ^~
   kernel//irq/msi.c:240:41: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
      ops->msi_init = msi_domain_ops_default.msi_init;
                                            ^
   kernel//irq/msi.c:243:9: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
     if (ops->msi_prepare == NULL)
            ^~
   kernel//irq/msi.c:244:6: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
      ops->msi_prepare = msi_domain_ops_default.msi_prepare;
         ^~
   kernel//irq/msi.c:244:44: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
      ops->msi_prepare = msi_domain_ops_default.msi_prepare;
                                               ^
   kernel//irq/msi.c:245:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
     if (ops->set_desc == NULL)
            ^~
   kernel//irq/msi.c:246:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
..

vim +/msi_alloc_info_t +225 include/linux/msi.h

f3cf8bb0 Jiang Liu        2014-11-12  204  
f3cf8bb0 Jiang Liu        2014-11-12  205  /**
f3cf8bb0 Jiang Liu        2014-11-12  206   * struct msi_domain_ops - MSI interrupt domain callbacks
f3cf8bb0 Jiang Liu        2014-11-12  207   * @get_hwirq:		Retrieve the resulting hw irq number
f3cf8bb0 Jiang Liu        2014-11-12  208   * @msi_init:		Domain specific init function for MSI interrupts
f3cf8bb0 Jiang Liu        2014-11-12  209   * @msi_free:		Domain specific function to free a MSI interrupts
d9109698 Jiang Liu        2014-11-15  210   * @msi_check:		Callback for verification of the domain/info/dev data
d9109698 Jiang Liu        2014-11-15  211   * @msi_prepare:	Prepare the allocation of the interrupts in the domain
1d1e8cdc Thomas Petazzoni 2015-12-21  212   * @msi_finish:		Optional callback to finalize the allocation
d9109698 Jiang Liu        2014-11-15  213   * @set_desc:		Set the msi descriptor for an interrupt
d9109698 Jiang Liu        2014-11-15  214   * @handle_error:	Optional error handler if the allocation fails
d9109698 Jiang Liu        2014-11-15  215   *
d9109698 Jiang Liu        2014-11-15  216   * @get_hwirq, @msi_init and @msi_free are callbacks used by
d9109698 Jiang Liu        2014-11-15  217   * msi_create_irq_domain() and related interfaces
d9109698 Jiang Liu        2014-11-15  218   *
d9109698 Jiang Liu        2014-11-15  219   * @msi_check, @msi_prepare, @msi_finish, @set_desc and @handle_error
1d1e8cdc Thomas Petazzoni 2015-12-21  220   * are callbacks used by msi_domain_alloc_irqs() and related
d9109698 Jiang Liu        2014-11-15  221   * interfaces which are based on msi_desc.
f3cf8bb0 Jiang Liu        2014-11-12  222   */
f3cf8bb0 Jiang Liu        2014-11-12  223  struct msi_domain_ops {
aeeb5965 Jiang Liu        2014-11-15  224  	irq_hw_number_t	(*get_hwirq)(struct msi_domain_info *info,
aeeb5965 Jiang Liu        2014-11-15 @225  				     msi_alloc_info_t *arg);
f3cf8bb0 Jiang Liu        2014-11-12  226  	int		(*msi_init)(struct irq_domain *domain,
f3cf8bb0 Jiang Liu        2014-11-12  227  				    struct msi_domain_info *info,
f3cf8bb0 Jiang Liu        2014-11-12  228  				    unsigned int virq, irq_hw_number_t hwirq,
aeeb5965 Jiang Liu        2014-11-15  229  				    msi_alloc_info_t *arg);
f3cf8bb0 Jiang Liu        2014-11-12  230  	void		(*msi_free)(struct irq_domain *domain,
f3cf8bb0 Jiang Liu        2014-11-12  231  				    struct msi_domain_info *info,
f3cf8bb0 Jiang Liu        2014-11-12  232  				    unsigned int virq);
d9109698 Jiang Liu        2014-11-15  233  	int		(*msi_check)(struct irq_domain *domain,
d9109698 Jiang Liu        2014-11-15  234  				     struct msi_domain_info *info,
d9109698 Jiang Liu        2014-11-15  235  				     struct device *dev);
d9109698 Jiang Liu        2014-11-15  236  	int		(*msi_prepare)(struct irq_domain *domain,
d9109698 Jiang Liu        2014-11-15  237  				       struct device *dev, int nvec,
d9109698 Jiang Liu        2014-11-15  238  				       msi_alloc_info_t *arg);
d9109698 Jiang Liu        2014-11-15  239  	void		(*msi_finish)(msi_alloc_info_t *arg, int retval);
d9109698 Jiang Liu        2014-11-15  240  	void		(*set_desc)(msi_alloc_info_t *arg,
d9109698 Jiang Liu        2014-11-15  241  				    struct msi_desc *desc);
d9109698 Jiang Liu        2014-11-15  242  	int		(*handle_error)(struct irq_domain *domain,
d9109698 Jiang Liu        2014-11-15  243  					struct msi_desc *desc, int error);
f3cf8bb0 Jiang Liu        2014-11-12  244  };
f3cf8bb0 Jiang Liu        2014-11-12  245  

:::::: The code at line 225 was first introduced by commit
:::::: aeeb59657c35da64068336c20068da237f41ab76 genirq: Provide default callbacks for msi_domain_ops

:::::: TO: Jiang Liu <jiang.liu@linux.intel.com>
:::::: CC: Thomas Gleixner <tglx@linutronix.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 51491 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170720/9560d1e2/attachment-0001.gz>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch
  2017-07-19 17:31   ` kbuild test robot
@ 2017-07-20 13:47     ` Laurentiu Tudor
  0 siblings, 0 replies; 20+ messages in thread
From: Laurentiu Tudor @ 2017-07-20 13:47 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

Sparc seems to be broken in multiple places, including generic code.
Is this a known issue?
Is there something I could/should do?

---
Thanks & Best Regards, Laurentiu

On 07/19/2017 08:31 PM, kbuild test robot wrote:
> Hi Laurentiu,
>
> [auto build test ERROR on staging/staging-testing]
> [also build test ERROR on v4.13-rc1 next-20170718]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url:    https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommits%2Flaurentiu-tudor-nxp-com%2Fstaging-fsl-mc-make-the-driver-compile-on-other-architectures%2F20170718-021715&data=01%7C01%7Claurentiu.tudor%40nxp.com%7C66f7c5619d664f88ce6108d4cecc14f5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=HgKrckHRkhwe6PrGHc%2B1UfoT1rCyMw5C5%2B7wdEuvS5s%3D&reserved=0
> config: sparc-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>          wget https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2F01org%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=01%7C01%7Claurentiu.tudor%40nxp.com%7C66f7c5619d664f88ce6108d4cecc14f5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=kFjtWysm4LCK%2BnLcmpogI%2FHRRApSDRcl7QWofLo0%2FDY%3D&reserved=0 -O ~/bin/make.cross
>          chmod +x ~/bin/make.cross
>          # save the attached .config to linux build tree
>          make.cross ARCH=sparc
>
> All error/warnings (new ones prefixed by >>):
>
>     In file included from kernel/irq/chip.c:14:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
> --
>     In file included from kernel/irq/msi.c:16:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
>     kernel/irq/msi.c: In function 'msi_domain_alloc':
>>> kernel/irq/msi.c:126:29: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>       irq_hw_number_t hwirq = ops->get_hwirq(info, arg);
>                                  ^~
>>> kernel/irq/msi.c:139:12: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
>                 ^~
>     kernel/irq/msi.c: At top level:
>>> kernel/irq/msi.c:201:11: error: unknown type name 'msi_alloc_info_t'
>                msi_alloc_info_t *arg)
>                ^~~~~~~~~~~~~~~~
>>> kernel/irq/msi.c:221:2: error: unknown field 'get_hwirq' specified in initializer
>       .get_hwirq = msi_domain_ops_get_hwirq,
>       ^
>>> kernel/irq/msi.c:222:2: error: unknown field 'msi_init' specified in initializer
>       .msi_init = msi_domain_ops_init,
>       ^
>>> kernel/irq/msi.c:222:14: error: 'msi_domain_ops_init' undeclared here (not in a function)
>       .msi_init = msi_domain_ops_init,
>                   ^~~~~~~~~~~~~~~~~~~
>>> kernel/irq/msi.c:224:2: error: unknown field 'msi_prepare' specified in initializer
>       .msi_prepare = msi_domain_ops_prepare,
>       ^
>>> kernel/irq/msi.c:225:2: error: unknown field 'set_desc' specified in initializer
>       .set_desc = msi_domain_ops_set_desc,
>       ^
>     In file included from include/uapi/linux/posix_types.h:4:0,
>                      from include/uapi/linux/types.h:13,
>                      from include/linux/types.h:5,
>                      from kernel/irq/msi.c:12:
>     include/linux/stddef.h:7:14: warning: excess elements in struct initializer
>      #define NULL ((void *)0)
>                   ^
>>> kernel/irq/msi.c:195:34: note: in expansion of macro 'NULL'
>      #define msi_domain_ops_set_desc  NULL
>                                       ^~~~
>>> kernel/irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
>       .set_desc = msi_domain_ops_set_desc,
>                   ^~~~~~~~~~~~~~~~~~~~~~~
>     include/linux/stddef.h:7:14: note: (near initialization for 'msi_domain_ops_default')
>      #define NULL ((void *)0)
>                   ^
>>> kernel/irq/msi.c:195:34: note: in expansion of macro 'NULL'
>      #define msi_domain_ops_set_desc  NULL
>                                       ^~~~
>>> kernel/irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
>       .set_desc = msi_domain_ops_set_desc,
>                   ^~~~~~~~~~~~~~~~~~~~~~~
>     kernel/irq/msi.c: In function 'msi_domain_update_dom_ops':
>     kernel/irq/msi.c:237:9: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>       if (ops->get_hwirq == NULL)
>              ^~
>     kernel/irq/msi.c:238:6: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>        ops->get_hwirq = msi_domain_ops_default.get_hwirq;
>           ^~
>     kernel/irq/msi.c:238:42: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>        ops->get_hwirq = msi_domain_ops_default.get_hwirq;
>                                               ^
>     kernel/irq/msi.c:239:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>       if (ops->msi_init == NULL)
>              ^~
>     kernel/irq/msi.c:240:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ops->msi_init = msi_domain_ops_default.msi_init;
>           ^~
>     kernel/irq/msi.c:240:41: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ops->msi_init = msi_domain_ops_default.msi_init;
>                                              ^
>>> kernel/irq/msi.c:243:9: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>       if (ops->msi_prepare == NULL)
>              ^~
>     kernel/irq/msi.c:244:6: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>        ops->msi_prepare = msi_domain_ops_default.msi_prepare;
>           ^~
>     kernel/irq/msi.c:244:44: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>        ops->msi_prepare = msi_domain_ops_default.msi_prepare;
>                                                 ^
>>> kernel/irq/msi.c:245:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
>       if (ops->set_desc == NULL)
>              ^~
>     kernel/irq/msi.c:246:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
>        ops->set_desc = msi_domain_ops_default.set_desc;
>           ^~
>     kernel/irq/msi.c:246:41: error: 'struct msi_domain_ops' has no member named 'set_desc'
>        ops->set_desc = msi_domain_ops_default.set_desc;
>                                              ^
>     kernel/irq/msi.c: At top level:
>     kernel/irq/msi.c:285:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *arg)
>                       ^~~~~~~~~~~~~~~~
>     kernel/irq/msi.c:299:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *arg)
>                                  ^~~~~~~~~~~~~~~~
>     kernel/irq/msi.c: In function 'msi_domain_alloc_irqs':
>     kernel/irq/msi.c:352:2: error: unknown type name 'msi_alloc_info_t'
>       msi_alloc_info_t arg;
>       ^~~~~~~~~~~~~~~~
>>> kernel/irq/msi.c:356:8: error: implicit declaration of function 'msi_domain_prepare_irqs' [-Werror=implicit-function-declaration]
>       ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
>             ^~~~~~~~~~~~~~~~~~~~~~~
>     kernel/irq/msi.c:361:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
>        ops->set_desc(&arg, desc);
>           ^~
>>> kernel/irq/msi.c:370:11: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
>         if (ops->msi_finish)
>                ^~
>     kernel/irq/msi.c:371:8: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
>          ops->msi_finish(&arg, ret);
>             ^~
>     kernel/irq/msi.c:379:9: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
>       if (ops->msi_finish)
>              ^~
>     kernel/irq/msi.c:380:6: error: 'struct msi_domain_ops' has no member named 'msi_finish'; did you mean 'msi_free'?
>        ops->msi_finish(&arg, 0);
>           ^~
>     cc1: some warnings being treated as errors
> --
>     In file included from drivers//staging/fsl-mc/bus/fsl-mc-msi.c:17:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
>     drivers//staging/fsl-mc/bus/fsl-mc-msi.c: In function 'fsl_mc_msi_update_dom_ops':
>>> drivers//staging/fsl-mc/bus/fsl-mc-msi.c:56:10: error: 'struct msi_domain_ops' has no member named 'set_desc'
>       if (!ops->set_desc)
>               ^~
>     drivers//staging/fsl-mc/bus/fsl-mc-msi.c:57:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
>        ops->set_desc = fsl_mc_msi_set_desc;
>           ^~
> --
>     In file included from drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:15:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
>>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:30:17: error: unknown type name 'msi_alloc_info_t'
>            int nvec, msi_alloc_info_t *info)
>                      ^~~~~~~~~~~~~~~~
>>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:56:2: error: unknown field 'msi_prepare' specified in initializer
>       .msi_prepare = its_fsl_mc_msi_prepare,
>       ^
>>> drivers//staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c:56:17: error: 'its_fsl_mc_msi_prepare' undeclared here (not in a function)
>       .msi_prepare = its_fsl_mc_msi_prepare,
>                      ^~~~~~~~~~~~~~~~~~~~~~
> --
>     In file included from drivers//base/platform-msi.c:24:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
>>> drivers//base/platform-msi.c:37:2: error: unknown type name 'msi_alloc_info_t'
>       msi_alloc_info_t arg;
>       ^~~~~~~~~~~~~~~~
>     drivers//base/platform-msi.c: In function 'platform_msi_update_dom_ops':
>>> drivers//base/platform-msi.c:84:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>       if (ops->msi_init == NULL)
>              ^~
>     drivers//base/platform-msi.c:85:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ops->msi_init = platform_msi_init;
>           ^~
>>> drivers//base/platform-msi.c:86:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
>       if (ops->set_desc == NULL)
>              ^~
>     drivers//base/platform-msi.c:87:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
>        ops->set_desc = platform_msi_set_desc;
>           ^~
>     drivers//base/platform-msi.c: In function 'platform_msi_create_device_domain':
>>> drivers//base/platform-msi.c:352:8: error: implicit declaration of function 'msi_domain_prepare_irqs' [-Werror=implicit-function-declaration]
>       err = msi_domain_prepare_irqs(domain->parent, dev, nvec, &data->arg);
>             ^~~~~~~~~~~~~~~~~~~~~~~
>     drivers//base/platform-msi.c: In function 'platform_msi_domain_alloc':
>>> drivers//base/platform-msi.c:410:8: error: implicit declaration of function 'msi_domain_populate_irqs' [-Werror=implicit-function-declaration]
>       err = msi_domain_populate_irqs(domain->parent, data->dev,
>             ^~~~~~~~~~~~~~~~~~~~~~~~
>     cc1: some warnings being treated as errors
> --
>     In file included from kernel//irq/msi.c:16:0:
>>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
>               msi_alloc_info_t *arg);
>               ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
>              msi_alloc_info_t *arg);
>              ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
>                 msi_alloc_info_t *arg);
>                 ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
>       void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
>                           ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
>       void  (*set_desc)(msi_alloc_info_t *arg,
>                         ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
>             int nvec, msi_alloc_info_t *args);
>                       ^~~~~~~~~~~~~~~~
>     include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
>              int virq, int nvec, msi_alloc_info_t *args);
>                                  ^~~~~~~~~~~~~~~~
>     kernel//irq/msi.c: In function 'msi_domain_alloc':
>     kernel//irq/msi.c:126:29: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>       irq_hw_number_t hwirq = ops->get_hwirq(info, arg);
>                                  ^~
>     kernel//irq/msi.c:139:12: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
>                 ^~
>     kernel//irq/msi.c: At top level:
>     kernel//irq/msi.c:201:11: error: unknown type name 'msi_alloc_info_t'
>                msi_alloc_info_t *arg)
>                ^~~~~~~~~~~~~~~~
>     kernel//irq/msi.c:221:2: error: unknown field 'get_hwirq' specified in initializer
>       .get_hwirq = msi_domain_ops_get_hwirq,
>       ^
>     kernel//irq/msi.c:222:2: error: unknown field 'msi_init' specified in initializer
>       .msi_init = msi_domain_ops_init,
>       ^
>     kernel//irq/msi.c:222:14: error: 'msi_domain_ops_init' undeclared here (not in a function)
>       .msi_init = msi_domain_ops_init,
>                   ^~~~~~~~~~~~~~~~~~~
>     kernel//irq/msi.c:224:2: error: unknown field 'msi_prepare' specified in initializer
>       .msi_prepare = msi_domain_ops_prepare,
>       ^
>     kernel//irq/msi.c:225:2: error: unknown field 'set_desc' specified in initializer
>       .set_desc = msi_domain_ops_set_desc,
>       ^
>     In file included from include/uapi/linux/posix_types.h:4:0,
>                      from include/uapi/linux/types.h:13,
>                      from include/linux/types.h:5,
>                      from kernel//irq/msi.c:12:
>     include/linux/stddef.h:7:14: warning: excess elements in struct initializer
>      #define NULL ((void *)0)
>                   ^
>     kernel//irq/msi.c:195:34: note: in expansion of macro 'NULL'
>      #define msi_domain_ops_set_desc  NULL
>                                       ^~~~
>     kernel//irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
>       .set_desc = msi_domain_ops_set_desc,
>                   ^~~~~~~~~~~~~~~~~~~~~~~
>     include/linux/stddef.h:7:14: note: (near initialization for 'msi_domain_ops_default')
>      #define NULL ((void *)0)
>                   ^
>     kernel//irq/msi.c:195:34: note: in expansion of macro 'NULL'
>      #define msi_domain_ops_set_desc  NULL
>                                       ^~~~
>     kernel//irq/msi.c:225:14: note: in expansion of macro 'msi_domain_ops_set_desc'
>       .set_desc = msi_domain_ops_set_desc,
>                   ^~~~~~~~~~~~~~~~~~~~~~~
>     kernel//irq/msi.c: In function 'msi_domain_update_dom_ops':
>     kernel//irq/msi.c:237:9: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>       if (ops->get_hwirq == NULL)
>              ^~
>     kernel//irq/msi.c:238:6: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>        ops->get_hwirq = msi_domain_ops_default.get_hwirq;
>           ^~
>     kernel//irq/msi.c:238:42: error: 'struct msi_domain_ops' has no member named 'get_hwirq'
>        ops->get_hwirq = msi_domain_ops_default.get_hwirq;
>                                               ^
>     kernel//irq/msi.c:239:9: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>       if (ops->msi_init == NULL)
>              ^~
>     kernel//irq/msi.c:240:6: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ops->msi_init = msi_domain_ops_default.msi_init;
>           ^~
>     kernel//irq/msi.c:240:41: error: 'struct msi_domain_ops' has no member named 'msi_init'; did you mean 'msi_free'?
>        ops->msi_init = msi_domain_ops_default.msi_init;
>                                              ^
>     kernel//irq/msi.c:243:9: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>       if (ops->msi_prepare == NULL)
>              ^~
>     kernel//irq/msi.c:244:6: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>        ops->msi_prepare = msi_domain_ops_default.msi_prepare;
>           ^~
>     kernel//irq/msi.c:244:44: error: 'struct msi_domain_ops' has no member named 'msi_prepare'; did you mean 'msi_free'?
>        ops->msi_prepare = msi_domain_ops_default.msi_prepare;
>                                                 ^
>     kernel//irq/msi.c:245:9: error: 'struct msi_domain_ops' has no member named 'set_desc'
>       if (ops->set_desc == NULL)
>              ^~
>     kernel//irq/msi.c:246:6: error: 'struct msi_domain_ops' has no member named 'set_desc'
> ..
>
> vim +/msi_alloc_info_t +225 include/linux/msi.h
>
> f3cf8bb0 Jiang Liu        2014-11-12  204
> f3cf8bb0 Jiang Liu        2014-11-12  205  /**
> f3cf8bb0 Jiang Liu        2014-11-12  206   * struct msi_domain_ops - MSI interrupt domain callbacks
> f3cf8bb0 Jiang Liu        2014-11-12  207   * @get_hwirq:		Retrieve the resulting hw irq number
> f3cf8bb0 Jiang Liu        2014-11-12  208   * @msi_init:		Domain specific init function for MSI interrupts
> f3cf8bb0 Jiang Liu        2014-11-12  209   * @msi_free:		Domain specific function to free a MSI interrupts
> d9109698 Jiang Liu        2014-11-15  210   * @msi_check:		Callback for verification of the domain/info/dev data
> d9109698 Jiang Liu        2014-11-15  211   * @msi_prepare:	Prepare the allocation of the interrupts in the domain
> 1d1e8cdc Thomas Petazzoni 2015-12-21  212   * @msi_finish:		Optional callback to finalize the allocation
> d9109698 Jiang Liu        2014-11-15  213   * @set_desc:		Set the msi descriptor for an interrupt
> d9109698 Jiang Liu        2014-11-15  214   * @handle_error:	Optional error handler if the allocation fails
> d9109698 Jiang Liu        2014-11-15  215   *
> d9109698 Jiang Liu        2014-11-15  216   * @get_hwirq, @msi_init and @msi_free are callbacks used by
> d9109698 Jiang Liu        2014-11-15  217   * msi_create_irq_domain() and related interfaces
> d9109698 Jiang Liu        2014-11-15  218   *
> d9109698 Jiang Liu        2014-11-15  219   * @msi_check, @msi_prepare, @msi_finish, @set_desc and @handle_error
> 1d1e8cdc Thomas Petazzoni 2015-12-21  220   * are callbacks used by msi_domain_alloc_irqs() and related
> d9109698 Jiang Liu        2014-11-15  221   * interfaces which are based on msi_desc.
> f3cf8bb0 Jiang Liu        2014-11-12  222   */
> f3cf8bb0 Jiang Liu        2014-11-12  223  struct msi_domain_ops {
> aeeb5965 Jiang Liu        2014-11-15  224  	irq_hw_number_t	(*get_hwirq)(struct msi_domain_info *info,
> aeeb5965 Jiang Liu        2014-11-15 @225  				     msi_alloc_info_t *arg);
> f3cf8bb0 Jiang Liu        2014-11-12  226  	int		(*msi_init)(struct irq_domain *domain,
> f3cf8bb0 Jiang Liu        2014-11-12  227  				    struct msi_domain_info *info,
> f3cf8bb0 Jiang Liu        2014-11-12  228  				    unsigned int virq, irq_hw_number_t hwirq,
> aeeb5965 Jiang Liu        2014-11-15  229  				    msi_alloc_info_t *arg);
> f3cf8bb0 Jiang Liu        2014-11-12  230  	void		(*msi_free)(struct irq_domain *domain,
> f3cf8bb0 Jiang Liu        2014-11-12  231  				    struct msi_domain_info *info,
> f3cf8bb0 Jiang Liu        2014-11-12  232  				    unsigned int virq);
> d9109698 Jiang Liu        2014-11-15  233  	int		(*msi_check)(struct irq_domain *domain,
> d9109698 Jiang Liu        2014-11-15  234  				     struct msi_domain_info *info,
> d9109698 Jiang Liu        2014-11-15  235  				     struct device *dev);
> d9109698 Jiang Liu        2014-11-15  236  	int		(*msi_prepare)(struct irq_domain *domain,
> d9109698 Jiang Liu        2014-11-15  237  				       struct device *dev, int nvec,
> d9109698 Jiang Liu        2014-11-15  238  				       msi_alloc_info_t *arg);
> d9109698 Jiang Liu        2014-11-15  239  	void		(*msi_finish)(msi_alloc_info_t *arg, int retval);
> d9109698 Jiang Liu        2014-11-15  240  	void		(*set_desc)(msi_alloc_info_t *arg,
> d9109698 Jiang Liu        2014-11-15  241  				    struct msi_desc *desc);
> d9109698 Jiang Liu        2014-11-15  242  	int		(*handle_error)(struct irq_domain *domain,
> d9109698 Jiang Liu        2014-11-15  243  					struct msi_desc *desc, int error);
> f3cf8bb0 Jiang Liu        2014-11-12  244  };
> f3cf8bb0 Jiang Liu        2014-11-12  245
>
> :::::: The code at line 225 was first introduced by commit
> :::::: aeeb59657c35da64068336c20068da237f41ab76 genirq: Provide default callbacks for msi_domain_ops
>
> :::::: TO: Jiang Liu <jiang.liu@linux.intel.com>
> :::::: CC: Thomas Gleixner <tglx@linutronix.de>
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fpipermail%2Fkbuild-all&data=01%7C01%7Claurentiu.tudor%40nxp.com%7C66f7c5619d664f88ce6108d4cecc14f5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=hceaX47eTei7tR91loXYyGufa3dPQhBqyS7R212VcUw%3D&reserved=0                   Intel Corporation
>

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2017-07-20 13:47 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
2017-07-17 13:26 ` [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc laurentiu.tudor at nxp.com
2017-07-17 13:26 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
2017-07-17 13:38   ` Robin Murphy
2017-07-17 13:46     ` Laurentiu Tudor
2017-07-17 13:26 ` [PATCH 3/7] staging: fsl-mc: drop useless gic v3 related #include laurentiu.tudor at nxp.com
2017-07-17 13:26 ` [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops laurentiu.tudor at nxp.com
2017-07-17 13:26 ` [PATCH 5/7] staging: fsl-mc: fix formating of phys_addr_t on 32 bits laurentiu.tudor at nxp.com
2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
2017-07-17 13:43   ` Robin Murphy
2017-07-17 14:53     ` Laurentiu Tudor
2017-07-17 13:45   ` Arnd Bergmann
2017-07-17 14:27     ` Laurentiu Tudor
2017-07-17 15:00       ` Arnd Bergmann
2017-07-18 11:08         ` Laurentiu Tudor
2017-07-18 11:39           ` Arnd Bergmann
2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
2017-07-19 16:09   ` kbuild test robot
2017-07-19 17:31   ` kbuild test robot
2017-07-20 13:47     ` Laurentiu Tudor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).