* [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 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 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 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 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: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 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 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 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 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 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).