Message ID | 20161106222128.24433-1-pbrobinson@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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.
">> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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@gmail.com> --- drivers/spi/Kconfig | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)