| Message ID | 1521208314-4783-1-git-send-email-geert@linux-m68k.org |
|---|---|
| Headers | show |
| Series | Allow compile-testing NO_DMA (drivers) | expand |
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,
Hi Herbert, On Fri, Mar 16, 2018 at 4:14 PM, Herbert Xu <herbert@gondor.apana.org.au> 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 -- 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
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,
> 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 <wsa@the-dreams.de> 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
> 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 <geert@linux-m68k.org> 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 <robherring2@gmail.com> wrote: > On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven > <geert@linux-m68k.org> 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
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(-)