* [PATCH 3/4] vfio_spapr_eeh: Enable compile as a module
From: Alexey Kardashevskiy @ 2014-08-05 12:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan
In-Reply-To: <1407241785-30111-1-git-send-email-aik@ozlabs.ru>
This adds necessary declarations to the module, otherwise multiple
dynamic linker errors happen:
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/vfio_spapr_eeh.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 1a93e83..a942dd0 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
* published by the Free Software Foundation.
*/
+#include <linux/module.h>
#include <linux/uaccess.h>
#include <linux/vfio.h>
#include <asm/eeh.h>
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC "VFIO IOMMU SPAPR EEH"
+
/* We might build address mapping here for "fast" path later */
#ifdef CONFIG_EEH
@@ -91,3 +96,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
}
EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl);
#endif /* CONFIG_EEH */
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
--
2.0.0
^ permalink raw reply related
* [PATCH 1/4] powerpc/eeh: Export eeh_iommu_group_to_pe()
From: Alexey Kardashevskiy @ 2014-08-05 12:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, Gavin Shan
In-Reply-To: <1407241785-30111-1-git-send-email-aik@ozlabs.ru>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
The function is used by VFIO driver, which might be built as a
dynamic module.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group *group)
return edev->pe;
}
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
#endif /* CONFIG_IOMMU_API */
--
2.0.0
^ permalink raw reply related
* [PATCH 4/4] vfio_pci: spapr: Enable VFIO if EEH is not supported
From: Alexey Kardashevskiy @ 2014-08-05 12:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan
In-Reply-To: <1407241785-30111-1-git-send-email-aik@ozlabs.ru>
The existing vfio_pci_open() fails if there is no EEH support for PCI.
This breaks POWER7's P5IOC2 PHB support which this patch brings back.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/pci/vfio_pci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..63a73c0 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -179,10 +179,8 @@ static int vfio_pci_open(void *device_data)
goto error;
ret = vfio_spapr_pci_eeh_open(vdev->pdev);
- if (ret) {
- vfio_pci_disable(vdev);
- goto error;
- }
+ if (ret)
+ pr_warn("EEH is not supported\n");
}
return 0;
--
2.0.0
^ permalink raw reply related
* [PATCH 0/4] vfio: eeh: spapr: Compile and compatibility fixes
From: Alexey Kardashevskiy @ 2014-08-05 12:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan
Here is what I have in my stash.
Alexey Kardashevskiy (2):
vfio_spapr_eeh: Enable compile as a module
vfio_pci: spapr: Enable VFIO if EEH is not supported
Gavin Shan (2):
powerpc/eeh: Export eeh_iommu_group_to_pe()
vfio: spapr: Fix build error
arch/powerpc/kernel/eeh.c | 1 +
drivers/vfio/Makefile | 4 ++--
drivers/vfio/pci/vfio_pci.c | 6 ++----
drivers/vfio/vfio.c | 1 +
drivers/vfio/vfio_spapr_eeh.c | 16 ++++++++++++++++
5 files changed, 22 insertions(+), 6 deletions(-)
--
2.0.0
^ permalink raw reply
* Re: [PATCH] arch/powerpc/mm/numa.c: Fix break placement
From: Michael Ellerman @ 2014-08-05 12:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sfr, rcj, alistair, kernel-janitors, linux-kernel, Andrey Utkin,
paulus, wangyun, srivatsa.bhat, joe, qiuxishi, akpm, qiudayu,
linuxppc-dev
In-Reply-To: <1407230219.3073.5.camel@pasglop>
On Tue, 2014-08-05 at 19:16 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-08-04 at 23:13 +0300, Andrey Utkin wrote:
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81631
> > Reported-by: David Binderman <dcb314@hotmail.com>
> > Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
>
> Thanks, I wonder how that managed to remain unnoticed for so long !
1. No one tested it :)
2. The code stupidly initialises ret at the beginning of the function, so the
compiler can't help us detect the unitialised usage.
3. NOTIFY_OK and NOTIFY_DONE appear to be equivalent in practice.
cheers
^ permalink raw reply
* [PATCH] fsl-rio: add support for mapping inbound windows
From: Martijn de Gouw @ 2014-08-05 13:52 UTC (permalink / raw)
To: linuxppc-dev, scottwood
Cc: Alexandre.Bounine, Martijn de Gouw, Barry.Wood, stef.van.os
Add support for mapping and unmapping of inbound rapidio windows.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
---
arch/powerpc/sysdev/fsl_rio.c | 104 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_rio.h | 13 ++++++
2 files changed, 117 insertions(+)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index c04b718..08d60f1 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -58,6 +58,19 @@
#define RIO_ISR_AACR 0x10120
#define RIO_ISR_AACR_AA 0x1 /* Accept All ID */
+#define RIWTAR_TRAD_VAL_SHIFT 12
+#define RIWTAR_TRAD_MASK 0x00FFFFFF
+#define RIWBAR_BADD_VAL_SHIFT 12
+#define RIWBAR_BADD_MASK 0x003FFFFF
+#define RIWAR_ENABLE 0x80000000
+#define RIWAR_TGINT_LOCAL 0x00F00000
+#define RIWAR_RDTYP_NO_SNOOP 0x00040000
+#define RIWAR_RDTYP_SNOOP 0x00050000
+#define RIWAR_WRTYP_NO_SNOOP 0x00004000
+#define RIWAR_WRTYP_SNOOP 0x00005000
+#define RIWAR_WRTYP_ALLOC 0x00006000
+#define RIWAR_SIZE_MASK 0x0000003F
+
#define __fsl_read_rio_config(x, addr, err, op) \
__asm__ __volatile__( \
"1: "op" %1,0(%2)\n" \
@@ -266,6 +279,89 @@ fsl_rio_config_write(struct rio_mport *mport, int index, u16 destid,
return 0;
}
+static void fsl_rio_inbound_mem_init(struct rio_priv *priv)
+{
+ int i;
+
+ /* close inbound windows */
+ for (i = 0; i < RIO_INB_ATMU_COUNT; i++)
+ out_be32(&priv->inb_atmu_regs[i].riwar, 0);
+}
+
+int fsl_map_inb_mem(struct rio_mport *mport, dma_addr_t lstart,
+ u64 rstart, u32 size, u32 flags)
+{
+ struct rio_priv *priv = mport->priv;
+ u32 base_size;
+ unsigned int base_size_log;
+ u64 win_start, win_end;
+ u32 riwar;
+ int i;
+
+ if ((size & (size - 1)) != 0)
+ return -EINVAL;
+
+ base_size_log = ilog2(size);
+ base_size = 1 << base_size_log;
+
+ /* check if addresses are aligned with the window size */
+ if (lstart & (base_size - 1))
+ return -EINVAL;
+ if (rstart & (base_size - 1))
+ return -EINVAL;
+
+ /* check for conflicting ranges */
+ for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
+ riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
+ if ((riwar & RIWAR_ENABLE) == 0)
+ continue;
+ win_start = ((u64)(in_be32(&priv->inb_atmu_regs[i].riwbar) & RIWBAR_BADD_MASK))
+ << RIWBAR_BADD_VAL_SHIFT;
+ win_end = win_start + ((1 << ((riwar & RIWAR_SIZE_MASK) + 1)) - 1);
+ if (rstart < win_end && (rstart + size) > win_start)
+ return -EINVAL;
+ }
+
+ /* find unused atmu */
+ for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
+ riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
+ if ((riwar & RIWAR_ENABLE) == 0)
+ break;
+ }
+ if (i >= RIO_INB_ATMU_COUNT)
+ return -ENOMEM;
+
+ out_be32(&priv->inb_atmu_regs[i].riwtar, lstart >> RIWTAR_TRAD_VAL_SHIFT);
+ out_be32(&priv->inb_atmu_regs[i].riwbar, rstart >> RIWBAR_BADD_VAL_SHIFT);
+ out_be32(&priv->inb_atmu_regs[i].riwar, RIWAR_ENABLE | RIWAR_TGINT_LOCAL |
+ RIWAR_RDTYP_SNOOP | RIWAR_WRTYP_SNOOP | (base_size_log - 1));
+
+ return 0;
+}
+
+void fsl_unmap_inb_mem(struct rio_mport *mport, dma_addr_t lstart)
+{
+ u32 win_start_shift, base_start_shift;
+ struct rio_priv *priv = mport->priv;
+ u32 riwar, riwtar;
+ int i;
+
+ /* skip default window */
+ base_start_shift = lstart >> RIWTAR_TRAD_VAL_SHIFT;
+ for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
+ riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
+ if ((riwar & RIWAR_ENABLE) == 0)
+ continue;
+
+ riwtar = in_be32(&priv->inb_atmu_regs[i].riwtar);
+ win_start_shift = riwtar & RIWTAR_TRAD_MASK;
+ if (win_start_shift == base_start_shift) {
+ out_be32(&priv->inb_atmu_regs[i].riwar, riwar & ~RIWAR_ENABLE);
+ return;
+ }
+ }
+}
+
void fsl_rio_port_error_handler(int offset)
{
/*XXX: Error recovery is not implemented, we just clear errors */
@@ -389,6 +485,8 @@ int fsl_rio_setup(struct platform_device *dev)
ops->add_outb_message = fsl_add_outb_message;
ops->add_inb_buffer = fsl_add_inb_buffer;
ops->get_inb_message = fsl_get_inb_message;
+ ops->map_inb = fsl_map_inb_mem;
+ ops->unmap_inb = fsl_unmap_inb_mem;
rmu_node = of_parse_phandle(dev->dev.of_node, "fsl,srio-rmu-handle", 0);
if (!rmu_node) {
@@ -602,6 +700,11 @@ int fsl_rio_setup(struct platform_device *dev)
RIO_ATMU_REGS_PORT2_OFFSET));
priv->maint_atmu_regs = priv->atmu_regs + 1;
+ priv->inb_atmu_regs = (struct rio_inb_atmu_regs __iomem *)
+ (priv->regs_win +
+ ((i == 0) ? RIO_INB_ATMU_REGS_PORT1_OFFSET :
+ RIO_INB_ATMU_REGS_PORT2_OFFSET));
+
/* Set to receive any dist ID for serial RapidIO controller. */
if (port->phy_type == RIO_PHY_SERIAL)
@@ -620,6 +723,7 @@ int fsl_rio_setup(struct platform_device *dev)
rio_law_start = range_start;
fsl_rio_setup_rmu(port, rmu_np[i]);
+ fsl_rio_inbound_mem_init(priv);
dbell->mport[i] = port;
diff --git a/arch/powerpc/sysdev/fsl_rio.h b/arch/powerpc/sysdev/fsl_rio.h
index ae8e274..d53407a 100644
--- a/arch/powerpc/sysdev/fsl_rio.h
+++ b/arch/powerpc/sysdev/fsl_rio.h
@@ -50,9 +50,12 @@
#define RIO_S_DBELL_REGS_OFFSET 0x13400
#define RIO_S_PW_REGS_OFFSET 0x134e0
#define RIO_ATMU_REGS_DBELL_OFFSET 0x10C40
+#define RIO_INB_ATMU_REGS_PORT1_OFFSET 0x10d60
+#define RIO_INB_ATMU_REGS_PORT2_OFFSET 0x10f60
#define MAX_MSG_UNIT_NUM 2
#define MAX_PORT_NUM 4
+#define RIO_INB_ATMU_COUNT 4
struct rio_atmu_regs {
u32 rowtar;
@@ -63,6 +66,15 @@ struct rio_atmu_regs {
u32 pad2[3];
};
+struct rio_inb_atmu_regs {
+ u32 riwtar;
+ u32 pad1;
+ u32 riwbar;
+ u32 pad2;
+ u32 riwar;
+ u32 pad3[3];
+};
+
struct rio_dbell_ring {
void *virt;
dma_addr_t phys;
@@ -99,6 +111,7 @@ struct rio_priv {
void __iomem *regs_win;
struct rio_atmu_regs __iomem *atmu_regs;
struct rio_atmu_regs __iomem *maint_atmu_regs;
+ struct rio_inb_atmu_regs __iomem *inb_atmu_regs;
void __iomem *maint_win;
void *rmm_handle; /* RapidIO message manager(unit) Handle */
};
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/4] vfio: spapr: Fix build error
From: Alex Williamson @ 2014-08-05 14:18 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, Gavin Shan, Gavin Shan
In-Reply-To: <1407241785-30111-3-git-send-email-aik@ozlabs.ru>
On Tue, 2014-08-05 at 22:29 +1000, Alexey Kardashevskiy wrote:
> From: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
> The VFIO related components could be built as dynamic modules.
> Unfortunately, CONFIG_EEH can't be configured to "m". The patch
> fixes the build errors when configuring VFIO related components
> as dynamic modules as follows:
>
> CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
> In file included from drivers/vfio/vfio.c:33:0:
> include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
> inside parameter list [enabled by default]
> :
> WRAP arch/powerpc/boot/zImage.pseries
> WRAP arch/powerpc/boot/zImage.maple
> WRAP arch/powerpc/boot/zImage.pmac
> WRAP arch/powerpc/boot/zImage.epapr
> MODPOST 1818 modules
> ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
> undefined!
> ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
> ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!
>
> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> drivers/vfio/Makefile | 4 ++--
> drivers/vfio/vfio.c | 1 +
> drivers/vfio/vfio_spapr_eeh.c | 6 ++++++
> 3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 50e30bc..4891cca 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -1,5 +1,5 @@
> obj-$(CONFIG_VFIO) += vfio.o
> obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
> -obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
> -obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o \
> + vfio_spapr_eeh.o
> obj-$(CONFIG_VFIO_PCI) += pci/
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index f018d8d..b4118e0 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -25,6 +25,7 @@
> #include <linux/miscdevice.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/pci.h>
VFIO-core shouldn't need to know about PCI, fix it some other way.
Since this code isn't in -next yet, I can't see what's causing it.
> #include <linux/rwsem.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index f834b4c..1a93e83 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -14,15 +14,19 @@
> #include <asm/eeh.h>
>
> /* We might build address mapping here for "fast" path later */
> +#ifdef CONFIG_EEH
Why not add a new CONFIG_VFIO_SPAPR_EEH option to handle this instead?
> +
> int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> {
> return eeh_dev_open(pdev);
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>
> void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> {
> eeh_dev_release(pdev);
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
>
> long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> unsigned int cmd, unsigned long arg)
> @@ -85,3 +89,5 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl);
> +#endif /* CONFIG_EEH */
^ permalink raw reply
* [PATCH] powerpc: non-GPL export for eeh_dev_check_failure
From: Vishal Mansur @ 2014-08-05 14:35 UTC (permalink / raw)
To: shangw, benh, linuxppc-dev; +Cc: linux-kernel
EEH kernel services are inconsistently exported by the
kernel. eeh_check_failure is exported for any use, but
eeh_dev_check_failure is exported only for GPL use.
While eeh_check_failure is implemented for a specific
purpose to be used by services such as readl, it is
not suited for a purpose where caller needs eeh status.
This functionality is provided by eeh_dev_check_failure.
This patch relaxes the export for eeh_dev_check_failure
to make it consistent with eeh_check_failure() and
usable by non-GPL modules.
Signed-off-by: Vishal Mansur <vmansur@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 86e2570..8689c30 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -496,8 +496,7 @@ dn_unlock:
eeh_serialize_unlock(flags);
return rc;
}
-
-EXPORT_SYMBOL_GPL(eeh_dev_check_failure);
+EXPORT_SYMBOL(eeh_dev_check_failure);
/**
* eeh_check_failure - Check if all 1's data is due to EEH slot freeze
--
2.0.1
^ permalink raw reply related
* [PATCH] powerpc: non-GPL export for eeh_dev_check_failure
From: Vishal Mansur @ 2014-08-05 14:42 UTC (permalink / raw)
To: gwshan, benh, linuxppc-dev; +Cc: linux-kernel
EEH kernel services are inconsistently exported by the
kernel. eeh_check_failure is exported for any use, but
eeh_dev_check_failure is exported only for GPL use.
While eeh_check_failure is implemented for a specific
purpose to be used by services such as readl, it is
not suited for a purpose where caller needs eeh status.
This functionality is provided by eeh_dev_check_failure.
This patch relaxes the export for eeh_dev_check_failure
to make it consistent with eeh_check_failure() and
usable by non-GPL modules.
Signed-off-by: Vishal Mansur <vmansur@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 86e2570..8689c30 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -496,8 +496,7 @@ dn_unlock:
eeh_serialize_unlock(flags);
return rc;
}
-
-EXPORT_SYMBOL_GPL(eeh_dev_check_failure);
+EXPORT_SYMBOL(eeh_dev_check_failure);
/**
* eeh_check_failure - Check if all 1's data is due to EEH slot freeze
--
2.0.1
^ permalink raw reply related
* Re: [PATCH] powerpc: non-GPL export for eeh_dev_check_failure
From: One Thousand Gnomes @ 2014-08-05 14:51 UTC (permalink / raw)
To: Vishal Mansur; +Cc: linuxppc-dev, gwshan, linux-kernel
In-Reply-To: <53E0ED41.8030804@linux.vnet.ibm.com>
On Tue, 05 Aug 2014 20:12:09 +0530
Vishal Mansur <vmansur@linux.vnet.ibm.com> wrote:
> EEH kernel services are inconsistently exported by the
> kernel. eeh_check_failure is exported for any use, but
> eeh_dev_check_failure is exported only for GPL use.
> While eeh_check_failure is implemented for a specific
> purpose to be used by services such as readl, it is
> not suited for a purpose where caller needs eeh status.
> This functionality is provided by eeh_dev_check_failure.
>
> This patch relaxes the export for eeh_dev_check_failure
> to make it consistent with eeh_check_failure() and
> usable by non-GPL modules.
The GPL covers all derivative works. Tweaking this doesn't magically
allow you to use the feature in non GPL code. Your legal department can I
am sure explain in detail further.
Alan
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix IOMMU group lost
From: Wei Yang @ 2014-08-05 16:03 UTC (permalink / raw)
To: Gavin Shan; +Cc: weiyang, linuxppc-dev, stable
In-Reply-To: <1407227258-17732-1-git-send-email-gwshan@linux.vnet.ibm.com>
I just give a shot with patch on PHB3 with hotplug case. From the functional
point of view, it works. The iommu group is created and attached with device.
While it still has the problem we had which commit 3f28c5a tried to solve.
In the test case, the pci bus is not removed. This means in
pcibios_add_device(), it will try to add iommu group since the
pci_bus->is_added is true. And at this moment the pci_dev->kobj->sd is not
initialized properly. This makes the iommu_add_device() fail.
Your patch delete the warning at this place, so from the log it looks good. But
actually, it is not that clear to address the problem. We still have two
problems:
1. iommu group will fail to be created
2. iommu group will be created multiple times
My opinion is to make a clear understanding of the order/sequence of the iommu
group creation in both pci bus removed/not removed cases, than create and
attach it properly.
On Tue, Aug 05, 2014 at 06:27:38PM +1000, Gavin Shan wrote:
>When we take full hotplug to recover from EEH errors, PCI buses
>could be involved. For the case, the child devices of involved
>PCI buses can't be attached to IOMMU group properly, which is
>caused by commit 3f28c5a ("powerpc/powernv: Reduce multi-hit of
>iommu_add_device()").
>
>When adding the PCI devices of the newly created PCI buses to
>the system, the IOMMU group is expected to be added in (C).
>(A) fails to bind the IOMMU group because bus->is_added is
>false. (B) fails because the device doesn't have binding IOMMU
>table yet. bus->is_added is set to true at end of (C) and
>pdev->is_added is set to true at (D).
>
> pcibios_add_pci_devices()
> pci_scan_bridge()
> pci_scan_child_bus()
> pci_scan_slot()
> pci_scan_single_device()
> pci_scan_device()
> pci_device_add()
> pcibios_add_device() A: Ignore
> device_add() B: Ignore
> pcibios_fixup_bus()
> pcibios_setup_bus_devices()
> pcibios_setup_device() C: Hit
> pcibios_finish_adding_to_bus()
> pci_bus_add_devices()
> pci_bus_add_device() D: Add device
>
>If the parent PCI bus isn't involved in hotplug, the IOMMU
>group is expected to be bound in (A).
>
>The patch fixes the issue by reverting commit 3f28c5a and remove
>WARN_ON() in iommu_add_device() to allow calling the function
>even the specified device already has associated IOMMU group.
>
>Cc: <stable@vger.kernel.org> # 3.16+
>Reported-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>---
> arch/powerpc/kernel/iommu.c | 30 +++++++++++++-----------------
> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
> 2 files changed, 14 insertions(+), 18 deletions(-)
>
>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>index 88e3ec6..4663c10 100644
>--- a/arch/powerpc/kernel/iommu.c
>+++ b/arch/powerpc/kernel/iommu.c
>@@ -1120,37 +1120,33 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
> int iommu_add_device(struct device *dev)
> {
> struct iommu_table *tbl;
>- int ret = 0;
>
>- if (WARN_ON(dev->iommu_group)) {
>- pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>- dev_name(dev),
>- iommu_group_id(dev->iommu_group));
>+ if (dev->iommu_group) {
>+ pr_debug("%s: Skipping device %s with iommu group %d\n",
>+ __func__, dev_name(dev),
>+ iommu_group_id(dev->iommu_group));
> return -EBUSY;
> }
>
> tbl = get_iommu_table_base(dev);
> if (!tbl || !tbl->it_group) {
>- pr_debug("iommu_tce: skipping device %s with no tbl\n",
>- dev_name(dev));
>+ pr_debug("%s: Skipping device %s with no tbl\n",
>+ __func__, dev_name(dev));
> return 0;
> }
>
>- pr_debug("iommu_tce: adding %s to iommu group %d\n",
>- dev_name(dev), iommu_group_id(tbl->it_group));
>+ pr_debug("%s: Adding %s to iommu group %d\n",
>+ __func__, dev_name(dev),
>+ iommu_group_id(tbl->it_group));
>
> if (PAGE_SIZE < IOMMU_PAGE_SIZE(tbl)) {
>- pr_err("iommu_tce: unsupported iommu page size.");
>- pr_err("%s has not been added\n", dev_name(dev));
>+ pr_err("%s: Invalid IOMMU page size %lx (%lx) on %s\n",
>+ __func__, IOMMU_PAGE_SIZE(tbl),
>+ PAGE_SIZE, dev_name(dev));
> return -EINVAL;
> }
>
>- ret = iommu_group_add_device(tbl->it_group, dev);
>- if (ret < 0)
>- pr_err("iommu_tce: %s has not been added, ret=%d\n",
>- dev_name(dev), ret);
>-
>- return ret;
>+ return iommu_group_add_device(tbl->it_group, dev);
> }
> EXPORT_SYMBOL_GPL(iommu_add_device);
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>index de19ede..86290eb 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -462,7 +462,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
>
> pe = &phb->ioda.pe_array[pdn->pe_number];
> WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
>- set_iommu_table_base(&pdev->dev, &pe->tce32_table);
>+ set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
> }
>
> static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
>--
>1.8.3.2
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 4/4] vfio_pci: spapr: Enable VFIO if EEH is not supported
From: Alex Williamson @ 2014-08-05 17:59 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1407241785-30111-5-git-send-email-aik@ozlabs.ru>
On Tue, 2014-08-05 at 22:29 +1000, Alexey Kardashevskiy wrote:
> The existing vfio_pci_open() fails if there is no EEH support for PCI.
> This breaks POWER7's P5IOC2 PHB support which this patch brings back.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> drivers/vfio/pci/vfio_pci.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index e2ee80f..63a73c0 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -179,10 +179,8 @@ static int vfio_pci_open(void *device_data)
> goto error;
>
> ret = vfio_spapr_pci_eeh_open(vdev->pdev);
> - if (ret) {
> - vfio_pci_disable(vdev);
> - goto error;
> - }
> + if (ret)
> + pr_warn("EEH is not supported\n");
Is this really deserving of a warn? Does it need a warning every time?
pr_warn_once? pr_info? pr_info_once?
PS - kvm is the official vfio mailing list; suggest keeping it cc'd
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH] fsl-rio: add support for mapping inbound windows
From: Scott Wood @ 2014-08-05 21:37 UTC (permalink / raw)
To: Martijn de Gouw
Cc: Alexandre.Bounine, Liu Gang, Barry.Wood, linuxppc-dev,
stef.van.os
In-Reply-To: <1407246752-21639-1-git-send-email-martijn.de.gouw@prodrive-technologies.com>
On Tue, 2014-08-05 at 15:52 +0200, Martijn de Gouw wrote:
> Add support for mapping and unmapping of inbound rapidio windows.
>
> Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Could you elaborate in the changelog on what this fixes or makes
possible? E.g. did the driver previously not support inbound
transactions at all, or did it assume the window was set up by a
bootloader?
Liu Gang, could you review this?
-Scott
> ---
> arch/powerpc/sysdev/fsl_rio.c | 104 +++++++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_rio.h | 13 ++++++
> 2 files changed, 117 insertions(+)
>
> diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
> index c04b718..08d60f1 100644
> --- a/arch/powerpc/sysdev/fsl_rio.c
> +++ b/arch/powerpc/sysdev/fsl_rio.c
> @@ -58,6 +58,19 @@
> #define RIO_ISR_AACR 0x10120
> #define RIO_ISR_AACR_AA 0x1 /* Accept All ID */
>
> +#define RIWTAR_TRAD_VAL_SHIFT 12
> +#define RIWTAR_TRAD_MASK 0x00FFFFFF
> +#define RIWBAR_BADD_VAL_SHIFT 12
> +#define RIWBAR_BADD_MASK 0x003FFFFF
> +#define RIWAR_ENABLE 0x80000000
> +#define RIWAR_TGINT_LOCAL 0x00F00000
> +#define RIWAR_RDTYP_NO_SNOOP 0x00040000
> +#define RIWAR_RDTYP_SNOOP 0x00050000
> +#define RIWAR_WRTYP_NO_SNOOP 0x00004000
> +#define RIWAR_WRTYP_SNOOP 0x00005000
> +#define RIWAR_WRTYP_ALLOC 0x00006000
> +#define RIWAR_SIZE_MASK 0x0000003F
> +
> #define __fsl_read_rio_config(x, addr, err, op) \
> __asm__ __volatile__( \
> "1: "op" %1,0(%2)\n" \
> @@ -266,6 +279,89 @@ fsl_rio_config_write(struct rio_mport *mport, int index, u16 destid,
> return 0;
> }
>
> +static void fsl_rio_inbound_mem_init(struct rio_priv *priv)
> +{
> + int i;
> +
> + /* close inbound windows */
> + for (i = 0; i < RIO_INB_ATMU_COUNT; i++)
> + out_be32(&priv->inb_atmu_regs[i].riwar, 0);
> +}
> +
> +int fsl_map_inb_mem(struct rio_mport *mport, dma_addr_t lstart,
> + u64 rstart, u32 size, u32 flags)
> +{
> + struct rio_priv *priv = mport->priv;
> + u32 base_size;
> + unsigned int base_size_log;
> + u64 win_start, win_end;
> + u32 riwar;
> + int i;
> +
> + if ((size & (size - 1)) != 0)
> + return -EINVAL;
> +
> + base_size_log = ilog2(size);
> + base_size = 1 << base_size_log;
> +
> + /* check if addresses are aligned with the window size */
> + if (lstart & (base_size - 1))
> + return -EINVAL;
> + if (rstart & (base_size - 1))
> + return -EINVAL;
> +
> + /* check for conflicting ranges */
> + for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
> + riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
> + if ((riwar & RIWAR_ENABLE) == 0)
> + continue;
> + win_start = ((u64)(in_be32(&priv->inb_atmu_regs[i].riwbar) & RIWBAR_BADD_MASK))
> + << RIWBAR_BADD_VAL_SHIFT;
> + win_end = win_start + ((1 << ((riwar & RIWAR_SIZE_MASK) + 1)) - 1);
> + if (rstart < win_end && (rstart + size) > win_start)
> + return -EINVAL;
> + }
> +
> + /* find unused atmu */
> + for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
> + riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
> + if ((riwar & RIWAR_ENABLE) == 0)
> + break;
> + }
> + if (i >= RIO_INB_ATMU_COUNT)
> + return -ENOMEM;
> +
> + out_be32(&priv->inb_atmu_regs[i].riwtar, lstart >> RIWTAR_TRAD_VAL_SHIFT);
> + out_be32(&priv->inb_atmu_regs[i].riwbar, rstart >> RIWBAR_BADD_VAL_SHIFT);
> + out_be32(&priv->inb_atmu_regs[i].riwar, RIWAR_ENABLE | RIWAR_TGINT_LOCAL |
> + RIWAR_RDTYP_SNOOP | RIWAR_WRTYP_SNOOP | (base_size_log - 1));
> +
> + return 0;
> +}
> +
> +void fsl_unmap_inb_mem(struct rio_mport *mport, dma_addr_t lstart)
> +{
> + u32 win_start_shift, base_start_shift;
> + struct rio_priv *priv = mport->priv;
> + u32 riwar, riwtar;
> + int i;
> +
> + /* skip default window */
> + base_start_shift = lstart >> RIWTAR_TRAD_VAL_SHIFT;
> + for (i = 0; i < RIO_INB_ATMU_COUNT; i++) {
> + riwar = in_be32(&priv->inb_atmu_regs[i].riwar);
> + if ((riwar & RIWAR_ENABLE) == 0)
> + continue;
> +
> + riwtar = in_be32(&priv->inb_atmu_regs[i].riwtar);
> + win_start_shift = riwtar & RIWTAR_TRAD_MASK;
> + if (win_start_shift == base_start_shift) {
> + out_be32(&priv->inb_atmu_regs[i].riwar, riwar & ~RIWAR_ENABLE);
> + return;
> + }
> + }
> +}
> +
> void fsl_rio_port_error_handler(int offset)
> {
> /*XXX: Error recovery is not implemented, we just clear errors */
> @@ -389,6 +485,8 @@ int fsl_rio_setup(struct platform_device *dev)
> ops->add_outb_message = fsl_add_outb_message;
> ops->add_inb_buffer = fsl_add_inb_buffer;
> ops->get_inb_message = fsl_get_inb_message;
> + ops->map_inb = fsl_map_inb_mem;
> + ops->unmap_inb = fsl_unmap_inb_mem;
>
> rmu_node = of_parse_phandle(dev->dev.of_node, "fsl,srio-rmu-handle", 0);
> if (!rmu_node) {
> @@ -602,6 +700,11 @@ int fsl_rio_setup(struct platform_device *dev)
> RIO_ATMU_REGS_PORT2_OFFSET));
>
> priv->maint_atmu_regs = priv->atmu_regs + 1;
> + priv->inb_atmu_regs = (struct rio_inb_atmu_regs __iomem *)
> + (priv->regs_win +
> + ((i == 0) ? RIO_INB_ATMU_REGS_PORT1_OFFSET :
> + RIO_INB_ATMU_REGS_PORT2_OFFSET));
> +
>
> /* Set to receive any dist ID for serial RapidIO controller. */
> if (port->phy_type == RIO_PHY_SERIAL)
> @@ -620,6 +723,7 @@ int fsl_rio_setup(struct platform_device *dev)
> rio_law_start = range_start;
>
> fsl_rio_setup_rmu(port, rmu_np[i]);
> + fsl_rio_inbound_mem_init(priv);
>
> dbell->mport[i] = port;
>
> diff --git a/arch/powerpc/sysdev/fsl_rio.h b/arch/powerpc/sysdev/fsl_rio.h
> index ae8e274..d53407a 100644
> --- a/arch/powerpc/sysdev/fsl_rio.h
> +++ b/arch/powerpc/sysdev/fsl_rio.h
> @@ -50,9 +50,12 @@
> #define RIO_S_DBELL_REGS_OFFSET 0x13400
> #define RIO_S_PW_REGS_OFFSET 0x134e0
> #define RIO_ATMU_REGS_DBELL_OFFSET 0x10C40
> +#define RIO_INB_ATMU_REGS_PORT1_OFFSET 0x10d60
> +#define RIO_INB_ATMU_REGS_PORT2_OFFSET 0x10f60
>
> #define MAX_MSG_UNIT_NUM 2
> #define MAX_PORT_NUM 4
> +#define RIO_INB_ATMU_COUNT 4
>
> struct rio_atmu_regs {
> u32 rowtar;
> @@ -63,6 +66,15 @@ struct rio_atmu_regs {
> u32 pad2[3];
> };
>
> +struct rio_inb_atmu_regs {
> + u32 riwtar;
> + u32 pad1;
> + u32 riwbar;
> + u32 pad2;
> + u32 riwar;
> + u32 pad3[3];
> +};
> +
> struct rio_dbell_ring {
> void *virt;
> dma_addr_t phys;
> @@ -99,6 +111,7 @@ struct rio_priv {
> void __iomem *regs_win;
> struct rio_atmu_regs __iomem *atmu_regs;
> struct rio_atmu_regs __iomem *maint_atmu_regs;
> + struct rio_inb_atmu_regs __iomem *inb_atmu_regs;
> void __iomem *maint_win;
> void *rmm_handle; /* RapidIO message manager(unit) Handle */
> };
^ permalink raw reply
* [PATCH] powerpc/pseries/hvcserver: Fix endian issue in hvcs_get_partner_info
From: Thomas Falcon @ 2014-08-05 21:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thomas Falcon
A buffer returned by H_VTERM_PARTNER_INFO contains device information
in big endian format, causing problems for little endian architectures.
This patch ensures that they are in cpu endian.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hvcserver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvcserver.c b/arch/powerpc/platforms/pseries/hvcserver.c
index 4557e91..eedb645 100644
--- a/arch/powerpc/platforms/pseries/hvcserver.c
+++ b/arch/powerpc/platforms/pseries/hvcserver.c
@@ -163,8 +163,8 @@ int hvcs_get_partner_info(uint32_t unit_address, struct list_head *head,
return retval;
}
- last_p_partition_ID = pi_buff[0];
- last_p_unit_address = pi_buff[1];
+ last_p_partition_ID = be64_to_cpu(pi_buff[0]);
+ last_p_unit_address = be64_to_cpu(pi_buff[1]);
/* This indicates that there are no further partners */
if (last_p_partition_ID == ~0UL
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/nohash: Split __early_init_mmu() into boot and secondary
From: Scott Wood @ 2014-08-06 0:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1407213410.19150.65.camel@pasglop>
On Tue, 2014-08-05 at 14:36 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2014-08-01 at 22:07 -0500, Scott Wood wrote:
>
> >
> > -void __init early_init_mmu(void)
> > -{
> > - __early_init_mmu(1);
> > -}
> > -
> > void early_init_mmu_secondary(void)
> > {
> > - __early_init_mmu(0);
> > + early_init_mmu_allcpus();
> > }
>
> Small nit, it took me 30s too long to figure out what you were doing due
> to the naming above :)
>
> Call the latter early_init_this_mmu() and keep the global one separate
> such that early_init_mmu() does:
>
> early_init_mmu_common();
> early_init_this_mmu();
I'll do s/mmu_allcpus/this_mmu/ but early_init_mmu() needs to do things
both before and after early_init_mmu_common(). Do you want two new
functions (before and after) or is it OK to just rename
early_init_mmu_allcpus() and put a comment before early_init_mmu()
saying it's just for the boot cpu?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix IOMMU group lost
From: Gavin Shan @ 2014-08-06 1:46 UTC (permalink / raw)
To: Wei Yang; +Cc: linuxppc-dev, Gavin Shan, stable
In-Reply-To: <20140805100036.GA7364@richard>
On Tue, Aug 05, 2014 at 06:00:36PM +0800, Wei Yang wrote:
>I didn't manage to test this one PHB3, since some network issue, I can't
>access the machine in Austin.
>
>Will reply after I test this on PHB3.
>
Yep, thanks. By the way, I tested it on P7 box and looks good
for partial/full hotplug cases.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix IOMMU group lost
From: Gavin Shan @ 2014-08-06 2:06 UTC (permalink / raw)
To: Wei Yang; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <20140805160323.GA9066@richard>
On Wed, Aug 06, 2014 at 12:03:23AM +0800, Wei Yang wrote:
>I just give a shot with patch on PHB3 with hotplug case. From the functional
>point of view, it works. The iommu group is created and attached with device.
>While it still has the problem we had which commit 3f28c5a tried to solve.
>
>In the test case, the pci bus is not removed. This means in
>pcibios_add_device(), it will try to add iommu group since the
>pci_bus->is_added is true. And at this moment the pci_dev->kobj->sd is not
>initialized properly. This makes the iommu_add_device() fail.
>
Yes, it's expected behaviour. I'll remove the PCI bus notifier
where we try to add IOMMU group, but fail eventually since
pdev->dev->kobj->sd isn't populated. This mechanism isn't taking
effect in full/partial hotplug cases. It would be separate fix,
I guess.
>Your patch delete the warning at this place, so from the log it looks good. But
>actually, it is not that clear to address the problem. We still have two
>problems:
> 1. iommu group will fail to be created
> 2. iommu group will be created multiple times
>
IOMMU group won't fail to be created since we have the condition:
If the IOMMU group (for one specific PCI device) has been created,
we simply bail without warning messages.
The problem (2) could be resolved by remove the PCI bus notifier.
And it should fail if we try add IOMMU group for PCI device who
had attached IOMMU group.
>My opinion is to make a clear understanding of the order/sequence of the iommu
>group creation in both pci bus removed/not removed cases, than create and
>attach it properly.
>
Please take a look on the function calls listed in the commit log.
For full hotplug case, IOMMU group is attached at (C). For partial
hotplug case (your test case), IOMMU group is bound at (A).
Thanks,
Gavin
>On Tue, Aug 05, 2014 at 06:27:38PM +1000, Gavin Shan wrote:
>>When we take full hotplug to recover from EEH errors, PCI buses
>>could be involved. For the case, the child devices of involved
>>PCI buses can't be attached to IOMMU group properly, which is
>>caused by commit 3f28c5a ("powerpc/powernv: Reduce multi-hit of
>>iommu_add_device()").
>>
>>When adding the PCI devices of the newly created PCI buses to
>>the system, the IOMMU group is expected to be added in (C).
>>(A) fails to bind the IOMMU group because bus->is_added is
>>false. (B) fails because the device doesn't have binding IOMMU
>>table yet. bus->is_added is set to true at end of (C) and
>>pdev->is_added is set to true at (D).
>>
>> pcibios_add_pci_devices()
>> pci_scan_bridge()
>> pci_scan_child_bus()
>> pci_scan_slot()
>> pci_scan_single_device()
>> pci_scan_device()
>> pci_device_add()
>> pcibios_add_device() A: Ignore
>> device_add() B: Ignore
>> pcibios_fixup_bus()
>> pcibios_setup_bus_devices()
>> pcibios_setup_device() C: Hit
>> pcibios_finish_adding_to_bus()
>> pci_bus_add_devices()
>> pci_bus_add_device() D: Add device
>>
>>If the parent PCI bus isn't involved in hotplug, the IOMMU
>>group is expected to be bound in (A).
>>
>>The patch fixes the issue by reverting commit 3f28c5a and remove
>>WARN_ON() in iommu_add_device() to allow calling the function
>>even the specified device already has associated IOMMU group.
>>
>>Cc: <stable@vger.kernel.org> # 3.16+
>>Reported-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
>>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>>---
>> arch/powerpc/kernel/iommu.c | 30 +++++++++++++-----------------
>> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
>> 2 files changed, 14 insertions(+), 18 deletions(-)
>>
>>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>>index 88e3ec6..4663c10 100644
>>--- a/arch/powerpc/kernel/iommu.c
>>+++ b/arch/powerpc/kernel/iommu.c
>>@@ -1120,37 +1120,33 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
>> int iommu_add_device(struct device *dev)
>> {
>> struct iommu_table *tbl;
>>- int ret = 0;
>>
>>- if (WARN_ON(dev->iommu_group)) {
>>- pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>>- dev_name(dev),
>>- iommu_group_id(dev->iommu_group));
>>+ if (dev->iommu_group) {
>>+ pr_debug("%s: Skipping device %s with iommu group %d\n",
>>+ __func__, dev_name(dev),
>>+ iommu_group_id(dev->iommu_group));
>> return -EBUSY;
>> }
>>
>> tbl = get_iommu_table_base(dev);
>> if (!tbl || !tbl->it_group) {
>>- pr_debug("iommu_tce: skipping device %s with no tbl\n",
>>- dev_name(dev));
>>+ pr_debug("%s: Skipping device %s with no tbl\n",
>>+ __func__, dev_name(dev));
>> return 0;
>> }
>>
>>- pr_debug("iommu_tce: adding %s to iommu group %d\n",
>>- dev_name(dev), iommu_group_id(tbl->it_group));
>>+ pr_debug("%s: Adding %s to iommu group %d\n",
>>+ __func__, dev_name(dev),
>>+ iommu_group_id(tbl->it_group));
>>
>> if (PAGE_SIZE < IOMMU_PAGE_SIZE(tbl)) {
>>- pr_err("iommu_tce: unsupported iommu page size.");
>>- pr_err("%s has not been added\n", dev_name(dev));
>>+ pr_err("%s: Invalid IOMMU page size %lx (%lx) on %s\n",
>>+ __func__, IOMMU_PAGE_SIZE(tbl),
>>+ PAGE_SIZE, dev_name(dev));
>> return -EINVAL;
>> }
>>
>>- ret = iommu_group_add_device(tbl->it_group, dev);
>>- if (ret < 0)
>>- pr_err("iommu_tce: %s has not been added, ret=%d\n",
>>- dev_name(dev), ret);
>>-
>>- return ret;
>>+ return iommu_group_add_device(tbl->it_group, dev);
>> }
>> EXPORT_SYMBOL_GPL(iommu_add_device);
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index de19ede..86290eb 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -462,7 +462,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
>>
>> pe = &phb->ioda.pe_array[pdn->pe_number];
>> WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
>>- set_iommu_table_base(&pdev->dev, &pe->tce32_table);
>>+ set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
>> }
>>
>> static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
>>--
>>1.8.3.2
>
>--
>Richard Yang
>Help you, Help me
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Fix IOMMU group lost
From: Gavin Shan @ 2014-08-06 2:48 UTC (permalink / raw)
To: Gavin Shan; +Cc: Wei Yang, linuxppc-dev
In-Reply-To: <20140806020604.GA5244@shangw>
On Wed, Aug 06, 2014 at 12:06:04PM +1000, Gavin Shan wrote:
>On Wed, Aug 06, 2014 at 12:03:23AM +0800, Wei Yang wrote:
>>I just give a shot with patch on PHB3 with hotplug case. From the functional
>>point of view, it works. The iommu group is created and attached with device.
>>While it still has the problem we had which commit 3f28c5a tried to solve.
>>
>>In the test case, the pci bus is not removed. This means in
>>pcibios_add_device(), it will try to add iommu group since the
>>pci_bus->is_added is true. And at this moment the pci_dev->kobj->sd is not
>>initialized properly. This makes the iommu_add_device() fail.
>>
>
>Yes, it's expected behaviour. I'll remove the PCI bus notifier
>where we try to add IOMMU group, but fail eventually since
>pdev->dev->kobj->sd isn't populated. This mechanism isn't taking
>effect in full/partial hotplug cases. It would be separate fix,
>I guess.
>
Rechecked the code for a bit, the notifier can't be removed as
some partial hotplug cases still rely on it to create IOMMU group
if parent bus won't be scanned. However, we can add one more
condition in iommu_add_device() to avoid the problem:
if (!device_is_registered(dev))
return -ENOENT;
I'll add the condition and send out v2 out.
Thanks,
Gavin
>>Your patch delete the warning at this place, so from the log it looks good. But
>>actually, it is not that clear to address the problem. We still have two
>>problems:
>> 1. iommu group will fail to be created
>> 2. iommu group will be created multiple times
>>
>
>IOMMU group won't fail to be created since we have the condition:
>If the IOMMU group (for one specific PCI device) has been created,
>we simply bail without warning messages.
>
>The problem (2) could be resolved by remove the PCI bus notifier.
>And it should fail if we try add IOMMU group for PCI device who
>had attached IOMMU group.
>
>>My opinion is to make a clear understanding of the order/sequence of the iommu
>>group creation in both pci bus removed/not removed cases, than create and
>>attach it properly.
>>
>
>Please take a look on the function calls listed in the commit log.
>For full hotplug case, IOMMU group is attached at (C). For partial
>hotplug case (your test case), IOMMU group is bound at (A).
>
>Thanks,
>Gavin
>
>>On Tue, Aug 05, 2014 at 06:27:38PM +1000, Gavin Shan wrote:
>>>When we take full hotplug to recover from EEH errors, PCI buses
>>>could be involved. For the case, the child devices of involved
>>>PCI buses can't be attached to IOMMU group properly, which is
>>>caused by commit 3f28c5a ("powerpc/powernv: Reduce multi-hit of
>>>iommu_add_device()").
>>>
>>>When adding the PCI devices of the newly created PCI buses to
>>>the system, the IOMMU group is expected to be added in (C).
>>>(A) fails to bind the IOMMU group because bus->is_added is
>>>false. (B) fails because the device doesn't have binding IOMMU
>>>table yet. bus->is_added is set to true at end of (C) and
>>>pdev->is_added is set to true at (D).
>>>
>>> pcibios_add_pci_devices()
>>> pci_scan_bridge()
>>> pci_scan_child_bus()
>>> pci_scan_slot()
>>> pci_scan_single_device()
>>> pci_scan_device()
>>> pci_device_add()
>>> pcibios_add_device() A: Ignore
>>> device_add() B: Ignore
>>> pcibios_fixup_bus()
>>> pcibios_setup_bus_devices()
>>> pcibios_setup_device() C: Hit
>>> pcibios_finish_adding_to_bus()
>>> pci_bus_add_devices()
>>> pci_bus_add_device() D: Add device
>>>
>>>If the parent PCI bus isn't involved in hotplug, the IOMMU
>>>group is expected to be bound in (A).
>>>
>>>The patch fixes the issue by reverting commit 3f28c5a and remove
>>>WARN_ON() in iommu_add_device() to allow calling the function
>>>even the specified device already has associated IOMMU group.
>>>
>>>Cc: <stable@vger.kernel.org> # 3.16+
>>>Reported-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
>>>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>>Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>>>---
>>> arch/powerpc/kernel/iommu.c | 30 +++++++++++++-----------------
>>> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
>>> 2 files changed, 14 insertions(+), 18 deletions(-)
>>>
>>>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>>>index 88e3ec6..4663c10 100644
>>>--- a/arch/powerpc/kernel/iommu.c
>>>+++ b/arch/powerpc/kernel/iommu.c
>>>@@ -1120,37 +1120,33 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
>>> int iommu_add_device(struct device *dev)
>>> {
>>> struct iommu_table *tbl;
>>>- int ret = 0;
>>>
>>>- if (WARN_ON(dev->iommu_group)) {
>>>- pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>>>- dev_name(dev),
>>>- iommu_group_id(dev->iommu_group));
>>>+ if (dev->iommu_group) {
>>>+ pr_debug("%s: Skipping device %s with iommu group %d\n",
>>>+ __func__, dev_name(dev),
>>>+ iommu_group_id(dev->iommu_group));
>>> return -EBUSY;
>>> }
>>>
>>> tbl = get_iommu_table_base(dev);
>>> if (!tbl || !tbl->it_group) {
>>>- pr_debug("iommu_tce: skipping device %s with no tbl\n",
>>>- dev_name(dev));
>>>+ pr_debug("%s: Skipping device %s with no tbl\n",
>>>+ __func__, dev_name(dev));
>>> return 0;
>>> }
>>>
>>>- pr_debug("iommu_tce: adding %s to iommu group %d\n",
>>>- dev_name(dev), iommu_group_id(tbl->it_group));
>>>+ pr_debug("%s: Adding %s to iommu group %d\n",
>>>+ __func__, dev_name(dev),
>>>+ iommu_group_id(tbl->it_group));
>>>
>>> if (PAGE_SIZE < IOMMU_PAGE_SIZE(tbl)) {
>>>- pr_err("iommu_tce: unsupported iommu page size.");
>>>- pr_err("%s has not been added\n", dev_name(dev));
>>>+ pr_err("%s: Invalid IOMMU page size %lx (%lx) on %s\n",
>>>+ __func__, IOMMU_PAGE_SIZE(tbl),
>>>+ PAGE_SIZE, dev_name(dev));
>>> return -EINVAL;
>>> }
>>>
>>>- ret = iommu_group_add_device(tbl->it_group, dev);
>>>- if (ret < 0)
>>>- pr_err("iommu_tce: %s has not been added, ret=%d\n",
>>>- dev_name(dev), ret);
>>>-
>>>- return ret;
>>>+ return iommu_group_add_device(tbl->it_group, dev);
>>> }
>>> EXPORT_SYMBOL_GPL(iommu_add_device);
>>>
>>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>index de19ede..86290eb 100644
>>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>@@ -462,7 +462,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
>>>
>>> pe = &phb->ioda.pe_array[pdn->pe_number];
>>> WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
>>>- set_iommu_table_base(&pdev->dev, &pe->tce32_table);
>>>+ set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
>>> }
>>>
>>> static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
>>>--
>>>1.8.3.2
>>
>>--
>>Richard Yang
>>Help you, Help me
^ permalink raw reply
* [PATCH v2 3/4] vfio_spapr_eeh: Enable compile as a module
From: Alexey Kardashevskiy @ 2014-08-06 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, kvm
In-Reply-To: <1407293313-24894-1-git-send-email-aik@ozlabs.ru>
This adds necessary declarations to the module, otherwise multiple
dynamic linker errors happen:
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/vfio_spapr_eeh.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 1a93e83..a942dd0 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
* published by the Free Software Foundation.
*/
+#include <linux/module.h>
#include <linux/uaccess.h>
#include <linux/vfio.h>
#include <asm/eeh.h>
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC "VFIO IOMMU SPAPR EEH"
+
/* We might build address mapping here for "fast" path later */
#ifdef CONFIG_EEH
@@ -91,3 +96,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
}
EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl);
#endif /* CONFIG_EEH */
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
--
2.0.0
^ permalink raw reply related
* [PATCH v2 2/4] vfio: spapr: Fix build error
From: Alexey Kardashevskiy @ 2014-08-06 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, kvm
In-Reply-To: <1407293313-24894-1-git-send-email-aik@ozlabs.ru>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:
CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/vfio/vfio.c:33:0:
include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
inside parameter list [enabled by default]
:
WRAP arch/powerpc/boot/zImage.pseries
WRAP arch/powerpc/boot/zImage.maple
WRAP arch/powerpc/boot/zImage.pmac
WRAP arch/powerpc/boot/zImage.epapr
MODPOST 1818 modules
ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[removed include "pci.h" in vfio.c]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* removed #include <linux/pci.h> from vfio.c and tested
---
drivers/vfio/Makefile | 4 ++--
drivers/vfio/vfio_spapr_eeh.c | 6 ++++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..4891cca 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_VFIO) += vfio.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
-obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o \
+ vfio_spapr_eeh.o
obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..1a93e83 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -14,15 +14,19 @@
#include <asm/eeh.h>
/* We might build address mapping here for "fast" path later */
+#ifdef CONFIG_EEH
+
int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
{
return eeh_dev_open(pdev);
}
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
{
eeh_dev_release(pdev);
}
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +89,5 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
return ret;
}
+EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl);
+#endif /* CONFIG_EEH */
--
2.0.0
^ permalink raw reply related
* [PATCH v2 1/4] powerpc/eeh: Export eeh_iommu_group_to_pe()
From: Alexey Kardashevskiy @ 2014-08-06 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, kvm
In-Reply-To: <1407293313-24894-1-git-send-email-aik@ozlabs.ru>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
The function is used by VFIO driver, which might be built as a
dynamic module.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group *group)
return edev->pe;
}
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
#endif /* CONFIG_IOMMU_API */
--
2.0.0
^ permalink raw reply related
* [PATCH v2 0/4] vfio: eeh: spapr: Compile and compatibility fixes
From: Alexey Kardashevskiy @ 2014-08-06 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, kvm
Here is what I have in my stash which would be nice to have in 3.17.
Alexey Kardashevskiy (2):
vfio_spapr_eeh: Enable compile as a module
vfio_pci: spapr: Enable VFIO if EEH is not supported
Gavin Shan (2):
powerpc/eeh: Export eeh_iommu_group_to_pe()
vfio: spapr: Fix build error
arch/powerpc/kernel/eeh.c | 1 +
drivers/vfio/Makefile | 4 ++--
drivers/vfio/pci/vfio_pci.c | 6 ++----
drivers/vfio/vfio_spapr_eeh.c | 16 ++++++++++++++++
4 files changed, 21 insertions(+), 6 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v2 4/4] vfio_pci: spapr: Enable VFIO if EEH is not supported
From: Alexey Kardashevskiy @ 2014-08-06 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, Gavin Shan, kvm
In-Reply-To: <1407293313-24894-1-git-send-email-aik@ozlabs.ru>
The existing vfio_pci_open() fails if there is no EEH support for PCI.
This breaks POWER7's P5IOC2 PHB support which this patch brings back.
It is a warning because this should not normally happen on supported
configurations such as POWER8+IODA so we always want to see it in dmesg.
It is _once() as the message may be triggered by non-privileged userspace
and we do not want to pollute dmesg.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* discussed with Ben Herrenschmidt and did s/pr_warn/pr_warn_once/
* updated commit log
---
drivers/vfio/pci/vfio_pci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..68dc8da 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -179,10 +179,8 @@ static int vfio_pci_open(void *device_data)
goto error;
ret = vfio_spapr_pci_eeh_open(vdev->pdev);
- if (ret) {
- vfio_pci_disable(vdev);
- goto error;
- }
+ if (ret)
+ pr_warn_once("EEH is not supported\n");
}
return 0;
--
2.0.0
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_sai: Add asynchronous mode support
From: Nicolin Chen @ 2014-08-06 2:42 UTC (permalink / raw)
To: Varka Bhadram
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, ijc+devicetree,
Li.Xiubo, b42378, b02247, linux-kernel, robh+dt, timur,
Nicolin Chen, broonie, galak, linuxppc-dev
In-Reply-To: <53E0BC95.7040208@gmail.com>
Hi Varka,
On Tue, Aug 05, 2014 at 04:44:29PM +0530, Varka Bhadram wrote:
> On 08/05/2014 04:37 PM, Nicolin Chen wrote:
> >Hi Varka,
> >
> >On Tue, Aug 05, 2014 at 04:29:50PM +0530, Varka Bhadram wrote:
> >>>diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> >>>index 0f4e238..77864f4 100644
> >>>--- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> >>>+++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> >>>@@ -24,6 +24,22 @@ Required properties:
> >>> - big-endian-data: If this property is absent, the little endian mode will
> >>> be in use as default, or the big endian mode will be in use for all the
> >>> fifo data.
> >>>+- fsl,sai-synchronous-rx: This is a boolean property. If present, indicating
> >>>+ that SAI will work in the synchronous mode (sync Tx with Rx) which means
> >>>+ both the transimitter and receiver will send and receive data by following
> >>>+ receiver's bit clocks and frame sync clocks.
> >>>+- fsl,sai-asynchronous: This is a boolean property. If present, indicating
> >>>+ that SAI will work in the asynchronous mode, which means both transimitter
> >>>+ and receiver will send and receive data by following their own bit clocks
> >>>+ and frame sync clocks separately.
> >>>
> >>Would be readable if it like this...
> >>
> >>fsl,sai-synchronous-rx: This is a boolean property. If present, indicating
> >> that SAI will work in the synchronous mode (sync Tx with Rx) which means
> >> both the transimitter and receiver will send and receive data by following
> >> receiver's bit clocks and frame sync clocks.
> >>- fsl,sai-asynchronous: This is a boolean property. If present, indicating
> >> that SAI will work in the asynchronous mode, which means both transimitter
> >> and receiver will send and receive data by following their own bit clocks
> >> and frame sync clocks separately.
> >I agree, however, the doc was initialized in that format. Adding
> >indentations for these two appended lines makes the whole text
> >look weird. :(
>
> Reading comfortably is important for us... :-)
> see this:http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt#L46
I know how to write a binding doc with indentations to make it clear.
What I'm talking about is that the doc was created without indentations,
so I don't feel comfortable to add indentations starting from this patch
while leaving the old lines in totally a different style because It's not
helpful to make people read comfortably at all but only forcing people to
think why these two lines are so special to take some steps back here.
So personally I agree with your idea to make doc more readable. But what
I prefer to do is not having a conversation on the style within this patch
but to create an extra style-refinement patch later after this one.
Let's just focus on the function itself right now. We can later send a
patch to refine this entire doc. Won't you think it's a better idea? :)
Thank you
Nicolin
^ permalink raw reply
* Re: [PATCH v2 2/4] vfio: spapr: Fix build error
From: Alex Williamson @ 2014-08-06 3:12 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1407293313-24894-3-git-send-email-aik@ozlabs.ru>
On Wed, 2014-08-06 at 12:48 +1000, Alexey Kardashevskiy wrote:
> From: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
> The VFIO related components could be built as dynamic modules.
> Unfortunately, CONFIG_EEH can't be configured to "m". The patch
> fixes the build errors when configuring VFIO related components
> as dynamic modules as follows:
>
> CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
> In file included from drivers/vfio/vfio.c:33:0:
> include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
> inside parameter list [enabled by default]
> :
> WRAP arch/powerpc/boot/zImage.pseries
> WRAP arch/powerpc/boot/zImage.maple
> WRAP arch/powerpc/boot/zImage.pmac
> WRAP arch/powerpc/boot/zImage.epapr
> MODPOST 1818 modules
> ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
> undefined!
> ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
> ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!
>
> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> [removed include "pci.h" in vfio.c]
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * removed #include <linux/pci.h> from vfio.c and tested
I also commented regarding the ifdef around all of vfio_spapr_eeh.c:
Why not add a new CONFIG_VFIO_SPAPR_EEH option to handle this
instead?
Did you disagree? The ifdef is pretty ugly.
> ---
> drivers/vfio/Makefile | 4 ++--
> drivers/vfio/vfio_spapr_eeh.c | 6 ++++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 50e30bc..4891cca 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -1,5 +1,5 @@
> obj-$(CONFIG_VFIO) += vfio.o
> obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
> -obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
> -obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o \
> + vfio_spapr_eeh.o
> obj-$(CONFIG_VFIO_PCI) += pci/
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index f834b4c..1a93e83 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -14,15 +14,19 @@
> #include <asm/eeh.h>
>
> /* We might build address mapping here for "fast" path later */
> +#ifdef CONFIG_EEH
> +
> int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> {
> return eeh_dev_open(pdev);
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>
> void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> {
> eeh_dev_release(pdev);
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
>
> long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> unsigned int cmd, unsigned long arg)
> @@ -85,3 +89,5 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(vfio_spapr_iommu_eeh_ioctl);
> +#endif /* CONFIG_EEH */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox