[PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures

From: 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 <***@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

l***@nxp.com

2017-07-17 13:26:41 UTC

From: 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 <***@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

Robin Murphy

2017-07-17 13:38:01 UTC

Post by l***@nxp.com
No need to use arch-specific memory barriers; switch to using generic
ones. The rmb()s were useless so drop them.
---
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.

Post by l***@nxp.com
@@ -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;
}

Laurentiu Tudor

2017-07-17 13:46:31 UTC

Post by Robin Murphy

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.

Post by Robin Murphy
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

l***@nxp.com

2017-07-17 13:26:42 UTC

From: 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 <***@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

l***@nxp.com

2017-07-17 13:26:44 UTC

From: 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 <***@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

l***@nxp.com

2017-07-17 13:26:45 UTC

From: 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 <***@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

Robin Murphy

2017-07-17 13:43:49 UTC

#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.

Post by l***@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);
}
/**

Laurentiu Tudor

2017-07-17 14:53:54 UTC

Hi Robin,

Post by Robin Murphy

#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

Post by Robin Murphy

Arnd Bergmann

2017-07-17 13:45:37 UTC

Post by l***@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.
---
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

Laurentiu Tudor

2017-07-17 14:27:57 UTC

Hi Arnd,

What is the byte order requirement on this buffer?

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

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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

Arnd Bergmann

2017-07-17 15:00:19 UTC

On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor

Post by Laurentiu Tudor
Hi Arnd,

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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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

Laurentiu Tudor

2017-07-18 11:08:10 UTC

Post by Arnd Bergmann
On Mon, Jul 17, 2017 at 4:27 PM, Laurentiu Tudor

Post by Laurentiu Tudor
Hi Arnd,

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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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.

Post by Arnd Bergmann
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.

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

---
Thanks & Best Regards, Laurentiu

Arnd Bergmann

2017-07-18 11:39:48 UTC

On Tue, Jul 18, 2017 at 1:08 PM, Laurentiu Tudor

Post by Arnd Bergmann
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

l***@nxp.com

2017-07-17 13:26:46 UTC

From: 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 <***@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

l***@nxp.com

2017-07-17 13:26:43 UTC

From: 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 <***@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

kbuild test robot

2017-07-19 16:09:16 UTC

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

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 <***@linux.intel.com>
:::::: CC: Thomas Gleixner <***@linutronix.de>

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

kbuild test robot

2017-07-19 17:31:31 UTC

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

include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'

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: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
--

include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'

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;
^~
--

include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'

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,
^~~~~~~~~~~~~~~~~~~~~~
--

include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'

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: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: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: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
--

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 <***@linux.intel.com>
:::::: CC: Thomas Gleixner <***@linutronix.de>

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

Laurentiu Tudor

2017-07-20 13:47:27 UTC