[PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Geert Uytterhoeven]

commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with
COMPILE_TEST") allows compile-testing drivers on platforms they're not
meant for.

However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies
assumed by the platform dependencies before, like HAS_DMA.

If NO_DMA=y:

drivers/built-in.o: In function `atmel_spi_dma_unmap_xfer':
drivers/spi/spi-atmel.c:915: undefined reference to `dma_unmap_single'
drivers/spi/spi-atmel.c:918: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `atmel_spi_next_xfer_data':
drivers/spi/spi-atmel.c:690: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `atmel_spi_dma_map_xfer':
drivers/spi/spi-atmel.c:890: undefined reference to `dma_map_single'
drivers/spi/spi-atmel.c:893: undefined reference to `dma_mapping_error'
drivers/spi/spi-atmel.c:897: undefined reference to `dma_map_single'
drivers/spi/spi-atmel.c:900: undefined reference to `dma_mapping_error'
drivers/spi/spi-atmel.c:902: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `atmel_spi_probe':
drivers/spi/spi-atmel.c:1540: undefined reference to `dma_alloc_coherent'
drivers/spi/spi-atmel.c:1623: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `atmel_spi_remove':
drivers/spi/spi-atmel.c:1665: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ep93xx_spi_dma_finish':
drivers/spi/spi-ep93xx.c:550: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `ep93xx_spi_dma_prepare':
drivers/spi/spi-ep93xx.c:516: undefined reference to `dma_map_sg'
drivers/spi/spi-ep93xx.c:522: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `omap2_mcspi_rx_dma':
drivers/spi/spi-omap2-mcspi.c:475: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `omap2_mcspi_txrx_dma':
drivers/spi/spi-omap2-mcspi.c:589: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `omap2_mcspi_transfer_one_message':
drivers/spi/spi-omap2-mcspi.c:1202: undefined reference to `dma_map_single'
drivers/spi/spi-omap2-mcspi.c:1204: undefined reference to `dma_mapping_error'
drivers/spi/spi-omap2-mcspi.c:1211: undefined reference to `dma_map_single'
drivers/spi/spi-omap2-mcspi.c:1213: undefined reference to `dma_mapping_error'
drivers/spi/spi-omap2-mcspi.c:1217: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `tegra_spi_deinit_dma_param':
drivers/spi/spi-tegra114.c:675: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `tegra_spi_copy_spi_rxbuf_to_client_rxbuf':
drivers/spi/spi-tegra114.c:415: undefined reference to `dma_sync_single_for_cpu'
drivers/spi/spi-tegra114.c:440: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `tegra_spi_copy_client_txbuf_to_spi_txbuf':
drivers/spi/spi-tegra114.c:381: undefined reference to `dma_sync_single_for_cpu'
drivers/spi/spi-tegra114.c:405: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `tegra_spi_start_dma_based_transfer':
drivers/spi/spi-tegra114.c:543: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `tegra_slink_deinit_dma_param':
drivers/spi/spi-tegra20-slink.c:705: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `tegra_slink_copy_spi_rxbuf_to_client_rxbuf':
drivers/spi/spi-tegra20-slink.c:427: undefined reference to `dma_sync_single_for_cpu'
drivers/spi/spi-tegra20-slink.c:452: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `tegra_slink_copy_client_txbuf_to_spi_txbuf':
drivers/spi/spi-tegra20-slink.c:393: undefined reference to `dma_sync_single_for_cpu'
drivers/spi/spi-tegra20-slink.c:417: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `tegra_slink_start_dma_based_transfer':
drivers/spi/spi-tegra20-slink.c:561: undefined reference to `dma_sync_single_for_cpu'

Add dependencies on HAS_DMA to fix this.

Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
---
v2: Use sparate "depends on HAS_DMA" instead of "COMPILE_TEST && HAS_DMA"
---
 drivers/spi/Kconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bdd20c1707e5..1a5965539efd 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -69,6 +69,7 @@ config SPI_ATH79
 
 config SPI_ATMEL
 	tristate "Atmel SPI Controller"
+	depends on HAS_DMA
 	depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
 	help
 	  This selects a driver for the Atmel SPI Controller, present on
@@ -185,6 +186,7 @@ config SPI_EFM32
 
 config SPI_EP93XX
 	tristate "Cirrus Logic EP93xx SPI controller"
+	depends on HAS_DMA
 	depends on ARCH_EP93XX || COMPILE_TEST
 	help
 	  This enables using the Cirrus EP93xx SPI controller in master
@@ -320,6 +322,7 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
 	tristate "McSPI driver for OMAP"
+	depends on HAS_DMA
 	depends on ARM || ARM64 || AVR32 || HEXAGON || MIPS || SUPERH
 	depends on ARCH_OMAP2PLUS || COMPILE_TEST
 	help
@@ -506,7 +509,7 @@ config SPI_MXS
 config SPI_TEGRA114
 	tristate "NVIDIA Tegra114 SPI Controller"
 	depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-	depends on RESET_CONTROLLER
+	depends on RESET_CONTROLLER && HAS_DMA
 	help
 	  SPI driver for NVIDIA Tegra114 SPI Controller interface. This controller
 	  is different than the older SoCs SPI controller and also register interface
@@ -524,7 +527,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
 	tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
 	depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-	depends on RESET_CONTROLLER
+	depends on RESET_CONTROLLER && HAS_DMA
 	help
 	  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
1.9.1

--
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 v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Mark Brown]

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

On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote:
> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with
> COMPILE_TEST") allows compile-testing drivers on platforms they're not
> meant for.

> However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies
> assumed by the platform dependencies before, like HAS_DMA.

I'm wondering if it isn't better to have the non-DMA platforms define
stub (always error) DMA functions instead - it's less error prone and
with SPI there's a bunch of drivers which can run perfectly usefully
without DMA while optionally supporting DMA.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Geert Uytterhoeven]

Hi Mark,

On Fri, Aug 29, 2014 at 7:37 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote:
>> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with
>> COMPILE_TEST") allows compile-testing drivers on platforms they're not
>> meant for.
>
>> However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies
>> assumed by the platform dependencies before, like HAS_DMA.
>
> I'm wondering if it isn't better to have the non-DMA platforms define
> stub (always error) DMA functions instead - it's less error prone and
> with SPI there's a bunch of drivers which can run perfectly usefully
> without DMA while optionally supporting DMA.

The SPI problem will sort itself out once all SPI master drivers have been
converted to use the SPI DMA core ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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 v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Geert Uytterhoeven]

Hi Mark,

On Fri, Aug 29, 2014 at 9:13 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Aug 29, 2014 at 7:37 PM, Mark Brown <broonie@kernel.org> wrote:
>> On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote:
>>> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with
>>> COMPILE_TEST") allows compile-testing drivers on platforms they're not
>>> meant for.
>>
>>> However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies
>>> assumed by the platform dependencies before, like HAS_DMA.
>>
>> I'm wondering if it isn't better to have the non-DMA platforms define
>> stub (always error) DMA functions instead - it's less error prone and
>> with SPI there's a bunch of drivers which can run perfectly usefully
>> without DMA while optionally supporting DMA.
>
> The SPI problem will sort itself out once all SPI master drivers have been
> converted to use the SPI DMA core ;-)

BTW, the dmaengine API has stubs, only the low-level dma-mapping API
doesn't. That's why e.g. spi-rspi doesn't need a dependency on HAS_DMA.
So it's indeed a good thing to handle the low-level DMA mapping in the
subsystem's core, as only that part can be optional and depend on HAS_DMA.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Mark Brown]

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

On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote:
> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with
> COMPILE_TEST") allows compile-testing drivers on platforms they're not
> meant for.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where needed

[Mark Brown]

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

On Sun, Aug 31, 2014 at 10:39:09AM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 29, 2014 at 9:13 PM, Geert Uytterhoeven

> >> I'm wondering if it isn't better to have the non-DMA platforms define
> >> stub (always error) DMA functions instead - it's less error prone and
> >> with SPI there's a bunch of drivers which can run perfectly usefully
> >> without DMA while optionally supporting DMA.

> > The SPI problem will sort itself out once all SPI master drivers have been
> > converted to use the SPI DMA core ;-)

> BTW, the dmaengine API has stubs, only the low-level dma-mapping API
> doesn't. That's why e.g. spi-rspi doesn't need a dependency on HAS_DMA.
> So it's indeed a good thing to handle the low-level DMA mapping in the
> subsystem's core, as only that part can be optional and depend on HAS_DMA.

Yeah, but I'd expect there's other subsystems which will be in a similar
boat here and with dmaengine having stubs it seems strange that the
mapping API doesn't.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]