[PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option

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 <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <redacted>
Cc: Heiko Carstens <redacted>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <redacted>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <redacted>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <redacted>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <redacted>
---
 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

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
[off-list ref] 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 <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <redacted>
Cc: Heiko Carstens <redacted>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <redacted>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <redacted>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <redacted>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <redacted>

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.

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

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:

quoted

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.

On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper [off-list ref] wrote:

On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:

quoted

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:

quoted

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.

On Sat, Jul 06, 2013 at 09:40:55AM -0600, Bjorn Helgaas wrote:

On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper [off-list ref] wrote:

quoted

On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:

quoted

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:

quoted

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.

Dear Jason Cooper,

On Sat, 6 Jul 2013 12:17:43 -0400, Jason Cooper wrote:

quoted

quoted

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