From: Laurentiu Tudor <[email protected]>
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
From: Laurentiu Tudor <[email protected]>
The mc-bus specific field, fsl_mc in struct msi_desc is missing its
comment so add it.
Signed-off-by: Laurentiu Tudor <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
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 <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
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 <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
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 <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
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 <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
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 <[email protected]>
---
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
From: Laurentiu Tudor <[email protected]>
Nothing from linux/irqchip/arm-gic-v3.h is used, so the #include can be
safely dropped.
Signed-off-by: Laurentiu Tudor <[email protected]>
---
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
On 17/07/17 14:26, [email protected] wrote:
> From: Laurentiu Tudor <[email protected]>
>
> 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 <[email protected]>
> ---
> 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;
> }
>
On 17/07/17 14:26, [email protected] wrote:
> From: Laurentiu Tudor <[email protected]>
>
> 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 <[email protected]>
> ---
> 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);
> }
>
> /**
>
On Mon, Jul 17, 2017 at 3:26 PM, <[email protected]> wrote:
> From: Laurentiu Tudor <[email protected]>
>
> 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 <[email protected]>
> ---
> 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
On 07/17/2017 04:38 PM, Robin Murphy wrote:
> On 17/07/17 14:26, [email protected] wrote:
>> From: Laurentiu Tudor <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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
Hi Arnd,
On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:26 PM, <[email protected]> wrote:
>> From: Laurentiu Tudor <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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
Hi Robin,
On 07/17/2017 04:43 PM, Robin Murphy wrote:
> On 17/07/17 14:26, [email protected] wrote:
>> From: Laurentiu Tudor <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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);
>> }
>>
>> /**
>>
>
On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor
<[email protected]> wrote:
> Hi Arnd,
>
> On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
>> On Mon, Jul 17, 2017 at 3:26 PM, <[email protected]> wrote:
>>> From: Laurentiu Tudor <[email protected]>
>>>
>>> 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 <[email protected]>
>>> ---
>>> 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
On 07/17/2017 06:00 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor
> <[email protected]> wrote:
>> Hi Arnd,
>>
>> On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
>>> On Mon, Jul 17, 2017 at 3:26 PM, <[email protected]> wrote:
>>>> From: Laurentiu Tudor <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>> ---
>>>> 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
On Tue, Jul 18, 2017 at 1:08 PM, Laurentiu Tudor
<[email protected]> 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
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 <[email protected]>
:::::: CC: Thomas Gleixner <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
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 <[email protected]>
:::::: CC: Thomas Gleixner <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
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 <[email protected]>
> :::::: CC: Thomas Gleixner <[email protected]>
>
> ---
> 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
>