Hi all,
If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
symbol bad_dma_ops, thus causing a link failure if it is ever used.
The intention of this is twofold:
1. To catch users of the DMA API on systems that do no support the DMA
mapping API,
2. To avoid building drivers that cannot work on such systems anyway.
However, the disadvantage is that we have to keep on adding dependencies
on HAS_DMA all over the place.
Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
already covering intention #2. Having to add an explicit dependency on
HAS_DMA here is cumbersome, and hinders compile-testing.
Hence I think the time is ripe to reconsider the link failure.
Patch series "[PATCH v2 0/5] Allow compile-testing NO_DMA (core)"
(https://lkml.org/lkml/2018/3/16/435) already:
- Changed get_dma_ops() to return NULL instead,
- Added a few more dummies to enable compile-testing.
This patch series:
- Removes dependencies on HAS_DMA for symbols that already have
platform dependencies implying HAS_DMA.
To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
this (drivers) series should be applied after the previous (core)
series (but not many people may notice/care ;-)
Changes compared to v1:
- Add Reviewed-by, Acked-by,
- Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
- Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
- Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
- Split in per-subsystem patches,
- Split-off the core part in a separate series.
This series is against v4.16-rc5. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.
Thanks!
Geert Uytterhoeven (21):
ASoC: Remove depends on HAS_DMA in case of platform dependency
ata: Remove depends on HAS_DMA in case of platform dependency
crypto: Remove depends on HAS_DMA in case of platform dependency
fbdev: Remove depends on HAS_DMA in case of platform dependency
firewire: Remove depends on HAS_DMA in case of platform dependency
fpga: Remove depends on HAS_DMA in case of platform dependency
i2c: Remove depends on HAS_DMA in case of platform dependency
iio: adc: Remove depends on HAS_DMA in case of platform dependency
iommu: Remove depends on HAS_DMA in case of platform dependency
lightnvm: Remove depends on HAS_DMA in case of platform dependency
mailbox: Remove depends on HAS_DMA in case of platform dependency
media: Remove depends on HAS_DMA in case of platform dependency
mmc: Remove depends on HAS_DMA in case of platform dependency
mtd: Remove depends on HAS_DMA in case of platform dependency
net: Remove depends on HAS_DMA in case of platform dependency
remoteproc: Remove depends on HAS_DMA in case of platform dependency
scsi: hisi_sas: Remove depends on HAS_DMA in case of platform
dependency
serial: Remove depends on HAS_DMA in case of platform dependency
spi: Remove depends on HAS_DMA in case of platform dependency
staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
usb: Remove depends on HAS_DMA in case of platform dependency
drivers/ata/Kconfig | 2 --
drivers/crypto/Kconfig | 14 +++------
drivers/firewire/Kconfig | 1 -
drivers/fpga/Kconfig | 1 -
drivers/i2c/busses/Kconfig | 3 --
drivers/iio/adc/Kconfig | 2 --
drivers/iommu/Kconfig | 5 ++--
drivers/lightnvm/Kconfig | 2 +-
drivers/mailbox/Kconfig | 2 --
drivers/media/common/videobuf2/Kconfig | 2 --
drivers/media/pci/dt3155/Kconfig | 1 -
drivers/media/pci/intel/ipu3/Kconfig | 1 -
drivers/media/pci/solo6x10/Kconfig | 1 -
drivers/media/pci/sta2x11/Kconfig | 1 -
drivers/media/pci/tw5864/Kconfig | 1 -
drivers/media/pci/tw686x/Kconfig | 1 -
drivers/media/platform/Kconfig | 40 ++++++++-----------------
drivers/media/platform/am437x/Kconfig | 2 +-
drivers/media/platform/atmel/Kconfig | 4 +--
drivers/media/platform/blackfin/Kconfig | 1 -
drivers/media/platform/davinci/Kconfig | 6 ----
drivers/media/platform/marvell-ccic/Kconfig | 3 +-
drivers/media/platform/rcar-vin/Kconfig | 2 +-
drivers/media/platform/soc_camera/Kconfig | 3 +-
drivers/media/platform/sti/c8sectpfe/Kconfig | 2 +-
drivers/media/v4l2-core/Kconfig | 2 --
drivers/mmc/host/Kconfig | 10 ++-----
drivers/mtd/nand/Kconfig | 8 ++---
drivers/mtd/spi-nor/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 -
drivers/net/ethernet/apm/xgene/Kconfig | 1 -
drivers/net/ethernet/arc/Kconfig | 6 ++--
drivers/net/ethernet/broadcom/Kconfig | 2 --
drivers/net/ethernet/calxeda/Kconfig | 2 +-
drivers/net/ethernet/hisilicon/Kconfig | 2 +-
drivers/net/ethernet/marvell/Kconfig | 8 ++---
drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
drivers/net/ethernet/renesas/Kconfig | 2 --
drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +-
drivers/remoteproc/Kconfig | 1 -
drivers/scsi/hisi_sas/Kconfig | 2 +-
drivers/spi/Kconfig | 12 ++------
drivers/staging/media/davinci_vpfe/Kconfig | 1 -
drivers/staging/media/omap4iss/Kconfig | 1 -
drivers/staging/vc04_services/Kconfig | 1 -
drivers/tty/serial/Kconfig | 4 ---
drivers/usb/gadget/udc/Kconfig | 4 +--
drivers/usb/mtu3/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 3 +-
sound/soc/bcm/Kconfig | 3 +-
sound/soc/kirkwood/Kconfig | 1 -
sound/soc/pxa/Kconfig | 1 -
sound/soc/qcom/Kconfig | 7 ++---
55 files changed, 56 insertions(+), 143 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Acked-by: Robin Murphy <[email protected]>
---
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/scsi/hisi_sas/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index d42f29a5eb65046d..57183fce70fb6355 100644
--- a/drivers/scsi/hisi_sas/Kconfig
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -1,6 +1,6 @@
config SCSI_HISI_SAS
tristate "HiSilicon SAS"
- depends on HAS_DMA && HAS_IOMEM
+ depends on HAS_IOMEM
depends on ARM64 || COMPILE_TEST
select SCSI_SAS_LIBSAS
select BLK_DEV_INTEGRITY
--
2.7.4
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Acked-by: Robin Murphy <[email protected]>
---
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/ata/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7120d6211546949..9eaeed1fb237fa33 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
- depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
config SATA_MV
tristate "Marvell SATA support"
- depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
On 16/03/2018 13:51, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> Reviewed-by: Mark Brown <[email protected]>
> Acked-by: Robin Murphy <[email protected]>
Acked-by: John Garry <[email protected]>
On Fri, Mar 16, 2018 at 02:51:33PM +0100, Geert Uytterhoeven wrote:
>
> This patch series:
> - Removes dependencies on HAS_DMA for symbols that already have
> platform dependencies implying HAS_DMA.
>
> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> this (drivers) series should be applied after the previous (core)
> series (but not many people may notice/care ;-)
>
> Changes compared to v1:
> - Add Reviewed-by, Acked-by,
> - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
> - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
> - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
> MTD_NAND_MARVELL on HAS_DMA,
> - Split in per-subsystem patches,
> - Split-off the core part in a separate series.
>
> This series is against v4.16-rc5. It can also be found at
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
>
> It has been compile-tested with allmodconfig and allyesconfig for
> m68k/sun3, and has received attention from the kbuild test robot.
Do these patches have any dependencies? Can they be applied directly
in a subsystem tree?
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
On Fri, Mar 16, 2018 at 4:14 PM, Herbert Xu <[email protected]> wrote:
> On Fri, Mar 16, 2018 at 02:51:33PM +0100, Geert Uytterhoeven wrote:
>> This patch series:
>> - Removes dependencies on HAS_DMA for symbols that already have
>> platform dependencies implying HAS_DMA.
>>
>> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
>> this (drivers) series should be applied after the previous (core)
>> series (but not many people may notice/care ;-)
>>
>> Changes compared to v1:
>> - Add Reviewed-by, Acked-by,
>> - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
>> - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
>> - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
>> MTD_NAND_MARVELL on HAS_DMA,
>> - Split in per-subsystem patches,
>> - Split-off the core part in a separate series.
>>
>> This series is against v4.16-rc5. It can also be found at
>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
>>
>> It has been compile-tested with allmodconfig and allyesconfig for
>> m68k/sun3, and has received attention from the kbuild test robot.
>
> Do these patches have any dependencies? Can they be applied directly
> in a subsystem tree?
| To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
| this (drivers) series should be applied after the previous (core)
| series (but not many people may notice/care ;-)
Apart from introducing build failures in allmodconfig/allyesconfig builds on
(uncommon) NO_DMA=y platforms, they can be applied directly and individually.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Fri, Mar 16, 2018 at 04:41:57PM +0100, Geert Uytterhoeven wrote:
>
> | To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> | this (drivers) series should be applied after the previous (core)
> | series (but not many people may notice/care ;-)
Oops, didn't notice it :)
> Apart from introducing build failures in allmodconfig/allyesconfig builds on
> (uncommon) NO_DMA=y platforms, they can be applied directly and individually.
I think I'll leave this with you then.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> this (drivers) series should be applied after the previous (core)
> series (but not many people may notice/care ;-)
I still don't get if there is a dependency on the core patches. I.e.
shall I apply the subsystem patch now by myself or do you want to push
the series after the core patch and need my ack here?
Hi Wolfram,
On Fri, Mar 16, 2018 at 10:23 PM, Wolfram Sang <[email protected]> wrote:
>> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
>> this (drivers) series should be applied after the previous (core)
>> series (but not many people may notice/care ;-)
>
> I still don't get if there is a dependency on the core patches. I.e.
> shall I apply the subsystem patch now by myself or do you want to push
> the series after the core patch and need my ack here?
Yes, there is a dependency. Without the core patches, enabling COMPILE_TEST,
and compile-testing drivers irrelevant on obscure NO_DMA=y platforms will
cause build failures.
To play it safe, you want to postpone the subsystem patches until the core
part has landed upstream. I will rebase and resubmit after v4.17-rc1.
Thanks, and sorry for being unclear.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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 play it safe, you want to postpone the subsystem patches until the core
> part has landed upstream. I will rebase and resubmit after v4.17-rc1.
Thanks for the heads up. I'll wait for the rebased patch then and apply
it after rc1 for 4.17.
On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
<[email protected]> wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
> 1. To catch users of the DMA API on systems that do no support the DMA
> mapping API,
> 2. To avoid building drivers that cannot work on such systems anyway.
>
> However, the disadvantage is that we have to keep on adding dependencies
> on HAS_DMA all over the place.
>
> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
> already covering intention #2. Having to add an explicit dependency on
> HAS_DMA here is cumbersome, and hinders compile-testing.
The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.
Rob
Hi Rob,
On Thu, Apr 5, 2018 at 2:32 AM, Rob Herring <[email protected]> wrote:
> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
> <[email protected]> wrote:
>> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
>> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>>
>> The intention of this is twofold:
>> 1. To catch users of the DMA API on systems that do no support the DMA
>> mapping API,
>> 2. To avoid building drivers that cannot work on such systems anyway.
>>
>> However, the disadvantage is that we have to keep on adding dependencies
>> on HAS_DMA all over the place.
>>
>> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
>> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
>> already covering intention #2. Having to add an explicit dependency on
>> HAS_DMA here is cumbersome, and hinders compile-testing.
>
> The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
> remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.
Perhaps, if time permits...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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