* [PATCHv4 01/11] irqdomain: add irq_alloc_mapping() function
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions Thomas Petazzoni
` (9 subsequent siblings)
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
This commit extends the irqdomain subsystem with an
irq_alloc_mapping() function which allows to let the irqdomain code
find an available hwirq number in the range [ 0 ; domain size ] for
the given domain, and create a virq mapping for it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
include/linux/irqdomain.h | 2 ++
kernel/irq/irqdomain.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 02f7658..5f9c3ff 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
extern unsigned int irq_find_mapping(struct irq_domain *host,
irq_hw_number_t hwirq);
extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
+extern unsigned int irq_alloc_mapping(struct irq_domain *host,
+ irq_hw_number_t *hwirq);
extern int irq_create_strict_mappings(struct irq_domain *domain,
unsigned int irq_base,
irq_hw_number_t hwirq_base, int count);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 836a0f7..be82d2e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)
EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
/**
+ * irq_alloc_mapping() - Allocate an irq for mapping
+ * @domain: domain to allocate the irq for or NULL for default domain
+ * @hwirq: reference to the returned hwirq
+ *
+ * This routine are used for irq controllers which can choose the
+ * hardware interrupt number from a range [ 0 ; domain size ], such as
+ * is often the case with PCI MSI controllers. The function will
+ * returned the allocated hwirq number in the hwirq pointer, and the
+ * corresponding virq number as the return value.
+ */
+unsigned int irq_alloc_mapping(struct irq_domain *domain,
+ irq_hw_number_t *out_hwirq)
+{
+ irq_hw_number_t hwirq;
+
+ pr_debug("irq_alloc_mapping(0x%p)\n", domain);
+
+ for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
+ if (!irq_find_mapping(domain, hwirq))
+ break;
+
+ if (hwirq == domain->hwirq_max) {
+ pr_debug("-> no available hwirq found\n");
+ return 0;
+ }
+
+ *out_hwirq = hwirq;
+ return irq_create_mapping(domain, hwirq);
+}
+EXPORT_SYMBOL_GPL(irq_alloc_mapping);
+
+/**
* irq_create_mapping() - Map a hardware interrupt into linux irq space
* @domain: domain owning this hardware interrupt or NULL for default domain
* @hwirq: hardware irq number in that domain space
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 01/11] irqdomain: add irq_alloc_mapping() function Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-02 0:53 ` Michael Ellerman
2013-07-05 21:32 ` Bjorn Helgaas
2013-07-01 13:42 ` [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option Thomas Petazzoni
` (8 subsequent siblings)
10 siblings, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.
Note that we keep a separate, non-weak, function
default_teardown_msi_irqs() for the default behavior of the
arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
x86 PCI code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
---
arch/mips/include/asm/pci.h | 5 -----
arch/powerpc/include/asm/pci.h | 5 -----
arch/s390/include/asm/pci.h | 4 ----
arch/x86/include/asm/pci.h | 28 --------------------------
arch/x86/kernel/x86_init.c | 21 ++++++++++++++++++++
drivers/pci/msi.c | 45 +++++++++++++++++++-----------------------
include/linux/msi.h | 7 ++++++-
7 files changed, 47 insertions(+), 68 deletions(-)
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index b8e24fd..031f4c1 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
extern char * (*pcibios_plat_setup)(char *str);
#ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
/* Decide whether to display the domain number in /proc */
extern int pci_proc_domain(struct pci_bus *bus);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
struct vm_area_struct;
/* Map a range of PCI memory or I/O space for a device into user space */
int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6c18012..8641e8d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
int pci_domain_nr(struct pci_bus *);
int pci_proc_domain(struct pci_bus *);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-
#define ZPCI_BUS_NR 0 /* default bus number */
#define ZPCI_DEVFN 0 /* default device number */
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..8c61de0 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
extern void pci_iommu_alloc(void);
#ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
- return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
- x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
- x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
/* implemented in arch/x86/kernel/apic/io_apic. */
struct msi_desc;
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev, int irq);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#else
#define native_setup_msi_irqs NULL
#define native_teardown_msi_irq NULL
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..a2b189c 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
.setup_hpet_msi = default_setup_hpet_msi,
};
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+ x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ x86_msi.restore_msi_irqs(dev, irq);
+}
+
struct x86_io_apic_ops x86_io_apic_ops = {
.init = native_io_apic_init_mappings,
.read = native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 2c10752..289fbfd 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
/* Arch hooks */
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
- return 0;
+ return -EINVAL;
}
-#endif
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+ return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
return 0;
}
-#endif
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
void default_teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry;
@@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
arch_teardown_msi_irq(entry->irq + i);
}
}
-#endif
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return default_teardown_msi_irqs(dev);
+}
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_restore_msi_irqs(struct pci_dev *dev, int irq)
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
{
struct msi_desc *entry;
@@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
if (entry)
write_msi_msg(irq, &entry->msg);
}
-#endif
static void msi_set_enable(struct pci_dev *dev, int enable)
{
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 20c2d6d..c82ff8d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -50,12 +50,17 @@ struct msi_desc {
};
/*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
*/
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
void arch_teardown_msi_irq(unsigned int irq);
int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
void arch_teardown_msi_irqs(struct pci_dev *dev);
int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
#endif /* LINUX_MSI_H */
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-01 13:42 ` [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions Thomas Petazzoni
@ 2013-07-02 0:53 ` Michael Ellerman
2013-07-02 5:30 ` Thomas Petazzoni
2013-07-05 21:32 ` Bjorn Helgaas
1 sibling, 1 reply; 38+ messages in thread
From: Michael Ellerman @ 2013-07-02 0:53 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
The MSI code used to use weak functions, until we discovered they were
being miscompiled on some toolchains (11df1f0). I assume these days
we're confident they work correctly.
cheers
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-02 0:53 ` Michael Ellerman
@ 2013-07-02 5:30 ` Thomas Petazzoni
2013-07-02 6:52 ` Michael Ellerman
2013-07-02 17:14 ` Bjorn Helgaas
0 siblings, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-02 5:30 UTC (permalink / raw)
To: linux-arm-kernel
Dear Michael Ellerman,
On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> > Until now, the MSI architecture-specific functions could be overloaded
> > using a fairly complex set of #define and compile-time
> > conditionals. In order to prepare for the introduction of the msi_chip
> > infrastructure, it is desirable to switch all those functions to use
> > the 'weak' mechanism. This commit converts all the architectures that
> > were overidding those MSI functions to use the new strategy.
>
> The MSI code used to use weak functions, until we discovered they were
> being miscompiled on some toolchains (11df1f0). I assume these days
> we're confident they work correctly.
Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
view on this?
Another option would be to have architecture register some msi_arch_ops
structure, with a set of operations, which I believe is a pattern that
is more widespread in the kernel than weak functions.
Thoughts?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-02 5:30 ` Thomas Petazzoni
@ 2013-07-02 6:52 ` Michael Ellerman
2013-07-02 17:14 ` Bjorn Helgaas
1 sibling, 0 replies; 38+ messages in thread
From: Michael Ellerman @ 2013-07-02 6:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 02, 2013 at 07:30:37AM +0200, Thomas Petazzoni wrote:
> Dear Michael Ellerman,
>
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> > On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> > > Until now, the MSI architecture-specific functions could be overloaded
> > > using a fairly complex set of #define and compile-time
> > > conditionals. In order to prepare for the introduction of the msi_chip
> > > infrastructure, it is desirable to switch all those functions to use
> > > the 'weak' mechanism. This commit converts all the architectures that
> > > were overidding those MSI functions to use the new strategy.
> >
> > The MSI code used to use weak functions, until we discovered they were
> > being miscompiled on some toolchains (11df1f0). I assume these days
> > we're confident they work correctly.
>
> Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
> affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
> view on this?
Stop press.
I went back and found the old threads on this, it's been a while. It
looks like it was only gcc 4.1.[01] that miscompiled. The reference to
gcc 4.3.2 was WRT ellision of the unused code, which is a separate
issue.
The kernel blacklists gcc 4.1.[01] (see f9d1425), so weak should be
safe to use.
We merged the change to the PCI code anyway because we thought it was
nicer and it also avoided any problems with weak.
So pretend I never said anything :)
cheers
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-02 5:30 ` Thomas Petazzoni
2013-07-02 6:52 ` Michael Ellerman
@ 2013-07-02 17:14 ` Bjorn Helgaas
1 sibling, 0 replies; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-02 17:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 11:30 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Michael Ellerman,
>
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
>> On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
>> > Until now, the MSI architecture-specific functions could be overloaded
>> > using a fairly complex set of #define and compile-time
>> > conditionals. In order to prepare for the introduction of the msi_chip
>> > infrastructure, it is desirable to switch all those functions to use
>> > the 'weak' mechanism. This commit converts all the architectures that
>> > were overidding those MSI functions to use the new strategy.
>>
>> The MSI code used to use weak functions, until we discovered they were
>> being miscompiled on some toolchains (11df1f0). I assume these days
>> we're confident they work correctly.
>
> Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
> affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
> view on this?
There *were* compilation issues with weak functions, but AFAIK they've
been resolved and there's no reason to avoid them. Commit f9d142500
addressed this.
Bjorn
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-01 13:42 ` [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions Thomas Petazzoni
2013-07-02 0:53 ` Michael Ellerman
@ 2013-07-05 21:32 ` Bjorn Helgaas
2013-07-05 21:34 ` Bjorn Helgaas
1 sibling, 1 reply; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
>
> Note that we keep a separate, non-weak, function
> default_teardown_msi_irqs() for the default behavior of the
> arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
> x86 PCI code.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem@davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> arch/mips/include/asm/pci.h | 5 -----
> arch/powerpc/include/asm/pci.h | 5 -----
> arch/s390/include/asm/pci.h | 4 ----
> arch/x86/include/asm/pci.h | 28 --------------------------
> arch/x86/kernel/x86_init.c | 21 ++++++++++++++++++++
> drivers/pci/msi.c | 45 +++++++++++++++++++-----------------------
> include/linux/msi.h | 7 ++++++-
> 7 files changed, 47 insertions(+), 68 deletions(-)
>
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index b8e24fd..031f4c1 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> return channel ? 15 : 14;
> }
>
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -/* MSI arch hook for OCTEON */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#endif
> -
> extern char * (*pcibios_plat_setup)(char *str);
>
> #ifdef CONFIG_OF
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 6653f27..95145a1 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
> /* Decide whether to display the domain number in /proc */
> extern int pci_proc_domain(struct pci_bus *bus);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -#define arch_msi_check_device arch_msi_check_device
> -
> struct vm_area_struct;
> /* Map a range of PCI memory or I/O space for a device into user space */
> int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index 6c18012..8641e8d 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
> int pci_domain_nr(struct pci_bus *);
> int pci_proc_domain(struct pci_bus *);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -
> #define ZPCI_BUS_NR 0 /* default bus number */
> #define ZPCI_DEVFN 0 /* default device number */
>
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index d9e9e6c..8c61de0 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
> extern void pci_iommu_alloc(void);
>
> #ifdef CONFIG_PCI_MSI
> -/* MSI arch specific hooks */
> -static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> - return x86_msi.setup_msi_irqs(dev, nvec, type);
> -}
> -
> -static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
> -{
> - x86_msi.teardown_msi_irqs(dev);
> -}
> -
> -static inline void x86_teardown_msi_irq(unsigned int irq)
> -{
> - x86_msi.teardown_msi_irq(irq);
> -}
> -static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
> -{
> - x86_msi.restore_msi_irqs(dev, irq);
> -}
> -#define arch_setup_msi_irqs x86_setup_msi_irqs
> -#define arch_teardown_msi_irqs x86_teardown_msi_irqs
> -#define arch_teardown_msi_irq x86_teardown_msi_irq
> -#define arch_restore_msi_irqs x86_restore_msi_irqs
> /* implemented in arch/x86/kernel/apic/io_apic. */
> struct msi_desc;
> int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> @@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
> void native_restore_msi_irqs(struct pci_dev *dev, int irq);
> int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> unsigned int irq_base, unsigned int irq_offset);
> -/* default to the implementation in drivers/lib/msi.c */
> -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_teardown_msi_irqs(struct pci_dev *dev);
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq);
> #else
> #define native_setup_msi_irqs NULL
> #define native_teardown_msi_irq NULL
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index 45a14db..a2b189c 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
> .setup_hpet_msi = default_setup_hpet_msi,
> };
>
> +/* MSI arch specific hooks */
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> + return x86_msi.setup_msi_irqs(dev, nvec, type);
> +}
> +
> +void arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> + x86_msi.teardown_msi_irqs(dev);
> +}
> +
> +void arch_teardown_msi_irq(unsigned int irq)
> +{
> + x86_msi.teardown_msi_irq(irq);
> +}
> +
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
> +{
> + x86_msi.restore_msi_irqs(dev, irq);
> +}
> +
> struct x86_io_apic_ops x86_io_apic_ops = {
> .init = native_io_apic_init_mappings,
> .read = native_io_apic_read,
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 2c10752..289fbfd 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
>
> /* Arch hooks */
>
> -#ifndef arch_msi_check_device
> -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> {
> - return 0;
> + return -EINVAL;
> }
> -#endif
>
> -#ifndef arch_setup_msi_irqs
> -# define arch_setup_msi_irqs default_setup_msi_irqs
> -# define HAVE_DEFAULT_MSI_SETUP_IRQS
> -#endif
> +void __weak arch_teardown_msi_irq(unsigned int irq)
> +{
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
> -int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +{
> + return 0;
> +}
> +
> +int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> {
> struct msi_desc *entry;
> int ret;
> @@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>
> return 0;
> }
> -#endif
>
> -#ifndef arch_teardown_msi_irqs
> -# define arch_teardown_msi_irqs default_teardown_msi_irqs
> -# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#endif
> -
> -#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> +/*
> + * We have a default implementation available as a separate non-weak
> + * function, as it is used by the Xen x86 PCI code
> + */
> void default_teardown_msi_irqs(struct pci_dev *dev)
> {
> struct msi_desc *entry;
> @@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
> arch_teardown_msi_irq(entry->irq + i);
> }
> }
> -#endif
>
> -#ifndef arch_restore_msi_irqs
> -# define arch_restore_msi_irqs default_restore_msi_irqs
> -# define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -#endif
> +void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> + return default_teardown_msi_irqs(dev);
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> +void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
> {
> struct msi_desc *entry;
>
> @@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> if (entry)
> write_msi_msg(irq, &entry->msg);
> }
> -#endif
>
> static void msi_set_enable(struct pci_dev *dev, int enable)
> {
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 20c2d6d..c82ff8d 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -50,12 +50,17 @@ struct msi_desc {
> };
>
> /*
> - * The arch hook for setup up msi irqs
> + * The arch hooks to setup up msi irqs. Those functions are
> + * implemented as weak symbols so that they /can/ be overriden by
> + * architecture specific code if needed.
> */
> int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
> void arch_teardown_msi_irq(unsigned int irq);
> int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> void arch_teardown_msi_irqs(struct pci_dev *dev);
> int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
> +
> +void default_teardown_msi_irqs(struct pci_dev *dev);
>
> #endif /* LINUX_MSI_H */
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-05 21:32 ` Bjorn Helgaas
@ 2013-07-05 21:34 ` Bjorn Helgaas
2013-07-05 21:40 ` Thomas Petazzoni
0 siblings, 1 reply; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 5, 2013 at 3:32 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
But please update your subject line to use consistent capitalization, e.g.,
PCI: Use weak ...
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
2013-07-05 21:34 ` Bjorn Helgaas
@ 2013-07-05 21:40 ` Thomas Petazzoni
0 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-05 21:40 UTC (permalink / raw)
To: linux-arm-kernel
Dear Bjorn Helgaas,
On Fri, 5 Jul 2013 15:34:10 -0600, Bjorn Helgaas wrote:
> On Fri, Jul 5, 2013 at 3:32 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> But please update your subject line to use consistent capitalization, e.g.,
>
> PCI: Use weak ...
Sure, will do.
Would it be possible to get Tested-by and/or Acked-by from the
different architecture maintainers affected by PATCH 02/11 and PATCH
03/11 ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 01/11] irqdomain: add irq_alloc_mapping() function Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-05 21:37 ` Bjorn Helgaas
2013-07-01 13:42 ` [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
` (7 subsequent siblings)
10 siblings, 1 reply; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Now that we have weak versions for each of the PCI MSI architecture
functions, we can actually build the MSI support for all platforms,
regardless of whether they provide or not architecture-specific
versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
hidden kconfig boolean becomes useless, and this patch gets rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
---
arch/arm/Kconfig | 1 -
arch/ia64/Kconfig | 1 -
arch/mips/Kconfig | 2 --
arch/powerpc/Kconfig | 1 -
arch/s390/Kconfig | 1 -
arch/sparc/Kconfig | 1 -
arch/tile/Kconfig | 1 -
arch/x86/Kconfig | 1 -
drivers/pci/Kconfig | 4 ----
9 files changed, 13 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8ab5962..3413679 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -435,7 +435,6 @@ config ARCH_NETX
config ARCH_IOP13XX
bool "IOP13xx-based"
depends on MMU
- select ARCH_SUPPORTS_MSI
select CPU_XSC3
select NEED_MACH_MEMORY_H
select NEED_RET_TO_USER
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 1a2b774..943d425 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -9,7 +9,6 @@ config IA64
select PCI if (!IA64_HP_SIM)
select ACPI if (!IA64_HP_SIM)
select PM if (!IA64_HP_SIM)
- select ARCH_SUPPORTS_MSI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7a58ab9..96c1225 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD
select SYS_HAS_CPU_CAVIUM_OCTEON
select SWAP_IO_SPACE
select HW_HAS_PCI
- select ARCH_SUPPORTS_MSI
select ZONE_DMA32
select USB_ARCH_HAS_OHCI
select USB_ARCH_HAS_EHCI
@@ -799,7 +798,6 @@ config NLM_XLR_BOARD
select CEVT_R4K
select CSRC_R4K
select IRQ_CPU
- select ARCH_SUPPORTS_MSI
select ZONE_DMA32 if 64BIT
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..f9d9d8e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -734,7 +734,6 @@ config PCI
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
default PCI_QSPAN if !4xx && !CPM2 && 8xx
- select ARCH_SUPPORTS_MSI
select GENERIC_PCI_IOMAP
help
Find out whether your system includes a PCI bus. PCI is the name of
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..9a6225b 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -429,7 +429,6 @@ menuconfig PCI
bool "PCI support"
default n
depends on 64BIT
- select ARCH_SUPPORTS_MSI
select PCI_MSI
help
Enable PCI support.
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 9ac9f16..822e1a1 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -52,7 +52,6 @@ config SPARC32
config SPARC64
def_bool 64BIT
- select ARCH_SUPPORTS_MSI
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_GRAPH_FP_TEST
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 3aa3766..d2d519c 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -379,7 +379,6 @@ config PCI
select PCI_DOMAINS
select GENERIC_PCI_IOMAP
select TILE_GXIO_TRIO if TILEGX
- select ARCH_SUPPORTS_MSI if TILEGX
select PCI_MSI if TILEGX
---help---
Enable PCI root complex support, so PCIe endpoint devices can
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 685692c..4229ce0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
- select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
---help---
Find out whether you have a PCI motherboard. PCI is the name of a
bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index ac45398..3d4c061 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,13 +1,9 @@
#
# PCI configuration
#
-config ARCH_SUPPORTS_MSI
- bool
-
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on ARCH_SUPPORTS_MSI
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-01 13:42 ` [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option Thomas Petazzoni
@ 2013-07-05 21:37 ` Bjorn Helgaas
2013-07-05 21:45 ` Thomas Petazzoni
0 siblings, 1 reply; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:37 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Now that we have weak versions for each of the PCI MSI architecture
> functions, we can actually build the MSI support for all platforms,
> regardless of whether they provide or not architecture-specific
> versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
> hidden kconfig boolean becomes useless, and this patch gets rid of it.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem@davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched,
but I think it's reasonable to put at least patches 2 & 3 in -next
soon after v3.11-rc1, so we should have time to shake out issues.
> ---
> arch/arm/Kconfig | 1 -
> arch/ia64/Kconfig | 1 -
> arch/mips/Kconfig | 2 --
> arch/powerpc/Kconfig | 1 -
> arch/s390/Kconfig | 1 -
> arch/sparc/Kconfig | 1 -
> arch/tile/Kconfig | 1 -
> arch/x86/Kconfig | 1 -
> drivers/pci/Kconfig | 4 ----
> 9 files changed, 13 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8ab5962..3413679 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -435,7 +435,6 @@ config ARCH_NETX
> config ARCH_IOP13XX
> bool "IOP13xx-based"
> depends on MMU
> - select ARCH_SUPPORTS_MSI
> select CPU_XSC3
> select NEED_MACH_MEMORY_H
> select NEED_RET_TO_USER
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 1a2b774..943d425 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -9,7 +9,6 @@ config IA64
> select PCI if (!IA64_HP_SIM)
> select ACPI if (!IA64_HP_SIM)
> select PM if (!IA64_HP_SIM)
> - select ARCH_SUPPORTS_MSI
> select HAVE_UNSTABLE_SCHED_CLOCK
> select HAVE_IDE
> select HAVE_OPROFILE
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 7a58ab9..96c1225 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD
> select SYS_HAS_CPU_CAVIUM_OCTEON
> select SWAP_IO_SPACE
> select HW_HAS_PCI
> - select ARCH_SUPPORTS_MSI
> select ZONE_DMA32
> select USB_ARCH_HAS_OHCI
> select USB_ARCH_HAS_EHCI
> @@ -799,7 +798,6 @@ config NLM_XLR_BOARD
> select CEVT_R4K
> select CSRC_R4K
> select IRQ_CPU
> - select ARCH_SUPPORTS_MSI
> select ZONE_DMA32 if 64BIT
> select SYNC_R4K
> select SYS_HAS_EARLY_PRINTK
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c33e3ad..f9d9d8e 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -734,7 +734,6 @@ config PCI
> default y if !40x && !CPM2 && !8xx && !PPC_83xx \
> && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
> default PCI_QSPAN if !4xx && !CPM2 && 8xx
> - select ARCH_SUPPORTS_MSI
> select GENERIC_PCI_IOMAP
> help
> Find out whether your system includes a PCI bus. PCI is the name of
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index da183c5..9a6225b 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -429,7 +429,6 @@ menuconfig PCI
> bool "PCI support"
> default n
> depends on 64BIT
> - select ARCH_SUPPORTS_MSI
> select PCI_MSI
> help
> Enable PCI support.
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 9ac9f16..822e1a1 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -52,7 +52,6 @@ config SPARC32
>
> config SPARC64
> def_bool 64BIT
> - select ARCH_SUPPORTS_MSI
> select HAVE_FUNCTION_TRACER
> select HAVE_FUNCTION_GRAPH_TRACER
> select HAVE_FUNCTION_GRAPH_FP_TEST
> diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
> index 3aa3766..d2d519c 100644
> --- a/arch/tile/Kconfig
> +++ b/arch/tile/Kconfig
> @@ -379,7 +379,6 @@ config PCI
> select PCI_DOMAINS
> select GENERIC_PCI_IOMAP
> select TILE_GXIO_TRIO if TILEGX
> - select ARCH_SUPPORTS_MSI if TILEGX
> select PCI_MSI if TILEGX
> ---help---
> Enable PCI root complex support, so PCIe endpoint devices can
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 685692c..4229ce0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)"
> config PCI
> bool "PCI support"
> default y
> - select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
> ---help---
> Find out whether you have a PCI motherboard. PCI is the name of a
> bus system, i.e. the way the CPU talks to the other stuff inside
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index ac45398..3d4c061 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,13 +1,9 @@
> #
> # PCI configuration
> #
> -config ARCH_SUPPORTS_MSI
> - bool
> -
> config PCI_MSI
> bool "Message Signaled Interrupts (MSI and MSI-X)"
> depends on PCI
> - depends on ARCH_SUPPORTS_MSI
> help
> This allows device drivers to enable MSI (Message Signaled
> Interrupts). Message Signaled Interrupts enable a device to
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-05 21:37 ` Bjorn Helgaas
@ 2013-07-05 21:45 ` Thomas Petazzoni
2013-07-06 13:54 ` Jason Cooper
0 siblings, 1 reply; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-05 21:45 UTC (permalink / raw)
To: linux-arm-kernel
Dear Bjorn Helgaas,
On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Again, please update the subject line to "PCI: Remove ..."
>
> I doubt that you'll get explicit acks from all the arches you touched,
> but I think it's reasonable to put at least patches 2 & 3 in -next
> soon after v3.11-rc1, so we should have time to shake out issues.
Sure. Which merge strategy do you suggest for this patch series, which
touches a number of different areas, and has some build-time
dependencies between the patches (if needed, I can detail those build
time dependencies to help figuring out the best strategy).
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-05 21:45 ` Thomas Petazzoni
@ 2013-07-06 13:54 ` Jason Cooper
2013-07-06 15:40 ` Bjorn Helgaas
0 siblings, 1 reply; 38+ messages in thread
From: Jason Cooper @ 2013-07-06 13:54 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
> Dear Bjorn Helgaas,
>
> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >
> > Again, please update the subject line to "PCI: Remove ..."
> >
> > I doubt that you'll get explicit acks from all the arches you touched,
> > but I think it's reasonable to put at least patches 2 & 3 in -next
> > soon after v3.11-rc1, so we should have time to shake out issues.
>
> Sure. Which merge strategy do you suggest for this patch series, which
> touches a number of different areas, and has some build-time
> dependencies between the patches (if needed, I can detail those build
> time dependencies to help figuring out the best strategy).
If we end up handling this the same as the of/pci & mvebu-pcie series
(whole series through mvebu -> arm-soc) I can have it up in -next within
a few days of -rc1. Just let me know.
hth,
Jason.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-06 13:54 ` Jason Cooper
@ 2013-07-06 15:40 ` Bjorn Helgaas
2013-07-06 16:17 ` Jason Cooper
0 siblings, 1 reply; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-06 15:40 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
>> Dear Bjorn Helgaas,
>>
>> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
>>
>> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>> >
>> > Again, please update the subject line to "PCI: Remove ..."
>> >
>> > I doubt that you'll get explicit acks from all the arches you touched,
>> > but I think it's reasonable to put at least patches 2 & 3 in -next
>> > soon after v3.11-rc1, so we should have time to shake out issues.
>>
>> Sure. Which merge strategy do you suggest for this patch series, which
>> touches a number of different areas, and has some build-time
>> dependencies between the patches (if needed, I can detail those build
>> time dependencies to help figuring out the best strategy).
>
> If we end up handling this the same as the of/pci & mvebu-pcie series
> (whole series through mvebu -> arm-soc) I can have it up in -next within
> a few days of -rc1. Just let me know.
That sounds fine with me. I don't think it's worth trying to split
out the drivers/pci stuff and trying to coordinate it going through
different trees.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-06 15:40 ` Bjorn Helgaas
@ 2013-07-06 16:17 ` Jason Cooper
2013-07-06 16:33 ` Thomas Petazzoni
0 siblings, 1 reply; 38+ messages in thread
From: Jason Cooper @ 2013-07-06 16:17 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jul 06, 2013 at 09:40:55AM -0600, Bjorn Helgaas wrote:
> On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
> >> Dear Bjorn Helgaas,
> >>
> >> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
> >>
> >> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> >
> >> > Again, please update the subject line to "PCI: Remove ..."
> >> >
> >> > I doubt that you'll get explicit acks from all the arches you touched,
> >> > but I think it's reasonable to put at least patches 2 & 3 in -next
> >> > soon after v3.11-rc1, so we should have time to shake out issues.
> >>
> >> Sure. Which merge strategy do you suggest for this patch series, which
> >> touches a number of different areas, and has some build-time
> >> dependencies between the patches (if needed, I can detail those build
> >> time dependencies to help figuring out the best strategy).
> >
> > If we end up handling this the same as the of/pci & mvebu-pcie series
> > (whole series through mvebu -> arm-soc) I can have it up in -next within
> > a few days of -rc1. Just let me know.
>
> That sounds fine with me. I don't think it's worth trying to split
> out the drivers/pci stuff and trying to coordinate it going through
> different trees.
Ok, will do.
Thomas, I assume there will be one more version to address Bjorn's last
comments?
thx,
Jason.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
2013-07-06 16:17 ` Jason Cooper
@ 2013-07-06 16:33 ` Thomas Petazzoni
0 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-06 16:33 UTC (permalink / raw)
To: linux-arm-kernel
Dear Jason Cooper,
On Sat, 6 Jul 2013 12:17:43 -0400, Jason Cooper wrote:
> > > If we end up handling this the same as the of/pci & mvebu-pcie series
> > > (whole series through mvebu -> arm-soc) I can have it up in -next within
> > > a few days of -rc1. Just let me know.
> >
> > That sounds fine with me. I don't think it's worth trying to split
> > out the drivers/pci stuff and trying to coordinate it going through
> > different trees.
>
> Ok, will do.
>
> Thomas, I assume there will be one more version to address Bjorn's last
> comments?
Yes, indeed. I was waiting to see if Thierry Redding would give some
additional feedback on Bjorn's comment, but if he doesn't, I'll resend
an updated version, most likely next week.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (2 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-05 21:51 ` Bjorn Helgaas
2013-07-01 13:42 ` [PATCHv4 05/11] of: pci: add registry of MSI chips Thomas Petazzoni
` (6 subsequent siblings)
10 siblings, 1 reply; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Thierry Reding <thierry.reding@avionic-design.de>
The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.
This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/pci/msi.c | 22 ++++++++++++++++++++++
drivers/pci/probe.c | 1 +
include/linux/msi.h | 11 +++++++++++
include/linux/pci.h | 1 +
4 files changed, 35 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 289fbfd..62eb3d5 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
+ struct msi_chip *chip = dev->bus->msi;
+
+ if (chip && chip->setup_irq) {
+ int err;
+
+ err = chip->setup_irq(chip, dev, desc);
+ if (err < 0)
+ return err;
+
+ irq_set_chip_data(desc->irq, chip);
+ return err;
+ }
+
return -EINVAL;
}
void __weak arch_teardown_msi_irq(unsigned int irq)
{
+ struct msi_chip *chip = irq_get_chip_data(irq);
+
+ if (chip && chip->teardown_irq)
+ chip->teardown_irq(chip, irq);
}
int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
{
+ struct msi_chip *chip = dev->bus->msi;
+
+ if (chip && chip->check_device)
+ return chip->check_device(chip, dev, nvec, type);
+
return 0;
}
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 70f10fa..c8591e4 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
child->parent = parent;
child->ops = parent->ops;
+ child->msi = parent->msi;
child->sysdata = parent->sysdata;
child->bus_flags = parent->bus_flags;
diff --git a/include/linux/msi.h b/include/linux/msi.h
index c82ff8d..5b357d92 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
void default_teardown_msi_irqs(struct pci_dev *dev);
+struct msi_chip {
+ struct module *owner;
+ struct device *dev;
+
+ int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+ struct msi_desc *desc);
+ void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+ int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+ int nvec, int type);
+};
+
#endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 3a24e4f..7ffc012 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -432,6 +432,7 @@ struct pci_bus {
struct resource busn_res; /* bus numbers routed to this bus */
struct pci_ops *ops; /* configuration access functions */
+ struct msi_chip *msi; /* MSI controller */
void *sysdata; /* hook for sys-specific extension */
struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-01 13:42 ` [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
@ 2013-07-05 21:51 ` Bjorn Helgaas
2013-07-05 22:08 ` Thomas Petazzoni
2013-07-08 14:51 ` Thomas Petazzoni
0 siblings, 2 replies; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> From: Thierry Reding <thierry.reding@avionic-design.de>
>
> The new struct msi_chip is used to associated an MSI controller with a
> PCI bus. It is automatically handed down from the root to its children
> during bus enumeration.
>
> This patch provides default (weak) implementations for the architecture-
> specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> and arch_msi_check_device()) which check if a PCI device's bus has an
> attached MSI chip and forward the call appropriately.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
I'm OK with this patch in principle, but I do have a couple comments below.
> ---
> drivers/pci/msi.c | 22 ++++++++++++++++++++++
> drivers/pci/probe.c | 1 +
> include/linux/msi.h | 11 +++++++++++
> include/linux/pci.h | 1 +
> 4 files changed, 35 insertions(+)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 289fbfd..62eb3d5 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
>
> int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> {
> + struct msi_chip *chip = dev->bus->msi;
> +
> + if (chip && chip->setup_irq) {
> + int err;
> +
> + err = chip->setup_irq(chip, dev, desc);
> + if (err < 0)
> + return err;
> +
> + irq_set_chip_data(desc->irq, chip);
> + return err;
> + }
> +
> return -EINVAL;
It's sub-optimal to indent the whole body of a function like this. I
think this is a bit more readable:
if (!chip || !chip->setup_irq)
return -EINVAL
err = chip->setup_irq(...);
...
return err;
The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
is a bit unclear. Apparently it can return negative values (errors)
or positive values (not sure what they mean), or zero (again, not
sure). A comment would clear this up.
It might even be worth introducing a no-op chip with pointers to no-op
functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on
that -- certainly there are many examples of code that *does* make
these checks everywhere -- so I'll ack it either way.
> }
>
> void __weak arch_teardown_msi_irq(unsigned int irq)
> {
> + struct msi_chip *chip = irq_get_chip_data(irq);
> +
> + if (chip && chip->teardown_irq)
> + chip->teardown_irq(chip, irq);
> }
>
> int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> {
> + struct msi_chip *chip = dev->bus->msi;
> +
> + if (chip && chip->check_device)
> + return chip->check_device(chip, dev, nvec, type);
> +
These functions are poorly named. They give no clue what
"check_device" means. Are we checking that it exists, that it
supports some property, that it's enabled, ... ?
> return 0;
> }
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 70f10fa..c8591e4 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>
> child->parent = parent;
> child->ops = parent->ops;
> + child->msi = parent->msi;
> child->sysdata = parent->sysdata;
> child->bus_flags = parent->bus_flags;
>
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index c82ff8d..5b357d92 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
>
> void default_teardown_msi_irqs(struct pci_dev *dev);
>
> +struct msi_chip {
> + struct module *owner;
> + struct device *dev;
> +
> + int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> + struct msi_desc *desc);
> + void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> + int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> + int nvec, int type);
> +};
> +
> #endif /* LINUX_MSI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 3a24e4f..7ffc012 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -432,6 +432,7 @@ struct pci_bus {
> struct resource busn_res; /* bus numbers routed to this bus */
>
> struct pci_ops *ops; /* configuration access functions */
> + struct msi_chip *msi; /* MSI controller */
> void *sysdata; /* hook for sys-specific extension */
> struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
>
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-05 21:51 ` Bjorn Helgaas
@ 2013-07-05 22:08 ` Thomas Petazzoni
2013-07-08 14:51 ` Thomas Petazzoni
1 sibling, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-05 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Dear Bjorn Helgaas,
On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
> > ---
> > drivers/pci/msi.c | 22 ++++++++++++++++++++++
> > drivers/pci/probe.c | 1 +
> > include/linux/msi.h | 11 +++++++++++
> > include/linux/pci.h | 1 +
> > 4 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 289fbfd..62eb3d5 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
> >
> > int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> > {
> > + struct msi_chip *chip = dev->bus->msi;
> > +
> > + if (chip && chip->setup_irq) {
> > + int err;
> > +
> > + err = chip->setup_irq(chip, dev, desc);
> > + if (err < 0)
> > + return err;
> > +
> > + irq_set_chip_data(desc->irq, chip);
> > + return err;
> > + }
> > +
> > return -EINVAL;
>
> It's sub-optimal to indent the whole body of a function like this. I
> think this is a bit more readable:
>
> if (!chip || !chip->setup_irq)
> return -EINVAL
>
> err = chip->setup_irq(...);
> ...
> return err;
Right.
> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> is a bit unclear. Apparently it can return negative values (errors)
> or positive values (not sure what they mean), or zero (again, not
> sure). A comment would clear this up.
Ok, I'll have to look into this. Maybe Thierry Redding can comment on
this.
> It might even be worth introducing a no-op chip with pointers to no-op
> functions so we don't have to do these checks ("if (chip &&
> chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on
> that -- certainly there are many examples of code that *does* make
> these checks everywhere -- so I'll ack it either way.
Ok, I'll see if it makes the overall thing cleaner.
> > int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > {
> > + struct msi_chip *chip = dev->bus->msi;
> > +
> > + if (chip && chip->check_device)
> > + return chip->check_device(chip, dev, nvec, type);
> > +
>
> These functions are poorly named. They give no clue what
> "check_device" means. Are we checking that it exists, that it
> supports some property, that it's enabled, ... ?
Maybe Thierry Redding can comment on this one?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-05 21:51 ` Bjorn Helgaas
2013-07-05 22:08 ` Thomas Petazzoni
@ 2013-07-08 14:51 ` Thomas Petazzoni
2013-07-09 5:05 ` Thierry Reding
2013-07-09 16:34 ` Bjorn Helgaas
1 sibling, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-08 14:51 UTC (permalink / raw)
To: linux-arm-kernel
Dear Bjorn Helgaas,
On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
> > int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> > {
> > + struct msi_chip *chip = dev->bus->msi;
> > +
> > + if (chip && chip->setup_irq) {
> > + int err;
> > +
> > + err = chip->setup_irq(chip, dev, desc);
> > + if (err < 0)
> > + return err;
> > +
> > + irq_set_chip_data(desc->irq, chip);
> > + return err;
> > + }
> > +
> > return -EINVAL;
>
> It's sub-optimal to indent the whole body of a function like this. I
> think this is a bit more readable:
>
> if (!chip || !chip->setup_irq)
> return -EINVAL
>
> err = chip->setup_irq(...);
> ...
> return err;
>
> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> is a bit unclear. Apparently it can return negative values (errors)
> or positive values (not sure what they mean), or zero (again, not
> sure). A comment would clear this up.
I've changed ->setup_irq() to simply return 0 on success, and a
negative error code on failure.
Apparently, according to the default implementation
of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
return:
* A negative value on error, the value being an error code that is
propagated to the caller.
* A positive value on some other errors, in which case the -ENOSPC
error value is returned. To me, it doesn't make a lot of sense, as
arch_msi_setup_irq() could just as well return -ENOSPC directly.
* A 0 value on success.
> It might even be worth introducing a no-op chip with pointers to no-op
> functions so we don't have to do these checks ("if (chip &&
> chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on
> that -- certainly there are many examples of code that *does* make
> these checks everywhere -- so I'll ack it either way.
The problem with this is that I'm not sure where in the PCI code this
association to the default implementation should be done. And there are
also two levels to take into account here:
* The PCI driver may not specify any msi_chip structure for a
particular pci_bus. This would have to be detected by the PCI core
when the bus is registered, and bus->msi would be set to the special
no-op msi_chip.
* The PCI driver may specify an msi_chip structure, but without
necessarily implementation all the methods. This could be solved by
offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
function to be used by PCI drivers to assign their msi_chip to a
given pci_bus, and this function would fill in the missing msi_chip
operations with the default implementation.
I am not sure it is really worth doing at this point, but I'm open to
suggestions on this.
> > int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > {
> > + struct msi_chip *chip = dev->bus->msi;
> > +
> > + if (chip && chip->check_device)
> > + return chip->check_device(chip, dev, nvec, type);
> > +
>
> These functions are poorly named. They give no clue what
> "check_device" means. Are we checking that it exists, that it
> supports some property, that it's enabled, ... ?
Well the naming clearly doesn't come from this commit. The
arch_msi_check_device() hook was around before this commit, and the
reason the operation is named ->check_device() is just because it used
the same terminology as the existing arch_msi_check_device() call.
This hook is only used in one place, the PowerPC architecture, in
arch/powerpc/kernel/msi.c, to actually check whether the given device
supports MSI.
I can rename if to arch_msi_device_supports_msi() and
->device_supports_msi(), or arch_msi_device_has_msi() and
->device_has_msi(), but that a change that relatively unrelated to this
commit, I'd say.
Here as well, I'm open to suggestions,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-08 14:51 ` Thomas Petazzoni
@ 2013-07-09 5:05 ` Thierry Reding
2013-07-09 16:34 ` Bjorn Helgaas
1 sibling, 0 replies; 38+ messages in thread
From: Thierry Reding @ 2013-07-09 5:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 08, 2013 at 04:51:49PM +0200, Thomas Petazzoni wrote:
> Dear Bjorn Helgaas,
Sorry for chiming in so late, I've had bad internet connectivity and
email access for a few days.
> On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
>
> > > int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> > > {
> > > + struct msi_chip *chip = dev->bus->msi;
> > > +
> > > + if (chip && chip->setup_irq) {
> > > + int err;
> > > +
> > > + err = chip->setup_irq(chip, dev, desc);
> > > + if (err < 0)
> > > + return err;
> > > +
> > > + irq_set_chip_data(desc->irq, chip);
> > > + return err;
> > > + }
> > > +
> > > return -EINVAL;
> >
> > It's sub-optimal to indent the whole body of a function like this. I
> > think this is a bit more readable:
> >
> > if (!chip || !chip->setup_irq)
> > return -EINVAL
> >
> > err = chip->setup_irq(...);
> > ...
> > return err;
> >
> > The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> > is a bit unclear. Apparently it can return negative values (errors)
> > or positive values (not sure what they mean), or zero (again, not
> > sure). A comment would clear this up.
>
> I've changed ->setup_irq() to simply return 0 on success, and a
> negative error code on failure.
>
> Apparently, according to the default implementation
> of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
> return:
> * A negative value on error, the value being an error code that is
> propagated to the caller.
> * A positive value on some other errors, in which case the -ENOSPC
> error value is returned. To me, it doesn't make a lot of sense, as
> arch_msi_setup_irq() could just as well return -ENOSPC directly.
> * A 0 value on success.
Yes, I think that'd be much more straightforward. Having > 0 as a
special case isn't useful here.
> > It might even be worth introducing a no-op chip with pointers to no-op
> > functions so we don't have to do these checks ("if (chip &&
> > chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on
> > that -- certainly there are many examples of code that *does* make
> > these checks everywhere -- so I'll ack it either way.
>
> The problem with this is that I'm not sure where in the PCI code this
> association to the default implementation should be done. And there are
> also two levels to take into account here:
>
> * The PCI driver may not specify any msi_chip structure for a
> particular pci_bus. This would have to be detected by the PCI core
> when the bus is registered, and bus->msi would be set to the special
> no-op msi_chip.
You could check if bus->msi was set after the call to pcibios_bus_add()
but that's a bit wonky because it may break once the first architecture
appears that assigns it in a different place.
> * The PCI driver may specify an msi_chip structure, but without
> necessarily implementation all the methods. This could be solved by
> offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
> function to be used by PCI drivers to assign their msi_chip to a
> given pci_bus, and this function would fill in the missing msi_chip
> operations with the default implementation.
>
> I am not sure it is really worth doing at this point, but I'm open to
> suggestions on this.
I think these extra calls aren't that bad given how other alternatives
are much easier to break things. Perhaps checking for the methods could
be dropped, therefore making them mandatory (by crashing if they're not
implemented).
> > > int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > > {
> > > + struct msi_chip *chip = dev->bus->msi;
> > > +
> > > + if (chip && chip->check_device)
> > > + return chip->check_device(chip, dev, nvec, type);
> > > +
> >
> > These functions are poorly named. They give no clue what
> > "check_device" means. Are we checking that it exists, that it
> > supports some property, that it's enabled, ... ?
>
> Well the naming clearly doesn't come from this commit. The
> arch_msi_check_device() hook was around before this commit, and the
> reason the operation is named ->check_device() is just because it used
> the same terminology as the existing arch_msi_check_device() call.
>
> This hook is only used in one place, the PowerPC architecture, in
> arch/powerpc/kernel/msi.c, to actually check whether the given device
> supports MSI.
>
> I can rename if to arch_msi_device_supports_msi() and
> ->device_supports_msi(), or arch_msi_device_has_msi() and
> ->device_has_msi(), but that a change that relatively unrelated to this
> commit, I'd say.
>
> Here as well, I'm open to suggestions,
I don't think *_check_device() is all that bad. Some of the
implementations in PowerPC only use it to output a debug message, others
do some more checking. Some of the checks look generic enough to move
them into the core.
If you rename it to *_has_msi() or *_supports_msi() then I'd expect it
to return a boolean and you loose the advantage of being able to return
a more meaningful value. Although I'm not sure how useful that error
code really is. It is passed all the way up to the caller of
pci_enable_msi(), so a driver could use it to construct a better error
message based on the error code. From a quick glance a few of them seem
to do that.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130709/d850b288/attachment.sig>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
2013-07-08 14:51 ` Thomas Petazzoni
2013-07-09 5:05 ` Thierry Reding
@ 2013-07-09 16:34 ` Bjorn Helgaas
1 sibling, 0 replies; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-09 16:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 8, 2013 at 8:51 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
>
>> > int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>> > {
>> > + struct msi_chip *chip = dev->bus->msi;
>> > +
>> > + if (chip && chip->setup_irq) {
>> > + int err;
>> > +
>> > + err = chip->setup_irq(chip, dev, desc);
>> > + if (err < 0)
>> > + return err;
>> > +
>> > + irq_set_chip_data(desc->irq, chip);
>> > + return err;
>> > + }
>> > +
>> > return -EINVAL;
>>
>> It's sub-optimal to indent the whole body of a function like this. I
>> think this is a bit more readable:
>>
>> if (!chip || !chip->setup_irq)
>> return -EINVAL
>>
>> err = chip->setup_irq(...);
>> ...
>> return err;
>>
>> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
>> is a bit unclear. Apparently it can return negative values (errors)
>> or positive values (not sure what they mean), or zero (again, not
>> sure). A comment would clear this up.
>
> I've changed ->setup_irq() to simply return 0 on success, and a
> negative error code on failure.
Perfect.
> Apparently, according to the default implementation
> of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
> return:
> * A negative value on error, the value being an error code that is
> propagated to the caller.
> * A positive value on some other errors, in which case the -ENOSPC
> error value is returned. To me, it doesn't make a lot of sense, as
> arch_msi_setup_irq() could just as well return -ENOSPC directly.
> * A 0 value on success.
>
>> It might even be worth introducing a no-op chip with pointers to no-op
>> functions so we don't have to do these checks ("if (chip &&
>> chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on
>> that -- certainly there are many examples of code that *does* make
>> these checks everywhere -- so I'll ack it either way.
>
> The problem with this is that I'm not sure where in the PCI code this
> association to the default implementation should be done. And there are
> also two levels to take into account here:
>
> * The PCI driver may not specify any msi_chip structure for a
> particular pci_bus. This would have to be detected by the PCI core
> when the bus is registered, and bus->msi would be set to the special
> no-op msi_chip.
>
> * The PCI driver may specify an msi_chip structure, but without
> necessarily implementation all the methods. This could be solved by
> offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
> function to be used by PCI drivers to assign their msi_chip to a
> given pci_bus, and this function would fill in the missing msi_chip
> operations with the default implementation.
>
> I am not sure it is really worth doing at this point, but I'm open to
> suggestions on this.
Sounds like it's not worth doing. Thanks for checking into it.
>> > int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
>> > {
>> > + struct msi_chip *chip = dev->bus->msi;
>> > +
>> > + if (chip && chip->check_device)
>> > + return chip->check_device(chip, dev, nvec, type);
>> > +
>>
>> These functions are poorly named. They give no clue what
>> "check_device" means. Are we checking that it exists, that it
>> supports some property, that it's enabled, ... ?
>
> Well the naming clearly doesn't come from this commit. The
> arch_msi_check_device() hook was around before this commit, and the
> reason the operation is named ->check_device() is just because it used
> the same terminology as the existing arch_msi_check_device() call.
>
> This hook is only used in one place, the PowerPC architecture, in
> arch/powerpc/kernel/msi.c, to actually check whether the given device
> supports MSI.
>
> I can rename if to arch_msi_device_supports_msi() and
> ->device_supports_msi(), or arch_msi_device_has_msi() and
> ->device_has_msi(), but that a change that relatively unrelated to this
> commit, I'd say.
>
> Here as well, I'm open to suggestions,
You're right, you didn't make that mess, so I guess it's OK if you
don't clean it up here. I spent a fair amount of time yesterday
analyzing the return values, and lost interest before all became
clear. So I stand by my assertion that it is hard to read, but I'm OK
with leaving it as-is for now.
Bjorn
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (3 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-05 21:56 ` Bjorn Helgaas
` (2 more replies)
2013-07-01 13:42 ` [PATCHv4 06/11] irqchip: armada-370-xp: properly request resources Thomas Petazzoni
` (5 subsequent siblings)
10 siblings, 3 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds a very basic registry of msi_chip structures, so that
an IRQ controller driver can register an msi_chip, and a PCIe host
controller can find it, based on a 'struct device_node'.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/msi.h | 2 ++
include/linux/of_pci.h | 12 ++++++++++++
3 files changed, 54 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 42c687a..f516632 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
return 0;
}
EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
+
+#ifdef CONFIG_PCI_MSI
+
+static LIST_HEAD(msi_chip_list);
+static DEFINE_MUTEX(msi_chip_mutex);
+
+int of_msi_chip_add(struct msi_chip *chip)
+{
+ if (! of_property_read_bool(chip->of_node, "msi-controller"))
+ return -EINVAL;
+
+ mutex_lock(&msi_chip_mutex);
+ list_add(&chip->list, &msi_chip_list);
+ mutex_unlock(&msi_chip_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_msi_chip_add);
+
+void of_msi_chip_remove(struct msi_chip *chip)
+{
+ mutex_lock(&msi_chip_mutex);
+ list_del(&chip->list);
+ mutex_unlock(&msi_chip_mutex);
+}
+EXPORT_SYMBOL_GPL(of_msi_chip_remove);
+
+struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
+{
+ struct msi_chip *c;
+ list_for_each_entry(c, &msi_chip_list, list) {
+ if (c->of_node == of_node)
+ return c;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
+
+#endif /* CONFIG_PCI_MSI */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 5b357d92..9e1a44b 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
struct msi_chip {
struct module *owner;
struct device *dev;
+ struct device_node *of_node;
+ struct list_head list;
int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
struct msi_desc *desc);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 7a04826..99e4361 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -2,6 +2,7 @@
#define __OF_PCI_H
#include <linux/pci.h>
+#include <linux/msi.h>
struct pci_dev;
struct of_irq;
@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
int of_pci_get_devfn(struct device_node *np);
int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
+#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
+int of_msi_chip_add(struct msi_chip *chip);
+void of_msi_chip_remove(struct msi_chip *chip);
+struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
+#else
+static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
+static inline void of_msi_chip_remove(struct msi_chip *chip) { }
+static inline struct msi_chip *
+of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
+#endif
+
#endif
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-01 13:42 ` [PATCHv4 05/11] of: pci: add registry of MSI chips Thomas Petazzoni
@ 2013-07-05 21:56 ` Bjorn Helgaas
2013-07-05 22:06 ` Thomas Petazzoni
2013-07-08 11:23 ` Thomas Petazzoni
2013-07-09 13:43 ` Rob Herring
2 siblings, 1 reply; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++
> include/linux/msi.h | 2 ++
> include/linux/of_pci.h | 12 ++++++++++++
> 3 files changed, 54 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)
> +{
> + if (! of_property_read_bool(chip->of_node, "msi-controller"))
The space between "! of_property..." is atypical.
> + return -EINVAL;
> +
> + mutex_lock(&msi_chip_mutex);
> + list_add(&chip->list, &msi_chip_list);
> + mutex_unlock(&msi_chip_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)
> +{
> + mutex_lock(&msi_chip_mutex);
> + list_del(&chip->list);
> + mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> +{
> + struct msi_chip *c;
Normally there's a blank line here.
The list traversal below isn't safe, is it? A simultaneous remove,
e.g., of an MSI chip unrelated to the one we're looking up, might
change the list while we're traversing it.
> + list_for_each_entry(c, &msi_chip_list, list) {
> + if (c->of_node == of_node)
> + return c;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
> struct msi_chip {
> struct module *owner;
> struct device *dev;
> + struct device_node *of_node;
> + struct list_head list;
>
> int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
> #define __OF_PCI_H
>
> #include <linux/pci.h>
> +#include <linux/msi.h>
>
> struct pci_dev;
> struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> int of_pci_get_devfn(struct device_node *np);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
> #endif
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-05 21:56 ` Bjorn Helgaas
@ 2013-07-05 22:06 ` Thomas Petazzoni
0 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-05 22:06 UTC (permalink / raw)
To: linux-arm-kernel
Dear Bjorn Helgaas,
On Fri, 5 Jul 2013 15:56:55 -0600, Bjorn Helgaas wrote:
> > +int of_msi_chip_add(struct msi_chip *chip)
> > +{
> > + if (! of_property_read_bool(chip->of_node, "msi-controller"))
>
> The space between "! of_property..." is atypical.
Indeed.
> > +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> > +{
> > + struct msi_chip *c;
>
> Normally there's a blank line here.
>
> The list traversal below isn't safe, is it? A simultaneous remove,
> e.g., of an MSI chip unrelated to the one we're looking up, might
> change the list while we're traversing it.
True, will fix!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-01 13:42 ` [PATCHv4 05/11] of: pci: add registry of MSI chips Thomas Petazzoni
2013-07-05 21:56 ` Bjorn Helgaas
@ 2013-07-08 11:23 ` Thomas Petazzoni
2013-07-09 13:43 ` Rob Herring
2 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-08 11:23 UTC (permalink / raw)
To: linux-arm-kernel
Grant, Rob,
Would it be possible to get your feeling about the below patch? Are you
ok with the idea of this msi_chip registry, based on device_node
pointer? This is the last piece of this patch set that needs an
approval in terms of general approach.
I am at Linaro Connect this week, so if you want to discuss this live,
do not hesitate to ping me.
Thanks a lot,
Thomas
On Mon, 1 Jul 2013 15:42:10 +0200, Thomas Petazzoni wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++
> include/linux/msi.h | 2 ++
> include/linux/of_pci.h | 12 ++++++++++++
> 3 files changed, 54 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)
> +{
> + if (! of_property_read_bool(chip->of_node, "msi-controller"))
> + return -EINVAL;
> +
> + mutex_lock(&msi_chip_mutex);
> + list_add(&chip->list, &msi_chip_list);
> + mutex_unlock(&msi_chip_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)
> +{
> + mutex_lock(&msi_chip_mutex);
> + list_del(&chip->list);
> + mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> +{
> + struct msi_chip *c;
> + list_for_each_entry(c, &msi_chip_list, list) {
> + if (c->of_node == of_node)
> + return c;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
> struct msi_chip {
> struct module *owner;
> struct device *dev;
> + struct device_node *of_node;
> + struct list_head list;
>
> int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
> #define __OF_PCI_H
>
> #include <linux/pci.h>
> +#include <linux/msi.h>
>
> struct pci_dev;
> struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> int of_pci_get_devfn(struct device_node *np);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
> #endif
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-01 13:42 ` [PATCHv4 05/11] of: pci: add registry of MSI chips Thomas Petazzoni
2013-07-05 21:56 ` Bjorn Helgaas
2013-07-08 11:23 ` Thomas Petazzoni
@ 2013-07-09 13:43 ` Rob Herring
2013-07-09 14:01 ` Thomas Petazzoni
2 siblings, 1 reply; 38+ messages in thread
From: Rob Herring @ 2013-07-09 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 8:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++
> include/linux/msi.h | 2 ++
> include/linux/of_pci.h | 12 ++++++++++++
> 3 files changed, 54 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)
Perhaps of_pci_msi_chip_add instead.
> +{
> + if (! of_property_read_bool(chip->of_node, "msi-controller"))
> + return -EINVAL;
> +
> + mutex_lock(&msi_chip_mutex);
> + list_add(&chip->list, &msi_chip_list);
> + mutex_unlock(&msi_chip_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)
ditto
> +{
> + mutex_lock(&msi_chip_mutex);
> + list_del(&chip->list);
> + mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
ditto.
> +{
> + struct msi_chip *c;
> + list_for_each_entry(c, &msi_chip_list, list) {
Need the safe variant here?
Rob
> + if (c->of_node == of_node)
> + return c;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
> struct msi_chip {
> struct module *owner;
> struct device *dev;
> + struct device_node *of_node;
> + struct list_head list;
>
> int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
> #define __OF_PCI_H
>
> #include <linux/pci.h>
> +#include <linux/msi.h>
>
> struct pci_dev;
> struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> int of_pci_get_devfn(struct device_node *np);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
> #endif
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-09 13:43 ` Rob Herring
@ 2013-07-09 14:01 ` Thomas Petazzoni
2013-07-09 16:30 ` Bjorn Helgaas
2013-07-09 22:52 ` Rob Herring
0 siblings, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-09 14:01 UTC (permalink / raw)
To: linux-arm-kernel
Rob,
On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:
> > +int of_msi_chip_add(struct msi_chip *chip)
>
> Perhaps of_pci_msi_chip_add instead.
Sure, makes sense.
> > +{
> > + struct msi_chip *c;
> > + list_for_each_entry(c, &msi_chip_list, list) {
>
> Need the safe variant here?
As suggested by Bjorn, I've changed this function to grab the
msi_chip_mutex while traversing the list.
Does your e-mail implies that the general approach seems ok? If so,
I'll resend an updated v5 version taking into account the comments
that I have received on this v4.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-09 14:01 ` Thomas Petazzoni
@ 2013-07-09 16:30 ` Bjorn Helgaas
2013-07-09 22:52 ` Rob Herring
1 sibling, 0 replies; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-09 16:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 9, 2013 at 8:01 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:
>> > +{
>> > + struct msi_chip *c;
>> > + list_for_each_entry(c, &msi_chip_list, list) {
>>
>> Need the safe variant here?
>
> As suggested by Bjorn, I've changed this function to grab the
> msi_chip_mutex while traversing the list.
The "safe" list functions don't do any mutual exclusion. The only
safety they provide is that we won't go in the weeds if the body of
the loop deletes the current list entry. This loop doesn't delete
entries, so we don't need the safe variant.
Bjorn
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCHv4 05/11] of: pci: add registry of MSI chips
2013-07-09 14:01 ` Thomas Petazzoni
2013-07-09 16:30 ` Bjorn Helgaas
@ 2013-07-09 22:52 ` Rob Herring
1 sibling, 0 replies; 38+ messages in thread
From: Rob Herring @ 2013-07-09 22:52 UTC (permalink / raw)
To: linux-arm-kernel
On 07/09/2013 09:01 AM, Thomas Petazzoni wrote:
> Rob,
>
> On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:
>
>>> +int of_msi_chip_add(struct msi_chip *chip)
>>
>> Perhaps of_pci_msi_chip_add instead.
>
> Sure, makes sense.
>
>>> +{
>>> + struct msi_chip *c;
>>> + list_for_each_entry(c, &msi_chip_list, list) {
>>
>> Need the safe variant here?
>
> As suggested by Bjorn, I've changed this function to grab the
> msi_chip_mutex while traversing the list.
>
> Does your e-mail implies that the general approach seems ok? If so,
> I'll resend an updated v5 version taking into account the comments
> that I have received on this v4.
Yes. Since it is only trivial comments, you can add my ack.
Acked-by: Rob Herring <rob.herring@calxeda.com>
Rob
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 06/11] irqchip: armada-370-xp: properly request resources
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (4 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 05/11] of: pci: add registry of MSI chips Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 07/11] irqchip: armada-370-xp: implement MSI support Thomas Petazzoni
` (4 subsequent siblings)
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Instead of using of_iomap(), we now use of_address_to_resource(),
request_mem_region() and ioremap(). This allows the corresponding I/O
regions to be properly requested and visible in /proc/iomem.
The main motivation for this change is that the introduction of the
MSI support requires us to get the physical address of the main
interrupt controller registers, so we will need the corresponding
'struct resource' anyway.
We also take this opportunity to change a panic() to BUG_ON(), in
order to be consistent with the rest of the driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/irqchip/irq-armada-370-xp.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index bb328a3..26adc74 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -248,12 +248,25 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
static int __init armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent)
{
+ struct resource main_int_res, per_cpu_int_res;
u32 control;
- main_int_base = of_iomap(node, 0);
- per_cpu_int_base = of_iomap(node, 1);
+ BUG_ON(of_address_to_resource(node, 0, &main_int_res));
+ BUG_ON(of_address_to_resource(node, 1, &per_cpu_int_res));
+ BUG_ON(!request_mem_region(main_int_res.start,
+ resource_size(&main_int_res),
+ node->full_name));
+ BUG_ON(!request_mem_region(per_cpu_int_res.start,
+ resource_size(&per_cpu_int_res),
+ node->full_name));
+
+ main_int_base = ioremap(main_int_res.start,
+ resource_size(&main_int_res));
BUG_ON(!main_int_base);
+
+ per_cpu_int_base = ioremap(per_cpu_int_res.start,
+ resource_size(&per_cpu_int_res));
BUG_ON(!per_cpu_int_base);
control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
@@ -262,8 +275,7 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
irq_domain_add_linear(node, (control >> 2) & 0x3ff,
&armada_370_xp_mpic_irq_ops, NULL);
- if (!armada_370_xp_mpic_domain)
- panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
+ BUG_ON(!armada_370_xp_mpic_domain);
irq_set_default_host(armada_370_xp_mpic_domain);
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 07/11] irqchip: armada-370-xp: implement MSI support
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (5 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 06/11] irqchip: armada-370-xp: properly request resources Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 08/11] arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci Thomas Petazzoni
` (3 subsequent siblings)
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an MSI chip to
the MSI chip registry, which will be used by the Marvell PCIe host
controller driver.
The MSI interrupts use the 16 high doorbells, and are therefore
notified using IRQ1 of the main interrupt controller.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../devicetree/bindings/arm/armada-370-xp-mpic.txt | 3 +
drivers/irqchip/irq-armada-370-xp.c | 141 ++++++++++++++++++++-
2 files changed, 143 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 61df564..d74091a 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
Required properties:
- compatible: Should be "marvell,mpic"
- interrupt-controller: Identifies the node as an interrupt controller.
+- msi-controller: Identifies the node as an PCI Message Signaled
+ Interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
@@ -24,6 +26,7 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
+ msi-controller;
reg = <0xd0020a00 0x1d0>,
<0xd0021070 0x58>;
};
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 26adc74..04efe64 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -21,7 +21,10 @@
#include <linux/io.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/of_pci.h>
#include <linux/irqdomain.h>
+#include <linux/slab.h>
+#include <linux/msi.h>
#include <asm/mach/arch.h>
#include <asm/exception.h>
#include <asm/smp_plat.h>
@@ -51,12 +54,20 @@
#define IPI_DOORBELL_START (0)
#define IPI_DOORBELL_END (8)
#define IPI_DOORBELL_MASK 0xFF
+#define PCI_MSI_DOORBELL_START (16)
+#define PCI_MSI_DOORBELL_NR (16)
+#define PCI_MSI_DOORBELL_END (32)
+#define PCI_MSI_DOORBELL_MASK 0xFFFF0000
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
+#ifdef CONFIG_PCI_MSI
+static struct irq_domain *armada_370_xp_msi_domain;
+static phys_addr_t msi_doorbell_addr;
+#endif
/*
* In SMP mode:
@@ -87,6 +98,102 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
}
+#ifdef CONFIG_PCI_MSI
+
+static int armada_370_xp_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *pdev,
+ struct msi_desc *desc)
+{
+ struct msi_msg msg;
+ irq_hw_number_t hwirq;
+ int virq;
+
+ virq = irq_alloc_mapping(armada_370_xp_msi_domain, &hwirq);
+ if (!virq)
+ return -EINVAL;
+
+ irq_set_msi_desc(virq, desc);
+
+ msg.address_lo = msi_doorbell_addr;
+ msg.address_hi = 0;
+ msg.data = 0xf00 | (hwirq + 16);
+
+ write_msi_msg(virq, &msg);
+ return 0;
+}
+
+static void armada_370_xp_teardown_msi_irq(struct msi_chip *chip,
+ unsigned int irq)
+{
+ irq_dispose_mapping(irq);
+}
+
+static struct irq_chip armada_370_xp_msi_irq_chip = {
+ .name = "armada_370_xp_msi_irq",
+ .irq_enable = unmask_msi_irq,
+ .irq_disable = mask_msi_irq,
+ .irq_mask = mask_msi_irq,
+ .irq_unmask = unmask_msi_irq,
+};
+
+static int armada_370_xp_msi_map(struct irq_domain *domain, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ irq_set_chip_and_handler(virq, &armada_370_xp_msi_irq_chip,
+ handle_simple_irq);
+ set_irq_flags(virq, IRQF_VALID);
+
+ return 0;
+}
+
+static const struct irq_domain_ops armada_370_xp_msi_irq_ops = {
+ .map = armada_370_xp_msi_map,
+};
+
+static int armada_370_xp_msi_init(struct device_node *node)
+{
+ struct msi_chip *msi_chip;
+ int ret;
+ u32 reg;
+
+ msi_chip = kzalloc(sizeof(*msi_chip), GFP_KERNEL);
+ if (!msi_chip)
+ return -ENOMEM;
+
+ armada_370_xp_msi_domain =
+ irq_domain_add_linear(NULL, PCI_MSI_DOORBELL_NR,
+ &armada_370_xp_msi_irq_ops, NULL);
+ if (!armada_370_xp_msi_domain) {
+ kfree(msi_chip);
+ return -ENOMEM;
+ }
+
+ msi_chip->of_node = node;
+ msi_chip->setup_irq = armada_370_xp_setup_msi_irq;
+ msi_chip->teardown_irq = armada_370_xp_teardown_msi_irq;
+
+ ret = of_msi_chip_add(msi_chip);
+ if (ret < 0) {
+ irq_domain_remove(armada_370_xp_msi_domain);
+ kfree(msi_chip);
+ return ret;
+ }
+
+ reg = readl(per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS)
+ | PCI_MSI_DOORBELL_MASK;
+
+ writel(reg, per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+ /* Unmask IPI interrupt */
+ writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+
+ return 0;
+}
+#else
+static inline int armada_370_xp_msi_init(struct device_node *node) { return 0; }
+#endif
+
#ifdef CONFIG_SMP
static int armada_xp_set_affinity(struct irq_data *d,
const struct cpumask *mask_val, bool force)
@@ -214,12 +321,39 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
if (irqnr > 1022)
break;
- if (irqnr > 0) {
+ if (irqnr > 1) {
irqnr = irq_find_mapping(armada_370_xp_mpic_domain,
irqnr);
handle_IRQ(irqnr, regs);
continue;
}
+
+#ifdef CONFIG_PCI_MSI
+ /* MSI handling */
+ if (irqnr == 1) {
+ u32 msimask, msinr;
+
+ msimask = readl_relaxed(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+ & PCI_MSI_DOORBELL_MASK;
+
+ writel(~PCI_MSI_DOORBELL_MASK, per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+ for (msinr = PCI_MSI_DOORBELL_START;
+ msinr < PCI_MSI_DOORBELL_END; msinr++) {
+ int irq;
+
+ if (!(msimask & BIT(msinr)))
+ continue;
+
+ irq = irq_find_mapping(armada_370_xp_msi_domain,
+ msinr - 16);
+ handle_IRQ(irq, regs);
+ }
+ }
+#endif
+
#ifdef CONFIG_SMP
/* IPI Handling */
if (irqnr == 0) {
@@ -269,6 +403,9 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
resource_size(&per_cpu_int_res));
BUG_ON(!per_cpu_int_base);
+ msi_doorbell_addr = main_int_res.start +
+ ARMADA_370_XP_SW_TRIG_INT_OFFS;
+
control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
armada_370_xp_mpic_domain =
@@ -292,6 +429,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
#endif
+ armada_370_xp_msi_init(node);
+
set_handle_irq(armada_370_xp_handle_irq);
return 0;
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 08/11] arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (6 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 07/11] irqchip: armada-370-xp: implement MSI support Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 09/11] arm: mvebu: the MPIC now provides MSI controller features Thomas Petazzoni
` (2 subsequent siblings)
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Some PCI drivers may need to adjust the pci_bus structure after it has
been allocated by the Linux PCI core. The PCI core allows
architectures to implement the pcibios_add_bus() and
pcibios_remove_bus() for this purpose. This commit therefore extends
the hw_pci and pci_sys_data structures of the ARM PCI core to allow
PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
which will get called when a bus is added or removed from the system.
This will be used for example by the Marvell PCIe driver to connect a
particular PCI bus with its corresponding MSI chip to handle Message
Signaled Interrupts.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
---
arch/arm/include/asm/mach/pci.h | 4 ++++
arch/arm/kernel/bios32.c | 16 ++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 7d2c3c8..b71cc9d 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -35,6 +35,8 @@ struct hw_pci {
resource_size_t start,
resource_size_t size,
resource_size_t align);
+ void (*add_bus)(struct pci_bus *bus);
+ void (*remove_bus)(struct pci_bus *bus);
};
/*
@@ -62,6 +64,8 @@ struct pci_sys_data {
resource_size_t start,
resource_size_t size,
resource_size_t align);
+ void (*add_bus)(struct pci_bus *bus);
+ void (*remove_bus)(struct pci_bus *bus);
void *private_data; /* platform controller private data */
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index b2ed73c..0a441f8 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus)
}
EXPORT_SYMBOL(pcibios_fixup_bus);
+void pcibios_add_bus(struct pci_bus *bus)
+{
+ struct pci_sys_data *sys = bus->sysdata;
+ if (sys->add_bus)
+ sys->add_bus(bus);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+ struct pci_sys_data *sys = bus->sysdata;
+ if (sys->remove_bus)
+ sys->remove_bus(bus);
+}
+
/*
* Swizzle the device pin each time we cross a bridge. If a platform does
* not provide a swizzle function, we perform the standard PCI swizzling.
@@ -463,6 +477,8 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
sys->align_resource = hw->align_resource;
+ sys->add_bus = hw->add_bus;
+ sys->remove_bus = hw->remove_bus;
INIT_LIST_HEAD(&sys->resources);
if (hw->private_data)
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 09/11] arm: mvebu: the MPIC now provides MSI controller features
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (7 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 08/11] arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 10/11] pci: mvebu: add support for MSI Thomas Petazzoni
2013-07-01 13:42 ` [PATCHv4 11/11] arm: mvebu: link PCIe controllers to the MSI controller Thomas Petazzoni
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Adds the 'msi-controller' property to the main interrupt controller
Device Tree node, to indicate that it can now behave as a MSI
controller.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index bb6224c..9020478 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -52,6 +52,7 @@
#interrupt-cells = <1>;
#size-cells = <1>;
interrupt-controller;
+ msi-controller;
};
coherency-fabric at 20200 {
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 10/11] pci: mvebu: add support for MSI
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (8 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 09/11] arm: mvebu: the MPIC now provides MSI controller features Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
2013-07-05 21:59 ` Bjorn Helgaas
2013-07-01 13:42 ` [PATCHv4 11/11] arm: mvebu: link PCIe controllers to the MSI controller Thomas Petazzoni
10 siblings, 1 reply; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds support for Message Signaled Interrupts in the
Marvell PCIe host controller. The work is very simple: it simply gets
a reference to the msi_chip associated to the PCIe controller thanks
to the msi-parent DT property, and stores this reference in the
pci_bus structure. This is enough to let the Linux PCI core use the
functions of msi_chip to setup and teardown MSIs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
.../devicetree/bindings/pci/mvebu-pci.txt | 3 +++
drivers/pci/host/pci-mvebu.c | 26 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..77e0ffe 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -12,6 +12,8 @@ Mandatory properties:
- device_type, set to "pci"
- ranges: ranges for the PCI memory and I/O regions, as well as the
MMIO registers to control the PCIe interfaces.
+- msi-parent: Link to the hardware entity that serves as the Message
+ Signaled Interrupt controller for this PCI controller.
In addition, the Device Tree node must have sub-nodes describing each
PCIe interface, having the following mandatory properties:
@@ -46,6 +48,7 @@ pcie-controller {
#size-cells = <2>;
bus-range = <0x00 0xff>;
+ msi-parent = <&mpic>;
ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */
0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..396f578 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -11,6 +11,7 @@
#include <linux/clk.h>
#include <linux/module.h>
#include <linux/mbus.h>
+#include <linux/msi.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/of_address.h>
@@ -107,6 +108,7 @@ struct mvebu_pcie_port;
struct mvebu_pcie {
struct platform_device *pdev;
struct mvebu_pcie_port *ports;
+ struct msi_chip *msi;
struct resource io;
struct resource realio;
struct resource mem;
@@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
return bus;
}
+void mvebu_pcie_add_bus(struct pci_bus *bus)
+{
+ struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
+ bus->msi = pcie->msi;
+}
+
resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
const struct resource *res,
resource_size_t start,
@@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
hw.map_irq = mvebu_pcie_map_irq;
hw.ops = &mvebu_pcie_ops;
hw.align_resource = mvebu_pcie_align_resource;
+ hw.add_bus = mvebu_pcie_add_bus;
pci_common_init(&hw);
}
@@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
return devm_request_and_ioremap(&pdev->dev, ®s);
}
+static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
+{
+ struct device_node *msi_node;
+
+ msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
+ "msi-parent", 0);
+ if (!msi_node)
+ return;
+
+ pcie->msi = of_find_msi_chip_by_node(msi_node);
+
+ if (pcie->msi)
+ pcie->msi->dev = &pcie->pdev->dev;
+}
+
static int __init mvebu_pcie_probe(struct platform_device *pdev)
{
struct mvebu_pcie *pcie;
@@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
i++;
}
+ mvebu_pcie_msi_enable(pcie);
+
mvebu_pcie_enable(pcie);
return 0;
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCHv4 10/11] pci: mvebu: add support for MSI
2013-07-01 13:42 ` [PATCHv4 10/11] pci: mvebu: add support for MSI Thomas Petazzoni
@ 2013-07-05 21:59 ` Bjorn Helgaas
0 siblings, 0 replies; 38+ messages in thread
From: Bjorn Helgaas @ 2013-07-05 21:59 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds support for Message Signaled Interrupts in the
> Marvell PCIe host controller. The work is very simple: it simply gets
> a reference to the msi_chip associated to the PCIe controller thanks
> to the msi-parent DT property, and stores this reference in the
> pci_bus structure. This is enough to let the Linux PCI core use the
> functions of msi_chip to setup and teardown MSIs.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
I've already acked this, and I reaffirm that. Please adjust the
subject line to capitalize "PCI" and the first word of the descriptive
sentence.
> ---
> .../devicetree/bindings/pci/mvebu-pci.txt | 3 +++
> drivers/pci/host/pci-mvebu.c | 26 ++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index f8d4058..77e0ffe 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -12,6 +12,8 @@ Mandatory properties:
> - device_type, set to "pci"
> - ranges: ranges for the PCI memory and I/O regions, as well as the
> MMIO registers to control the PCIe interfaces.
> +- msi-parent: Link to the hardware entity that serves as the Message
> + Signaled Interrupt controller for this PCI controller.
>
> In addition, the Device Tree node must have sub-nodes describing each
> PCIe interface, having the following mandatory properties:
> @@ -46,6 +48,7 @@ pcie-controller {
> #size-cells = <2>;
>
> bus-range = <0x00 0xff>;
> + msi-parent = <&mpic>;
>
> ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */
> 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13a633b..396f578 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -11,6 +11,7 @@
> #include <linux/clk.h>
> #include <linux/module.h>
> #include <linux/mbus.h>
> +#include <linux/msi.h>
> #include <linux/slab.h>
> #include <linux/platform_device.h>
> #include <linux/of_address.h>
> @@ -107,6 +108,7 @@ struct mvebu_pcie_port;
> struct mvebu_pcie {
> struct platform_device *pdev;
> struct mvebu_pcie_port *ports;
> + struct msi_chip *msi;
> struct resource io;
> struct resource realio;
> struct resource mem;
> @@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> return bus;
> }
>
> +void mvebu_pcie_add_bus(struct pci_bus *bus)
> +{
> + struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> + bus->msi = pcie->msi;
> +}
> +
> resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
> const struct resource *res,
> resource_size_t start,
> @@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
> hw.map_irq = mvebu_pcie_map_irq;
> hw.ops = &mvebu_pcie_ops;
> hw.align_resource = mvebu_pcie_align_resource;
> + hw.add_bus = mvebu_pcie_add_bus;
>
> pci_common_init(&hw);
> }
> @@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
> return devm_request_and_ioremap(&pdev->dev, ®s);
> }
>
> +static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
> +{
> + struct device_node *msi_node;
> +
> + msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
> + "msi-parent", 0);
> + if (!msi_node)
> + return;
> +
> + pcie->msi = of_find_msi_chip_by_node(msi_node);
> +
> + if (pcie->msi)
> + pcie->msi->dev = &pcie->pdev->dev;
> +}
> +
> static int __init mvebu_pcie_probe(struct platform_device *pdev)
> {
> struct mvebu_pcie *pcie;
> @@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> i++;
> }
>
> + mvebu_pcie_msi_enable(pcie);
> +
> mvebu_pcie_enable(pcie);
>
> return 0;
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCHv4 11/11] arm: mvebu: link PCIe controllers to the MSI controller
2013-07-01 13:42 [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
` (9 preceding siblings ...)
2013-07-01 13:42 ` [PATCHv4 10/11] pci: mvebu: add support for MSI Thomas Petazzoni
@ 2013-07-01 13:42 ` Thomas Petazzoni
10 siblings, 0 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: linux-arm-kernel
This commit adjusts the Armada 370 and Armada XP PCIe controllers
Device Tree informations to reference their MSI controller. In the
case of this platform, the MSI controller is implemented by the MPIC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 1 +
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 1 +
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 1 +
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 1 +
4 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..a60018d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -178,6 +178,7 @@
#address-cells = <3>;
#size-cells = <2>;
+ msi-parent = <&mpic>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..4a9a305 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -91,6 +91,7 @@
#address-cells = <3>;
#size-cells = <2>;
+ msi-parent = <&mpic>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f4029f0..bc63783 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -111,6 +111,7 @@
#address-cells = <3>;
#size-cells = <2>;
+ msi-parent = <&mpic>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..77db2bc 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -127,6 +127,7 @@
#address-cells = <3>;
#size-cells = <2>;
+ msi-parent = <&mpic>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
--
1.8.1.2
^ permalink raw reply related [flat|nested] 38+ messages in thread