[PATCH] spi: make architecture specific hardware depend on the associated hardware

[PATCH] spi: make architecture specific hardware depend on the associated hardware

[Peter Robinson]

There's not much point enabling hardware specific hardware drivers if the
actual SoC architecture platforms aren't enabled as they're not much use
with out it.

Signed-off-by: Peter Robinson <pbrobinson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/spi/Kconfig | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b799547..5a25ab8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -188,6 +188,7 @@ config SPI_BUTTERFLY
 
 config SPI_CADENCE
 	tristate "Cadence SPI controller"
+	depends on ARCH_ZYNQ || ARCH_ZYNQMP || COMPILE_TEST
 	help
 	  This selects the Cadence SPI controller master driver
 	  used by Xilinx Zynq and ZynqMP.
@@ -224,7 +225,7 @@ config SPI_DW_PCI
 
 config SPI_DW_MID_DMA
 	bool "DMA support for DW SPI controller on Intel MID platform"
-	depends on SPI_DW_PCI && DW_DMAC_PCI
+	depends on X86 && SPI_DW_PCI && DW_DMAC_PCI
 
 config SPI_DW_MMIO
 	tristate "Memory-mapped io interface driver for DW SPI core"
@@ -499,6 +500,7 @@ config SPI_PXA2XX_PCI
 
 config SPI_ROCKCHIP
 	tristate "Rockchip SPI controller driver"
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	help
 	  This selects a driver for Rockchip SPI controller.
 
@@ -650,7 +652,7 @@ config SPI_TEGRA20_SLINK
 
 config SPI_THUNDERX
 	tristate "Cavium ThunderX SPI controller"
-	depends on PCI && 64BIT && (ARM64 || COMPILE_TEST)
+	depends on PCI && 64BIT && (ARCH_THUNDER || COMPILE_TEST)
 	help
 	  SPI host driver for the hardware found on Cavium ThunderX
 	  SOCs.
@@ -680,7 +682,7 @@ config SPI_XCOMM
 
 config SPI_XILINX
 	tristate "Xilinx SPI controller common module"
-	depends on HAS_IOMEM
+	depends on HAS_IOMEM && (ARCH_ZYNQ || ARCH_ZYNQMP)
 	select SPI_BITBANG
 	help
 	  This exposes the SPI controller IP from the Xilinx EDK.
@@ -715,7 +717,7 @@ config SPI_XTENSA_XTFPGA
 
 config SPI_ZYNQMP_GQSPI
 	tristate "Xilinx ZynqMP GQSPI controller"
-	depends on SPI_MASTER && HAS_DMA
+	depends on SPI_MASTER && HAS_DMA && ARCH_ZYNQMP
 	help
 	  Enables Xilinx GQSPI controller driver for Zynq UltraScale+ MPSoC.
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: make architecture specific hardware depend on the associated hardware

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Sun, Nov 06, 2016 at 10:21:28PM +0000, Peter Robinson wrote:

> There's not much point enabling hardware specific hardware drivers if the
> actual SoC architecture platforms aren't enabled as they're not much use
> with out it.

This really needs cross checking with the various platform maintainers
that the dependencies are correct and it's breaking compile test
coverage for quite a few of the individual drivers.

>  config SPI_DW_MID_DMA
>  	bool "DMA support for DW SPI controller on Intel MID platform"
> -	depends on SPI_DW_PCI && DW_DMAC_PCI
> +	depends on X86 && SPI_DW_PCI && DW_DMAC_PCI

This isn't right - while Intel do use this IP Desginware are a generic
IP vendor and PCI is an architecture neutral bus so there shouldn't be
an x86 dependency.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH] spi: make architecture specific hardware depend on the associated hardware

[Peter Robinson]

">> There's not much point enabling hardware specific hardware drivers if the
>> actual SoC architecture platforms aren't enabled as they're not much use
>> with out it.
>
> This really needs cross checking with the various platform maintainers
> that the dependencies are correct and it's breaking compile test
> coverage for quite a few of the individual drivers.

Was going on the get maintainers script, but on the breakage I'm not
sure how it does breaks stuff as it just adds in the explicit ARCH
config for those SoCs. Are the compile test breakages somewhere public
where I can see them and cross verify with my testing?

>>  config SPI_DW_MID_DMA
>>       bool "DMA support for DW SPI controller on Intel MID platform"
>> -     depends on SPI_DW_PCI && DW_DMAC_PCI
>> +     depends on X86 && SPI_DW_PCI && DW_DMAC_PCI
>
> This isn't right - while Intel do use this IP Desginware are a generic
> IP vendor and PCI is an architecture neutral bus so there shouldn't be
> an x86 dependency.

The SPI_DW_PCI seems to be the generic part. The description for the
DMA bit explicitly says "Intel MID platform" and looking in
spi-dw-mid.c it has comments like "Get pci device for DMA controller,
currently it could only be the DMA controller of Medfield" so while
I'm aware that DesignWare is generic IP a lot of the ARM DW stuff is
mostly generic drivers a lot have a bunch of platform specific
wrapping it the form of platform specific bits (see the SW stmmac
ethernet directory for numerous examples. This does look at least
currently to be specific for that Intel part so at the moment I still
think that makes sense.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: make architecture specific hardware depend on the associated hardware

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Mon, Nov 07, 2016 at 06:12:21PM +0000, Peter Robinson wrote:

> > This really needs cross checking with the various platform maintainers
> > that the dependencies are correct and it's breaking compile test
> > coverage for quite a few of the individual drivers.

> Was going on the get maintainers script, but on the breakage I'm not
> sure how it does breaks stuff as it just adds in the explicit ARCH
> config for those SoCs. Are the compile test breakages somewhere public
> where I can see them and cross verify with my testing?

If you are adding architecture dependencies to things that previously
had none and not also adding an || COMPILE_TEST then it is evident to
inspection that those things will no longer be included in as many build
tests and hence compile test coverage will be broken.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]