Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header
Hi Simon, On Tue, May 22, 2018 at 11:05 AM, Simon Horman <ho...@verge.net.au> wrote: >> --- a/drivers/media/platform/vsp1/vsp1_regs.h >> +++ b/drivers/media/platform/vsp1/vsp1_regs.h >> @@ -1,4 +1,4 @@ >> -/* SPDX-License-Identifier: GPL-2.0 */ >> +/* SPDX-License-Identifier: GPL-2.0+ */ > > While you are changing this line, I believe the correct format is > to use a '//' comment. > > i.e.: > > // SPDX-License-Identifier: GPL-2.0+ Not for C header files, only for C source files. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH v2] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Acked-by: Arnd Bergmann <a...@arndb.de> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Reviewed-by: Simon Horman <horms+rene...@verge.net.au> --- v2: - Add Acked-by, Reviewed-by. --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 840475e3a6b87ac1..a0fe7b127412d3e1 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -397,7 +397,7 @@ config VIDEO_SH_VEU config VIDEO_RENESAS_FDP1 tristate "Renesas Fine Display Processor" depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV -- 2.7.4
[PATCH v4] media: Remove depends on HAS_DMA in case of platform dependency
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. Note: - The various VIDEOBUF*DMA* symbols had to loose their dependencies on HAS_DMA, as they are selected by several individual drivers. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- From: kbuild test robot <l...@intel.com> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git no-dma-compile-testing-v4-media branch HEAD: 9fd4215b490cae0bb6dd058a18a19e60dbcd3020 media: Remove depends on HAS_DMA in case of platform dependency elapsed time: 41m configs tested: 99 --- v4: - Rebase to media-next on 2018-05-17, v3: - Rebase to v4.17-rc1, - Handle new VIDEO_RENESAS_CEU symbol, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA, - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on HAS_DMA, - Split per subsystem. --- 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 | 43 +--- drivers/media/platform/am437x/Kconfig| 2 +- drivers/media/platform/atmel/Kconfig | 4 +-- drivers/media/platform/davinci/Kconfig | 6 drivers/media/platform/marvell-ccic/Kconfig | 2 -- 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/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - 18 files changed, 20 insertions(+), 56 deletions(-) diff --git a/drivers/media/common/videobuf2/Kconfig b/drivers/media/common/videobuf2/Kconfig index 17c32ea58395d78f..4ed11b46676ac4d0 100644 --- a/drivers/media/common/videobuf2/Kconfig +++ b/drivers/media/common/videobuf2/Kconfig @@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS config VIDEOBUF2_DMA_CONTIG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS select DMA_SHARED_BUFFER @@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC config VIDEOBUF2_DMA_SG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644 --- a/drivers/media/pci/dt3155/Kconfig +++ b/drivers/media/pci/dt3155/Kconfig @@ -1,7 +1,6 @@ config VIDEO_DT3155 tristate "DT3155 frame grabber" depends on PCI && VIDEO_DEV && VIDEO_V4L2 - depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n ---help--- diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig index 45cf99a512e484d5..c8bd98d7564afdfb 100644 --- a/drivers/media/pci/intel/ipu3/Kconfig +++ b/drivers/media/pci/intel/ipu3/Kconfig @@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2 depends on VIDEO_V4L2_SUBDEV_API depends on (X86 && ACPI) || COMPILE_TEST depends on MEDIA_CONTROLLER - depends on HAS_DMA select V4L2_FWNODE select VIDEOBUF2_DMA_SG diff --git a/drivers/media/pci/solo6x10/Kconfig b/drivers/media/pci/solo6x10/Kconfig index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644 --- a/drivers/media/pci/solo6x10/Kconfig +++ b/drivers/media/pci/solo6x10/Kconfig @@ -1,7 +1,6 @@ config VIDEO_SOLO6X10 tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)" depends on PCI && VIDEO_DEV && SND && I2C - depends on HAS_DMA select BITREVERSE select FONT_SUPPORT select FONT_8x16 diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig index 7af3f1cbcea824b9..4407b9f881e400d8 100644 --- a/drivers/media/pci/sta2x11/Kconfig +++ b/drivers/media/pci/sta2x11/Kconfig @@ -1,7 +1,6 @@ config STA2X11_VIP tristate "STA2X11 VIP Video For Linux" depends on STA2X11 || COMPILE_TEST - depends on HAS_DMA select V
Re: [PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0
Hi Jacopo, On Thu, Apr 26, 2018 at 8:24 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc. > > Reported-by: Geert Uytterhoeven <ge...@glider.be> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> Thanks for your patch! Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Minor question below. > --- a/arch/arm/boot/dts/r8a7740.dtsi > +++ b/arch/arm/boot/dts/r8a7740.dtsi > @@ -67,6 +67,16 @@ > power-domains = <_d4>; > }; > > + ceu0: ceu@fe91 { > + reg = <0xfe91 0x3000>; > + compatible = "renesas,r8a7740-ceu"; > + interrupts = ; > + clocks = <_clks R8A7740_CLK_CEU20>; > + clock-names = "ceu20"; Why the "clock-names" property? It's not mentioned in the DT bindings, and may cause issues if the bindings are ever amended. > + power-domains = <_a4r>; > + status = "disabled"; > + }; > + Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] media: vsp1: cleanup a false positive warning
Hi Mauro, On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab <mchehab+sams...@kernel.org> wrote: > With the new vsp1 code changes introduced by changeset > f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines > dynamically"), > smatch complains with: > drivers/media/platform/vsp1/vsp1_drm.c:262 > vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could > be null (see line 180) > > This is a false positive, as, if pipe->bru is NULL, the brx > var will be different, with ends by calling a code that will > set pipe->bru to another value. > > Yet, cleaning this false positive is as easy as adding an explicit > check if pipe->bru is NULL. > > Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org> Thanks for your patch! s/bru/brx/ > --- a/drivers/media/platform/vsp1/vsp1_drm.c > +++ b/drivers/media/platform/vsp1/vsp1_drm.c > @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device > *vsp1, > brx = >brs->entity; > > /* Switch BRx if needed. */ > - if (brx != pipe->brx) { > + if (brx != pipe->brx || !pipe->brx) { > struct vsp1_entity *released_brx = NULL; > > /* Release our BRx if we have one. */ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v14 03/33] rcar-vin: add Gen3 devicetree bindings documentation
-Board setup example (vin1 composite video input) > - > +Board setup example for Gen2 platforms (vin1 composite video input) > +--- > > { > status = "okay"; > @@ -95,6 +118,77 @@ Board setup example (vin1 composite video input) > }; > }; > > +Device node example for Gen3 platforms > +-- > > +vin0: video@e6ef { > +compatible = "renesas,vin-r8a7795"; > +reg = <0 0xe6ef 0 0x1000>; > +interrupts = ; > +clocks = < CPG_MOD 811>; > +power-domains = < R8A7795_PD_ALWAYS_ON>; > +resets = < 811>; > +renesas,id = <0>; > + > +ports { > +#address-cells = <1>; > +#size-cells = <0>; > + > +port@1 { > +#address-cells = <1>; > +#size-cells = <0>; > + > +reg = <1>; > + > +vin0csi20: endpoint@0 { > +reg = <0>; > +remote-endpoint= <>; > +}; > +vin0csi21: endpoint@1 { > +reg = <1>; > +remote-endpoint= <>; > +}; > +vin0csi40: endpoint@2 { > +reg = <2>; > +remote-endpoint= <>; > +}; > +}; > +}; > +}; > + > +csi20: csi2@fea8 { > +compatible = "renesas,r8a7795-csi2"; > +reg = <0 0xfea8 0 0x1>; > +interrupts = ; > +clocks = < CPG_MOD 714>; > +power-domains = < R8A7795_PD_ALWAYS_ON>; > +resets = < 714>; > + > +ports { > +#address-cells = <1>; > +#size-cells = <0>; > + > +port@0 { > +reg = <0>; > +csi20_in: endpoint { > +clock-lanes = <0>; > + data-lanes = <1>; > +remote-endpoint = <_txb>; > +}; > +}; > + > +port@1 { > +#address-cells = <1>; > +#size-cells = <0>; > + > +reg = <1>; > + > +csi20vin0: endpoint@0 { > +reg = <0>; > +remote-endpoint = <>; > +}; > +}; > +}; > +}; > > [1] video-interfaces.txt common video media interface Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] rcar-vin: fix null pointer dereference in rvin_group_get()
On Wed, Apr 25, 2018 at 1:45 AM, Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> wrote: > Store the group pointer before disassociating the VIN from the group. s/get/put/ in one-line summary? > Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions") > Reported-by: Colin Ian King <colin.k...@canonical.com> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > --- > drivers/media/platform/rcar-vin/rcar-core.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c > b/drivers/media/platform/rcar-vin/rcar-core.c > index 7bc2774a11232362..d3072e166a1ca24f 100644 > --- a/drivers/media/platform/rcar-vin/rcar-core.c > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > @@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin) > > static void rvin_group_put(struct rvin_dev *vin) > { > - mutex_lock(>group->lock); > + struct rvin_group *group = vin->group; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
(Reducing/enhancing CC list) On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS > platform dependencies. Hence finish the conversion from ARCH_SHMOBILE > to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit > 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS"). > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- > This depends on the previous patches in this series, hence the RFC. > > JFTR, after this, the following symbols for drivers supporting only > Renesas SuperH "SH-Mobile" SoCs can no longer be selected: > - CONFIG_KEYBOARD_SH_KEYSC, > - CONFIG_VIDEO_SH_VOU, > - CONFIG_VIDEO_SH_MOBILE_CEU, > - CONFIG_DRM_SHMOBILE[*], > - CONFIG_FB_SH_MOBILE_MERAM. > (changes for a shmobile_defconfig .config) Apparently CONFIG_VIDEO_SH_MOBILE_CEU was set in the old armadillo800eva_defconfig, and used by the old board code. While DT bindings do exist [1], some DT support has been added to the driver [2], and this even ended up as the example in [3], this was never enabled in the corresponding board DTS. Nevertheless, I understand that soc_camera-based driver is obsolete, and has been replaced by [4], but bindings for r8a7740 are lacking [5]. [1] Documentation/devicetree/bindings/media/sh_mobile_ceu.txt [2] drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c [3] Documentation/devicetree/bindings/media/video-interfaces.txt [4] drivers/media/platform/renesas-ceu.c [5] Documentation/devicetree/bindings/media/renesas,ceu.txt Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus
Hi Mauro, On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > The virt_to_bus/bus_to_virt macros are arch-specific. Some > archs don't support it. Yet, as it is interesting to allow > doing compilation tests on non-ia32/ia64 archs, provide a > fallback for such archs. > > While here, enable COMPILE_TEST for two media drivers that > depends on it. > > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com> Thanks for your patch! I guess this will cause the kernel to crash if I insert an STA2X11 or Zoran PCI card in a non-VIRT_TO_BUS machine and boot an all{mod,yes}config kernel? IMHO dummies are fine if they return error codes, not it they can cause crashes. > --- > drivers/media/pci/sta2x11/Kconfig | 4 ++-- > drivers/media/pci/zoran/Kconfig | 3 ++- > include/asm-generic/io.h | 2 +- > 3 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/pci/sta2x11/Kconfig > b/drivers/media/pci/sta2x11/Kconfig > index 7af3f1cbcea8..fb4b4c8ac430 100644 > --- a/drivers/media/pci/sta2x11/Kconfig > +++ b/drivers/media/pci/sta2x11/Kconfig > @@ -1,10 +1,10 @@ > config STA2X11_VIP > tristate "STA2X11 VIP Video For Linux" > - depends on STA2X11 || COMPILE_TEST > + depends on (STA2X11 && VIRT_TO_BUS) || COMPILE_TEST > depends on HAS_DMA > select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT > select VIDEOBUF2_DMA_CONTIG > - depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS > + depends on PCI && VIDEO_V4L2 > depends on VIDEO_V4L2_SUBDEV_API > depends on I2C > help > diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig > index 39ec35bd21a5..5d2678a9e310 100644 > --- a/drivers/media/pci/zoran/Kconfig > +++ b/drivers/media/pci/zoran/Kconfig > @@ -1,6 +1,7 @@ > config VIDEO_ZORAN > tristate "Zoran ZR36057/36067 Video For Linux" > - depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS > + depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 > + depends on VIRT_TO_BUS || COMPILE_TEST > depends on !ALPHA > help > Say Y for support for MJPEG capture cards based on the Zoran > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h > index 66d1d45fa2e1..f448129ad15c 100644 > --- a/include/asm-generic/io.h > +++ b/include/asm-generic/io.h > @@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t > phys, void *addr) > } > #endif > > -#ifdef CONFIG_VIRT_TO_BUS > +#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST) > #ifndef virt_to_bus > static inline unsigned long virt_to_bus(void *address) > { Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
Hi Laurent, On Sun, Apr 22, 2018 at 10:46 AM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote: >> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote: >> > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs >> > only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce >> > ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency >> > than the legacy ARCH_SHMOBILE, hence use the former. >> > >> > This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near >> > future. >> > >> > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> >> >> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> >> >> How would you like to get this merged ? > > Unless you would like to merge the whole series in one go, I'll take this in > my tree as I have a conflicting patch I would like to submit for v4.18. Please take it in your tree, thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/3] v4l: rcar_fdp1: Enable compilation on Gen2 platforms
Hi Laurent, On Sun, Apr 22, 2018 at 12:28 PM, Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com> wrote: > Commit 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency") fixed > a compilation breakage when the optional VIDEO_RENESAS_FCP dependency is > compiled as a module while the rcar_fdp1 driver is built in. As a side > effect it disabled compilation on Gen2 by disallowing the valid > combination ARCH_RENESAS && !VIDEO_RENESAS_FCP. Fix it by handling the > dependency the same way the vsp1 driver did in commit 199946731fa4 > ("[media] vsp1: clarify FCP dependency"). > > Fixes: 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency") > Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com> > --- > drivers/media/platform/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 621d63b2001d..81c3ab95c050 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -397,7 +397,7 @@ config VIDEO_RENESAS_FDP1 > tristate "Renesas Fine Display Processor" > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > depends on ARCH_RENESAS || COMPILE_TEST > - depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP > + depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP s/!ARM64/ARCH_RCAR_GEN2/? > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS
Hi Mark, On Fri, Apr 20, 2018 at 6:48 PM, Mark Brown <broo...@kernel.org> wrote: > On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote: >> The first 6 patches can be applied independently by subsystem >> maintainers. >> The last two patches depend on the first 6 patches, and are thus marked >> RFC. > > Would it not make sense to try to apply everything en masse rather than > delaying? I'm happy to apply the subsystem stuff but if it gets things > done quicker or more efficiently I'm also happy to have the lot merged > as one series. In theory, yes. However, this touches multiple subsystems, and it's non-critical, so I don't want to spent the energy to get this done in a synchronized way. It's way easier to postpone the last (RFC) patches when everything else has been applied by subsystem maintainers. So please apply your part, thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS platform dependencies. Hence finish the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS"). Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- This depends on the previous patches in this series, hence the RFC. JFTR, after this, the following symbols for drivers supporting only Renesas SuperH "SH-Mobile" SoCs can no longer be selected: - CONFIG_KEYBOARD_SH_KEYSC, - CONFIG_VIDEO_SH_VOU, - CONFIG_VIDEO_SH_MOBILE_CEU, - CONFIG_DRM_SHMOBILE[*], - CONFIG_FB_SH_MOBILE_MERAM. (changes for a shmobile_defconfig .config) [*] CONFIG_DRM_SHMOBILE has a dependency on ARM, but it was never wired up. From the use of sh_mobile_meram, I guess it was meant for SH-Mobile AP4 on Mackerel or AP4EVB, which are long gone. So the only remaining upstream platforms that could make use of it are legacy SuperH SH-Mobile SoCs? --- arch/arm/mach-shmobile/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 96672da02f5f17b9..d892c5b52b6f5627 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -1,6 +1,3 @@ -config ARCH_SHMOBILE - bool - config PM_RMOBILE bool select PM @@ -30,7 +27,6 @@ menuconfig ARCH_RENESAS bool "Renesas ARM SoCs" depends on ARCH_MULTI_V7 && MMU select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE - select ARCH_SHMOBILE select ARM_GIC select GPIOLIB select HAVE_ARM_SCU if SMP -- 2.7.4
[PATCH/RFC 8/8] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol
The Kconfig symbol for Renesas 64-bit ARM SoCs has always been ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs. Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas 32-bit SoCs. Now all drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS platform dependencies, there is no longer a need to select ARCH_SHMOBILE. With ARCH_SHMOBILE gone, move the ARCH_RENESAS section up, to restore alphabetical sort order. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- This depends on the driver patches in this series, hence the RFC. JFTR, after this, the following symbols for drivers supporting only Renesas SuperH "SH-Mobile" SoCs can no longer be selected: - CONFIG_KEYBOARD_SH_KEYSC, - CONFIG_VIDEO_SH_VOU, - CONFIG_VIDEO_RENESAS_CEU, - CONFIG_FB_SH_MOBILE_MERAM. (changes for a renesas_defconfig .config) --- arch/arm64/Kconfig.platforms | 42 +++--- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index d5aeac351fc3a776..49d8ed1ab84766dd 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -145,31 +145,8 @@ config ARCH_REALTEK This enables support for the ARMv8 based Realtek chipsets, like the RTD1295. -config ARCH_ROCKCHIP - bool "Rockchip Platforms" - select ARCH_HAS_RESET_CONTROLLER - select GPIOLIB - select PINCTRL - select PINCTRL_ROCKCHIP - select ROCKCHIP_TIMER - help - This enables support for the ARMv8 based Rockchip chipsets, - like the RK3368. - -config ARCH_SEATTLE - bool "AMD Seattle SoC Family" - help - This enables support for AMD Seattle SOC Family - -config ARCH_SHMOBILE - bool - -config ARCH_SYNQUACER - bool "Socionext SynQuacer SoC Family" - config ARCH_RENESAS bool "Renesas SoC Platforms" - select ARCH_SHMOBILE select PINCTRL select PM select PM_GENERIC_DOMAINS @@ -220,6 +197,25 @@ config ARCH_R8A77995 help This enables support for the Renesas R-Car D3 SoC. +config ARCH_ROCKCHIP + bool "Rockchip Platforms" + select ARCH_HAS_RESET_CONTROLLER + select GPIOLIB + select PINCTRL + select PINCTRL_ROCKCHIP + select ROCKCHIP_TIMER + help + This enables support for the ARMv8 based Rockchip chipsets, + like the RK3368. + +config ARCH_SEATTLE + bool "AMD Seattle SoC Family" + help + This enables support for AMD Seattle SOC Family + +config ARCH_SYNQUACER + bool "Socionext SynQuacer SoC Family" + config ARCH_STRATIX10 bool "Altera's Stratix 10 SoCFPGA Family" help -- 2.7.4
[PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS
Hi all, Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas ARM SoCs. This patch series completes the conversion, by: 1. Updating dependencies for drivers that weren't converted yet, 2. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64. The first 6 patches can be applied independently by subsystem maintainers. The last two patches depend on the first 6 patches, and are thus marked RFC. Thanks for your comments! Geert Uytterhoeven (8): arm: shmobile: Change platform dependency to ARCH_RENESAS dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS sh_eth: Change platform check to CONFIG_ARCH_RENESAS staging: emxx_udc: Change platform dependency to ARCH_RENESAS ASoC: sh: Update menu title and platform dependency [RFC] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol [RFC] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol arch/arm/Kconfig | 2 +- arch/arm/Makefile | 2 +- arch/arm/mach-shmobile/Kconfig| 4 --- arch/arm64/Kconfig.platforms | 42 + drivers/dma/sh/shdmac.c | 50 +++ drivers/media/platform/Kconfig| 2 +- drivers/net/ethernet/renesas/sh_eth.h | 2 +- drivers/staging/emxx_udc/Kconfig | 2 +- sound/soc/sh/Kconfig | 4 +-- 9 files changed, 47 insertions(+), 63 deletions(-) -- 2.7.4 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- arch/arm/Kconfig | 2 +- arch/arm/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a7f8e7f4b88fdd03..2d34c0a44877e85b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1467,7 +1467,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 2048 if ARCH_SOCFPGA - default 1024 if ARCH_BRCMSTB || ARCH_SHMOBILE || ARCH_TEGRA || \ + default 1024 if ARCH_BRCMSTB || ARCH_RENESAS || ARCH_TEGRA || \ ARCH_ZYNQ default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \ SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210 diff --git a/arch/arm/Makefile b/arch/arm/Makefile index e4e537f27339f7a1..a92f5a876d96839d 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -212,7 +212,7 @@ machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx machine-$(CONFIG_ARCH_S5PV210) += s5pv210 machine-$(CONFIG_ARCH_SA1100) += sa1100 -machine-$(CONFIG_ARCH_SHMOBILE)+= shmobile +machine-$(CONFIG_ARCH_RENESAS) += shmobile machine-$(CONFIG_ARCH_SIRF)+= prima2 machine-$(CONFIG_ARCH_SOCFPGA) += socfpga machine-$(CONFIG_ARCH_STI) += sti -- 2.7.4
[PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy CONFIG_ARCH_SHMOBILE, hence use the former. Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4 check. This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/net/ethernet/renesas/sh_eth.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h index a5b792ce2ae7d046..1bf930d4a1e52c18 100644 --- a/drivers/net/ethernet/renesas/sh_eth.h +++ b/drivers/net/ethernet/renesas/sh_eth.h @@ -163,7 +163,7 @@ enum { }; /* Driver's parameters */ -#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE) +#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_RENESAS) #define SH_ETH_RX_ALIGN32 #else #define SH_ETH_RX_ALIGN2 -- 2.7.4
[PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy CONFIG_ARCH_SHMOBILE, hence use the former. Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4 check, just like before support for Renesas ARM SoCs was added. Instead of blindly changing all the #ifdefs, switch the main code block in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the remaining #ifdefs. This will allow to drop ARCH_SHMOBILE on ARM in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/dma/sh/shdmac.c | 50 + 1 file changed, 21 insertions(+), 29 deletions(-) diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c index 516f5487cc44cf96..8fcaae482ce0949a 100644 --- a/drivers/dma/sh/shdmac.c +++ b/drivers/dma/sh/shdmac.c @@ -440,7 +440,6 @@ static bool sh_dmae_reset(struct sh_dmae_device *shdev) return ret; } -#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE) static irqreturn_t sh_dmae_err(int irq, void *data) { struct sh_dmae_device *shdev = data; @@ -451,7 +450,6 @@ static irqreturn_t sh_dmae_err(int irq, void *data) sh_dmae_reset(shdev); return IRQ_HANDLED; } -#endif static bool sh_dmae_desc_completed(struct shdma_chan *schan, struct shdma_desc *sdesc) @@ -683,11 +681,8 @@ static int sh_dmae_probe(struct platform_device *pdev) const struct sh_dmae_pdata *pdata; unsigned long chan_flag[SH_DMAE_MAX_CHANNELS] = {}; int chan_irq[SH_DMAE_MAX_CHANNELS]; -#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE) unsigned long irqflags = 0; - int errirq; -#endif - int err, i, irq_cnt = 0, irqres = 0, irq_cap = 0; + int err, errirq, i, irq_cnt = 0, irqres = 0, irq_cap = 0; struct sh_dmae_device *shdev; struct dma_device *dma_dev; struct resource *chan, *dmars, *errirq_res, *chanirq_res; @@ -789,33 +784,32 @@ static int sh_dmae_probe(struct platform_device *pdev) if (err) goto rst_err; -#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE) - chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1); + if (IS_ENABLED(CONFIG_CPU_SH4) || IS_ENABLED(CONFIG_ARCH_RENESAS)) { + chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1); - if (!chanirq_res) - chanirq_res = errirq_res; - else - irqres++; + if (!chanirq_res) + chanirq_res = errirq_res; + else + irqres++; - if (chanirq_res == errirq_res || - (errirq_res->flags & IORESOURCE_BITS) == IORESOURCE_IRQ_SHAREABLE) - irqflags = IRQF_SHARED; + if (chanirq_res == errirq_res || + (errirq_res->flags & IORESOURCE_BITS) == IORESOURCE_IRQ_SHAREABLE) + irqflags = IRQF_SHARED; - errirq = errirq_res->start; + errirq = errirq_res->start; - err = devm_request_irq(>dev, errirq, sh_dmae_err, irqflags, - "DMAC Address Error", shdev); - if (err) { - dev_err(>dev, - "DMA failed requesting irq #%d, error %d\n", - errirq, err); - goto eirq_err; + err = devm_request_irq(>dev, errirq, sh_dmae_err, + irqflags, "DMAC Address Error", shdev); + if (err) { + dev_err(>dev, + "DMA failed requesting irq #%d, error %d\n", + errirq, err); + goto eirq_err; + } + } else { + chanirq_res = errirq_res; } -#else - chanirq_res = errirq_res; -#endif /* CONFIG_CPU_SH4 || CONFIG_ARCH_SHMOBILE */ - if (chanirq_res->start == chanirq_res->end && !platform_get_resource(pdev, IORESOURCE_IRQ, 1)) { /* Special case - all multiplexed */ @@ -881,9 +875,7 @@ static int sh_dmae_probe(struct platform_device *pdev) chan_probe_err: sh_dmae_chan_remove(shdev); -#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE) eirq_err: -#endif rst_err: spin_lock_irq(_dmae_lock); list_del_rcu(>node); -- 2.7.4
[PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS
Emma Mobile is a Renesas ARM SoC. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/staging/emxx_udc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/emxx_udc/Kconfig b/drivers/staging/emxx_udc/Kconfig index d7577096fb25ae7a..e50e722183648c55 100644 --- a/drivers/staging/emxx_udc/Kconfig +++ b/drivers/staging/emxx_udc/Kconfig @@ -1,6 +1,6 @@ config USB_EMXX tristate "EMXX USB Function Device Controller" - depends on USB_GADGET && (ARCH_SHMOBILE || (ARM && COMPILE_TEST)) + depends on USB_GADGET && (ARCH_RENESAS || (ARM && COMPILE_TEST)) help The Emma Mobile series of SoCs from Renesas Electronics and former NEC Electronics include USB Function hardware. -- 2.7.4
[PATCH 6/8] ASoC: sh: Update menu title and platform dependency
Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as both SuperH and ARM SoCs are supported. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM SoCs than the legacy ARCH_SHMOBILE, hence use the former. Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH dependency. This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- sound/soc/sh/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig index 1aa5cd77ca24a06f..c1b7fb91e3063f2b 100644 --- a/sound/soc/sh/Kconfig +++ b/sound/soc/sh/Kconfig @@ -1,5 +1,5 @@ -menu "SoC Audio support for SuperH" - depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST +menu "SoC Audio support for Renesas SoCs" + depends on SUPERH || ARCH_RENESAS || COMPILE_TEST config SND_SOC_PCM_SH7760 tristate "SoC Audio support for Renesas SH7760" -- 2.7.4
[PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near future. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f9235e8f8e962d2e..7ad4725f9d1f9627 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -396,7 +396,7 @@ config VIDEO_SH_VEU config VIDEO_RENESAS_FDP1 tristate "Renesas Fine Display Processor" depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV -- 2.7.4
[PATCH v3 18/20] spi: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Mark Brown <broo...@kernel.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/spi/Kconfig | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 2d4146ce2f1be49d..5a8524a3bc13f92d 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -71,7 +71,6 @@ config SPI_ARMADA_3700 config SPI_ATMEL tristate "Atmel SPI Controller" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST help This selects a driver for the Atmel SPI Controller, present on @@ -233,7 +232,6 @@ 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 @@ -355,7 +353,6 @@ config SPI_FSL_SPI config SPI_FSL_DSPI tristate "Freescale DSPI controller" select REGMAP_MMIO - depends on HAS_DMA depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || COMPILE_TEST help This enables support for the Freescale DSPI controller in master @@ -431,7 +428,6 @@ config SPI_OMAP_UWIRE config SPI_OMAP24XX tristate "McSPI driver for OMAP" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || COMPILE_TEST select SG_SPLIT help @@ -440,7 +436,6 @@ config SPI_OMAP24XX config SPI_TI_QSPI tristate "DRA7xxx QSPI controller support" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || COMPILE_TEST help QSPI master controller for DRA7xxx used for flash devices. @@ -469,7 +464,6 @@ config SPI_PIC32 config SPI_PIC32_SQI tristate "Microchip PIC32 Quad SPI driver" depends on MACH_PIC32 || COMPILE_TEST - depends on HAS_DMA help SPI driver for PIC32 Quad SPI controller. @@ -572,7 +566,7 @@ config SPI_SC18IS602 config SPI_SH_MSIOF tristate "SuperH MSIOF SPI controller" - depends on HAVE_CLK && HAS_DMA + depends on HAVE_CLK depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST help SPI driver for SuperH and SH Mobile MSIOF blocks. @@ -650,7 +644,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 && HAS_DMA + depends on RESET_CONTROLLER help SPI driver for NVIDIA Tegra114 SPI Controller interface. This controller is different than the older SoCs SPI controller and also register interface @@ -668,7 +662,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 && HAS_DMA + depends on RESET_CONTROLLER help SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface. -- 2.7.4
[PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Ulf Hansson <ulf.hans...@linaro.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/mmc/host/Kconfig | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 9589f9c9046f14b1..3978d0418958bf6b 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support" depends on ARCH_MESON || COMPILE_TEST depends on COMMON_CLK - depends on HAS_DMA depends on OF help This selects support for the SD/MMC Host Controller on @@ -401,7 +400,6 @@ config MMC_OMAP config MMC_OMAP_HS tristate "TI OMAP High Speed Multimedia Card Interface support" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST help This selects the TI OMAP High Speed Multimedia card Interface. @@ -511,7 +509,6 @@ config MMC_DAVINCI config MMC_GOLDFISH tristate "goldfish qemu Multimedia Card Interface support" - depends on HAS_DMA depends on GOLDFISH || COMPILE_TEST help This selects the Goldfish Multimedia card Interface emulation @@ -605,7 +602,7 @@ config MMC_SDHI config MMC_SDHI_SYS_DMAC tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC" - depends on MMC_SDHI && HAS_DMA + depends on MMC_SDHI default MMC_SDHI if (SUPERH || ARM) help This provides DMA support for SDHI SD/SDIO controllers @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC config MMC_SDHI_INTERNAL_DMAC tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering" depends on ARM64 || COMPILE_TEST - depends on MMC_SDHI && HAS_DMA + depends on MMC_SDHI default MMC_SDHI if ARM64 help This provides DMA support for SDHI SD/SDIO controllers @@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX config MMC_DW tristate "Synopsys DesignWare Memory Card Interface" - depends on HAS_DMA depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST help This selects support for the Synopsys DesignWare Mobile Storage IP @@ -748,7 +744,6 @@ config MMC_DW_ZX config MMC_SH_MMCIF tristate "SuperH Internal MMCIF support" - depends on HAS_DMA depends on SUPERH || ARCH_RENESAS || COMPILE_TEST help This selects the MMC Host Interface controller (MMCIF) found in various @@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI config MMC_BCM2835 tristate "Broadcom BCM2835 SDHOST MMC Controller support" depends on ARCH_BCM2835 || COMPILE_TEST - depends on HAS_DMA help This selects the BCM2835 SDHOST MMC controller. If you have a BCM2835 platform with SD or MMC devices, say Y or M here. -- 2.7.4
[PATCH v3 19/20] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/staging/vc04_services/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/vc04_services/Kconfig b/drivers/staging/vc04_services/Kconfig index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644 --- a/drivers/staging/vc04_services/Kconfig +++ b/drivers/staging/vc04_services/Kconfig @@ -1,6 +1,5 @@ menuconfig BCM_VIDEOCORE tristate "Broadcom VideoCore support" - depends on HAS_DMA depends on OF depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE) default y -- 2.7.4
[PATCH v3 05/20] firewire: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/firewire/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig index 145974f9662b63e6..4199849e37585181 100644 --- a/drivers/firewire/Kconfig +++ b/drivers/firewire/Kconfig @@ -1,5 +1,4 @@ menu "IEEE 1394 (FireWire) support" - depends on HAS_DMA depends on PCI || COMPILE_TEST # firewire-core does not depend on PCI but is # not useful without PCI controller driver -- 2.7.4
[PATCH v3 12/20] media: Remove depends on HAS_DMA in case of platform dependency
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. Note: - The various VIDEOBUF*DMA* symbols had to loose their dependencies on HAS_DMA, as they are selected by several individual drivers. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, - Handle new VIDEO_RENESAS_CEU symbol, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA, - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on HAS_DMA, - Split per subsystem. --- 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 | 42 ++-- drivers/media/platform/am437x/Kconfig| 2 +- drivers/media/platform/atmel/Kconfig | 4 +-- 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/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - 18 files changed, 21 insertions(+), 55 deletions(-) diff --git a/drivers/media/common/videobuf2/Kconfig b/drivers/media/common/videobuf2/Kconfig index 17c32ea58395d78f..4ed11b46676ac4d0 100644 --- a/drivers/media/common/videobuf2/Kconfig +++ b/drivers/media/common/videobuf2/Kconfig @@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS config VIDEOBUF2_DMA_CONTIG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS select DMA_SHARED_BUFFER @@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC config VIDEOBUF2_DMA_SG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644 --- a/drivers/media/pci/dt3155/Kconfig +++ b/drivers/media/pci/dt3155/Kconfig @@ -1,7 +1,6 @@ config VIDEO_DT3155 tristate "DT3155 frame grabber" depends on PCI && VIDEO_DEV && VIDEO_V4L2 - depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n ---help--- diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig index a82d3fe277d2cdec..2533ec1cb1177715 100644 --- a/drivers/media/pci/intel/ipu3/Kconfig +++ b/drivers/media/pci/intel/ipu3/Kconfig @@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2 depends on VIDEO_V4L2_SUBDEV_API depends on X86 || COMPILE_TEST depends on MEDIA_CONTROLLER - depends on HAS_DMA depends on ACPI select V4L2_FWNODE select VIDEOBUF2_DMA_SG diff --git a/drivers/media/pci/solo6x10/Kconfig b/drivers/media/pci/solo6x10/Kconfig index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644 --- a/drivers/media/pci/solo6x10/Kconfig +++ b/drivers/media/pci/solo6x10/Kconfig @@ -1,7 +1,6 @@ config VIDEO_SOLO6X10 tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)" depends on PCI && VIDEO_DEV && SND && I2C - depends on HAS_DMA select BITREVERSE select FONT_SUPPORT select FONT_8x16 diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig index e03587b1af714199..7b856395ede9295c 100644 --- a/drivers/media/pci/sta2x11/Kconfig +++ b/drivers/media/pci/sta2x11/Kconfig @@ -1,7 +1,6 @@ config STA2X11_VIP tristate "STA2X11 VIP Video For Linux" depends on STA2X11 - depends on HAS_DMA select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT select VIDEOBUF2_DMA_CONTIG depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig index 87c8f327e2d49dfa..760fb11dfeaef47b 100644 --- a/drivers/media/pci/tw5864/Kconfig +++ b/drivers/media/pci/tw5864/Kconfig @@ -1,7 +1,6 @@ config VIDEO_TW5864
[PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/i2c/busses/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index c4865b08d7fb9e3b..8d21b9825d71764d 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -707,7 +707,6 @@ config I2C_MPC config I2C_MT65XX tristate "MediaTek I2C adapter" depends on ARCH_MEDIATEK || COMPILE_TEST - depends on HAS_DMA help This selects the MediaTek(R) Integrated Inter Circuit bus driver for MT65xx and MT81xx. @@ -885,7 +884,6 @@ config I2C_SH7760 config I2C_SH_MOBILE tristate "SuperH Mobile I2C Controller" - depends on HAS_DMA depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST help If you say yes to this option, support will be included for the @@ -1098,7 +1096,6 @@ config I2C_XLP9XX config I2C_RCAR tristate "Renesas R-Car I2C Controller" - depends on HAS_DMA depends on ARCH_RENESAS || COMPILE_TEST select I2C_SLAVE help -- 2.7.4
[PATCH v3 14/20] mtd: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA, - Split per subsystem. --- drivers/mtd/nand/raw/Kconfig | 8 ++-- drivers/mtd/spi-nor/Kconfig | 2 +- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 19a2b283fbbe627e..6871ff0fd300bb81 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -46,7 +46,7 @@ config MTD_NAND_DENALI config MTD_NAND_DENALI_PCI tristate "Support Denali NAND controller on Intel Moorestown" select MTD_NAND_DENALI - depends on HAS_DMA && PCI + depends on PCI help Enable the driver for NAND flash on Intel Moorestown, using the Denali NAND controller core. @@ -152,7 +152,6 @@ config MTD_NAND_S3C2410_CLKSTOP config MTD_NAND_TANGO tristate "NAND Flash support for Tango chips" depends on ARCH_TANGO || COMPILE_TEST - depends on HAS_DMA help Enables the NAND Flash controller on Tango chips. @@ -285,7 +284,7 @@ config MTD_NAND_MARVELL tristate "NAND controller support on Marvell boards" depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \ COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM help This enables the NAND flash controller driver for Marvell boards, including: @@ -447,7 +446,6 @@ config MTD_NAND_SH_FLCTL tristate "Support for NAND on Renesas SuperH FLCTL" depends on SUPERH || COMPILE_TEST depends on HAS_IOMEM - depends on HAS_DMA help Several Renesas SuperH CPU has FLCTL. This option enables support for NAND Flash using FLCTL. @@ -515,7 +513,6 @@ config MTD_NAND_SUNXI config MTD_NAND_HISI504 tristate "Support for NAND controller on Hisilicon SoC Hip04" depends on ARCH_HISI || COMPILE_TEST - depends on HAS_DMA help Enables support for NAND controller on Hisilicon SoC Hip04. @@ -529,7 +526,6 @@ config MTD_NAND_QCOM config MTD_NAND_MTK tristate "Support for NAND controller on MTK SoCs" depends on ARCH_MEDIATEK || COMPILE_TEST - depends on HAS_DMA help Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 89da88e591215db1..c493b8230a38c059 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI config SPI_HISI_SFC tristate "Hisilicon SPI-NOR Flash Controller(SFC)" depends on ARCH_HISI || COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM help This enables support for hisilicon SPI-NOR flash controller. -- 2.7.4
[PATCH v3 06/20] fpga: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Alan Tull <at...@kernel.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/fpga/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index f47ef848bcd056d5..fd539132542e30ee 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP config FPGA_MGR_ZYNQ_FPGA tristate "Xilinx Zynq FPGA" depends on ARCH_ZYNQ || COMPILE_TEST - depends on HAS_DMA help FPGA manager driver support for Xilinx Zynq FPGAs. -- 2.7.4
[PATCH v3 16/20] remoteproc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Bjorn Andersson <bjorn.anders...@linaro.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/remoteproc/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 027274008b086d6f..cd1c168fd18898dc 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -24,7 +24,6 @@ config IMX_REMOTEPROC config OMAP_REMOTEPROC tristate "OMAP remoteproc support" - depends on HAS_DMA depends on ARCH_OMAP4 || SOC_OMAP5 depends on OMAP_IOMMU select MAILBOX -- 2.7.4
[PATCH v3 00/20] Allow compile-testing NO_DMA (drivers)
Hi all, As of v4.17-rc1, patch series "[PATCH v2 0/5] Allow compile-testing NO_DMA (core)" (https://lkml.org/lkml/2018/3/16/435) has been included upstream, and drivers using the DMA API can be compile-tested on platforms selecting NO_DMA. This follow-up patch series removes dependencies on HAS_DMA for symbols that already have platform dependencies implying HAS_DMA, which increases compile-coverage. Please apply to your tree if appropriate. Changes compared to v2: - Add Acked-by, - Rebased to v4.17-rc1, dropping applied patch for scsi/hisi_sas, - Handle new VIDEO_RENESAS_CEU symbol, - Drop obsolete note about FSL_FMAN. 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.17-rc1. 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-v3 It has been compile-tested with allmodconfig and allyesconfig for m68k/sun3, and has received attention from the kbuild test robot. Thanks for applying! Geert Uytterhoeven (20): 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 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 | 42 + drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/atmel/Kconfig| 4 +-- 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/raw/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/quanten
[PATCH v3 02/20] ata: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, 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 2b16e7c8fff35764..39b181d6bd0d8cf2 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
[PATCH v3 11/20] mailbox: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, - Removed bogus notes, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/mailbox/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index a2bb27446dce4e2b..725dce5ba62d5baf 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -162,7 +162,6 @@ config XGENE_SLIMPRO_MBOX config BCM_PDC_MBOX tristate "Broadcom FlexSparx DMA Mailbox" depends on ARCH_BCM_IPROC || COMPILE_TEST - depends on HAS_DMA help Mailbox implementation for the Broadcom FlexSparx DMA ring manager, which provides access to various offload engines on Broadcom @@ -172,7 +171,6 @@ config BCM_FLEXRM_MBOX tristate "Broadcom FlexRM Mailbox" depends on ARM64 depends on ARCH_BCM_IPROC || COMPILE_TEST - depends on HAS_DMA select GENERIC_MSI_IRQ_DOMAIN default m if ARCH_BCM_IPROC help -- 2.7.4
[PATCH v3 03/20] crypto: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Herbert Xu <herb...@gondor.apana.org.au> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/crypto/Kconfig | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index d1ea1a07cecbb36c..3dbc47528667b77c 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM select CRYPTO_AES select CRYPTO_BLKCIPHER help @@ -466,7 +466,6 @@ endif # if CRYPTO_DEV_UX500 config CRYPTO_DEV_ATMEL_AUTHENC tristate "Support for Atmel IPSEC/SSL hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_AUTHENC select CRYPTO_DEV_ATMEL_AES @@ -479,7 +478,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC config CRYPTO_DEV_ATMEL_AES tristate "Support for Atmel AES hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_AES select CRYPTO_AEAD @@ -494,7 +492,6 @@ config CRYPTO_DEV_ATMEL_AES config CRYPTO_DEV_ATMEL_TDES tristate "Support for Atmel DES/TDES hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_DES select CRYPTO_BLKCIPHER @@ -508,7 +505,6 @@ config CRYPTO_DEV_ATMEL_TDES config CRYPTO_DEV_ATMEL_SHA tristate "Support for Atmel SHA hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_HASH help @@ -574,7 +570,8 @@ config CRYPTO_DEV_CAVIUM_ZIP config CRYPTO_DEV_QCE tristate "Qualcomm crypto engine accelerator" - depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM + depends on ARCH_QCOM || COMPILE_TEST + depends on HAS_IOMEM select CRYPTO_AES select CRYPTO_DES select CRYPTO_ECB @@ -598,7 +595,6 @@ source "drivers/crypto/vmx/Kconfig" config CRYPTO_DEV_IMGTEC_HASH tristate "Imagination Technologies hardware hash accelerator" depends on MIPS || COMPILE_TEST - depends on HAS_DMA select CRYPTO_MD5 select CRYPTO_SHA1 select CRYPTO_SHA256 @@ -650,7 +646,6 @@ config CRYPTO_DEV_ROCKCHIP config CRYPTO_DEV_MEDIATEK tristate "MediaTek's EIP97 Cryptographic Engine driver" - depends on HAS_DMA depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST select CRYPTO_AES select CRYPTO_AEAD @@ -688,7 +683,7 @@ source "drivers/crypto/stm32/Kconfig" config CRYPTO_DEV_SAFEXCEL tristate "Inside Secure's SafeXcel cryptographic engine driver" - depends on HAS_DMA && OF + depends on OF depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT) select CRYPTO_AES select CRYPTO_BLKCIPHER @@ -706,7 +701,6 @@ config CRYPTO_DEV_SAFEXCEL config CRYPTO_DEV_ARTPEC6 tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration." depends on ARM && (ARCH_ARTPEC || COMPILE_TEST) - depends on HAS_DMA depends on OF select CRYPTO_AEAD select CRYPTO_AES -- 2.7.4
[PATCH v3 09/20] iommu: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Joerg Roedel <jroe...@suse.de> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/iommu/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index df171cb8582296b9..c76157e57f6ba4ba 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE config IOMMU_IO_PGTABLE_LPAE bool "ARMv7/v8 Long Descriptor Format" select IOMMU_IO_PGTABLE - depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)) + depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64) help Enable support for the ARM long descriptor pagetable format. This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page @@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST config IOMMU_IO_PGTABLE_ARMV7S bool "ARMv7/v8 Short Descriptor Format" select IOMMU_IO_PGTABLE - depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST) + depends on ARM || ARM64 || COMPILE_TEST help Enable support for the ARM Short-descriptor pagetable format. This supports 32-bit virtual and physical addresses mapped using @@ -376,7 +376,6 @@ config QCOM_IOMMU # Note: iommu drivers cannot (yet?) be built as modules bool "Qualcomm IOMMU Support" depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64) - depends on HAS_DMA select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU -- 2.7.4
[PATCH v3 01/20] ASoC: Remove depends on HAS_DMA in case of platform dependency
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. Note: - The various SND_SOC_LPASS_* symbols had to loose their dependencies on HAS_DMA, as they are selected by SND_SOC_STORM and/or SND_SOC_APQ8016_SBC. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Mark Brown <broo...@kernel.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA, - Split per subsystem. --- sound/soc/bcm/Kconfig | 3 +-- sound/soc/kirkwood/Kconfig | 1 - sound/soc/pxa/Kconfig | 1 - sound/soc/qcom/Kconfig | 7 ++- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig index edf367100ebd2f17..02f50b7a966ff262 100644 --- a/sound/soc/bcm/Kconfig +++ b/sound/soc/bcm/Kconfig @@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S config SND_SOC_CYGNUS tristate "SoC platform audio for Broadcom Cygnus chips" depends on ARCH_BCM_CYGNUS || COMPILE_TEST - depends on HAS_DMA help Say Y if you want to add support for ASoC audio on Broadcom Cygnus chips (bcm958300, bcm958305, bcm911360) - If you don't know what to do here, say N. \ No newline at end of file + If you don't know what to do here, say N. diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig index bc3c7b5ac752e471..132bb83f8e99aff3 100644 --- a/sound/soc/kirkwood/Kconfig +++ b/sound/soc/kirkwood/Kconfig @@ -1,7 +1,6 @@ config SND_KIRKWOOD_SOC tristate "SoC Audio for the Marvell Kirkwood and Dove chips" depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST - depends on HAS_DMA help Say Y or M if you want to add support for codecs attached to the Kirkwood I2S interface. You will also need to select the diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 484ab3c2ad672fc8..960744e46edc0549 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -1,7 +1,6 @@ config SND_PXA2XX_SOC tristate "SoC Audio for the Intel PXA2xx chip" depends on ARCH_PXA || COMPILE_TEST - depends on HAS_DMA select SND_PXA2XX_LIB help Say Y or M if you want to add support for codecs attached to diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 8ec9a074b38bd702..3cc252e55468eaab 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/Kconfig @@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU config SND_SOC_LPASS_PLATFORM tristate - depends on HAS_DMA select REGMAP_MMIO config SND_SOC_LPASS_IPQ806X tristate - depends on HAS_DMA select SND_SOC_LPASS_CPU select SND_SOC_LPASS_PLATFORM config SND_SOC_LPASS_APQ8016 tristate - depends on HAS_DMA select SND_SOC_LPASS_CPU select SND_SOC_LPASS_PLATFORM config SND_SOC_STORM tristate "ASoC I2S support for Storm boards" - depends on SND_SOC_QCOM && HAS_DMA + depends on SND_SOC_QCOM select SND_SOC_LPASS_IPQ806X select SND_SOC_MAX98357A help @@ -37,7 +34,7 @@ config SND_SOC_STORM config SND_SOC_APQ8016_SBC tristate "SoC Audio support for APQ8016 SBC platforms" - depends on SND_SOC_QCOM && HAS_DMA + depends on SND_SOC_QCOM select SND_SOC_LPASS_APQ8016 help Support for Qualcomm Technologies LPASS audio block in -- 2.7.4
[PATCH v3 20/20] usb: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> [drivers/usb/gadget/] Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/usb/gadget/udc/Kconfig | 4 ++-- drivers/usb/mtu3/Kconfig | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig index 0875d38476ee9395..9c3b4f86965e80c7 100644 --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -179,7 +179,7 @@ config USB_R8A66597 config USB_RENESAS_USBHS_UDC tristate 'Renesas USBHS controller' - depends on USB_RENESAS_USBHS && HAS_DMA + depends on USB_RENESAS_USBHS help Renesas USBHS is a discrete USB host and peripheral controller chip that supports both full and high speed USB 2.0 data transfers. @@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC config USB_RENESAS_USB3 tristate 'Renesas USB3.0 Peripheral controller' depends on ARCH_RENESAS || COMPILE_TEST - depends on EXTCON && HAS_DMA + depends on EXTCON help Renesas USB3.0 Peripheral controller is a USB peripheral controller that supports super, high, and full speed USB 3.0 data transfers. diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig index 25cd61947beea51e..c0c0eb88e5eafc74 100644 --- a/drivers/usb/mtu3/Kconfig +++ b/drivers/usb/mtu3/Kconfig @@ -2,7 +2,7 @@ config USB_MTU3 tristate "MediaTek USB3 Dual Role controller" - depends on EXTCON && (USB || USB_GADGET) && HAS_DMA + depends on EXTCON && (USB || USB_GADGET) depends on ARCH_MEDIATEK || COMPILE_TEST select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD help -- 2.7.4
[PATCH v3 10/20] lightnvm: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Reviewed-by: Matias Bjørling <m...@lightnvm.io> --- v3: - Add Reviewed-by, - Rebase to v4.17-rc1, - Removed bogus notes, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/lightnvm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig index 10c08982185a572f..9c03f35d9df113c6 100644 --- a/drivers/lightnvm/Kconfig +++ b/drivers/lightnvm/Kconfig @@ -4,7 +4,7 @@ menuconfig NVM bool "Open-Channel SSD target support" - depends on BLOCK && HAS_DMA && PCI + depends on BLOCK && PCI select BLK_DEV_NVME help Say Y here to get to enable Open-channel SSDs. -- 2.7.4
[PATCH v3 04/20] fbdev: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/video/fbdev/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index d94254263ea5caa7..4f9853ec1721950f 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2075,7 +2075,8 @@ config FB_XILINX config FB_GOLDFISH tristate "Goldfish Framebuffer" - depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST) + depends on FB + depends on GOLDFISH || COMPILE_TEST select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 2.7.4
[PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v3: - Rebase to v4.17-rc1, - Drop obsolete note about FSL_FMAN, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- 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 +- 12 files changed, 12 insertions(+), 19 deletions(-) diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig index d5c15e8bb3de706b..f273af136fc7c995 100644 --- a/drivers/net/ethernet/amd/Kconfig +++ b/drivers/net/ethernet/amd/Kconfig @@ -173,7 +173,7 @@ config SUNLANCE config AMD_XGBE tristate "AMD 10GbE Ethernet driver" - depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && HAS_DMA + depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM depends on X86 || ARM64 || COMPILE_TEST select BITREVERSE select CRC32 diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig b/drivers/net/ethernet/apm/xgene-v2/Kconfig index 1205861b631896a0..eedd3f3dd22e2201 100644 --- a/drivers/net/ethernet/apm/xgene-v2/Kconfig +++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig @@ -1,6 +1,5 @@ config NET_XGENE_V2 tristate "APM X-Gene SoC Ethernet-v2 Driver" - depends on HAS_DMA depends on ARCH_XGENE || COMPILE_TEST help This is the Ethernet driver for the on-chip ethernet interface diff --git a/drivers/net/ethernet/apm/xgene/Kconfig b/drivers/net/ethernet/apm/xgene/Kconfig index afccb033177b3923..e4e33c900b577161 100644 --- a/drivers/net/ethernet/apm/xgene/Kconfig +++ b/drivers/net/ethernet/apm/xgene/Kconfig @@ -1,6 +1,5 @@ config NET_XGENE tristate "APM X-Gene SoC Ethernet Driver" - depends on HAS_DMA depends on ARCH_XGENE || COMPILE_TEST select PHYLIB select MDIO_XGENE diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig index e743ddf46343302f..5d0ab8e74b680cc6 100644 --- a/drivers/net/ethernet/arc/Kconfig +++ b/drivers/net/ethernet/arc/Kconfig @@ -24,7 +24,8 @@ config ARC_EMAC_CORE config ARC_EMAC tristate "ARC EMAC support" select ARC_EMAC_CORE - depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST) + depends on OF_IRQ && OF_NET + depends on ARC || COMPILE_TEST ---help--- On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x non-standard on-chip ethernet device ARC EMAC 10/100 is used. @@ -33,7 +34,8 @@ config ARC_EMAC config EMAC_ROCKCHIP tristate "Rockchip EMAC support" select ARC_EMAC_CORE - depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP || COMPILE_TEST) + depends on OF_IRQ && OF_NET && REGULATOR + depends on ARCH_ROCKCHIP || COMPILE_TEST ---help--- Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers. This selects Rockchip SoC glue layer support for the diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig index af75156919edfead..4c3bfde6e8de00f2 100644 --- a/drivers/net/ethernet/broadcom/Kconfig +++ b/drivers/net/ethernet/broadcom/Kconfig @@ -157,7 +157,6 @@ config BGMAC config BGMAC_BCMA tristate "Broadcom iProc GBit BCMA support" depends on BCMA && BCMA_HOST_SOC - depends on HAS_DMA depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST select BGMAC select PHYLIB @@ -170,7 +169,6 @@ config BGMAC_BCMA config BGMAC_PLATFORM tristate "Broadcom iProc GBit platform support" - depends on HAS_DMA
[PATCH v3 08/20] iio: adc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Jonathan Cameron <jonathan.came...@huawei.com> --- v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/iio/adc/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 15606f237480dacb..88bbcd0e98632273 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,7 +157,6 @@ config AT91_SAMA5D2_ADC tristate "Atmel AT91 SAMA5D2 ADC" depends on ARCH_AT91 || COMPILE_TEST depends on HAS_IOMEM - depends on HAS_DMA select IIO_TRIGGERED_BUFFER help Say yes here to build support for Atmel SAMA5D2 ADC which is @@ -646,7 +645,6 @@ config SD_ADC_MODULATOR config STM32_ADC_CORE tristate "STMicroelectronics STM32 adc core" depends on ARCH_STM32 || COMPILE_TEST - depends on HAS_DMA depends on OF depends on REGULATOR select IIO_BUFFER -- 2.7.4
Re: [PATCH v7] media: platform: Renesas IMR driver
Hi Sergei, On Fri, Aug 4, 2017 at 8:03 PM, Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> wrote: > The image renderer, or the distortion correction engine, is a drawing > processor with a simple instruction system capable of referencing video > capture data or data in an external memory as the 2D texture data and > performing texture mapping and drawing with respect to any shape that is > split into triangular objects. > > This V4L2 memory-to-memory device driver only supports image renderer light > extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support > can be added later... > > Based on the original patch by Konstantin Kozhevnikov. > > Signed-off-by: Konstantin Kozhevnikov > <konstantin.kozhevni...@cogentembedded.com> > Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> > Acked-by: Rob Herring <r...@kernel.org> > Documentation/devicetree/bindings/media/rcar_imr.txt | 27 > Documentation/media/v4l-drivers/index.rst|1 > Documentation/media/v4l-drivers/rcar_imr.rst | 372 +++ > drivers/media/platform/Kconfig | 13 > drivers/media/platform/Makefile |1 > drivers/media/platform/rcar_imr.c| 1832 > +++ > include/uapi/linux/rcar_imr.h| 182 + > 7 files changed, 2428 insertions(+) What's the status of this patch? The compatible value "renesas,r8a7796-imr-lx4" has been in use since v4.14. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
On Wed, Apr 4, 2018 at 5:26 PM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Thursday, 29 March 2018 14:30:39 EEST Maxime Ripard wrote: >> On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote: >> > + switch (priv->lanes) { >> > + case 1: >> > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_0; >> > + break; >> > + case 2: >> > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0; >> > + break; >> > + case 4: >> > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_3 | PHYCNT_ENABLE_2 | >> > + PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0; >> > + break; >> > + default: >> > + return -EINVAL; >> > + } >> >> I guess you could have a simpler construct here using this: >> >> phycnt = PHYCNT_ENABLECLK; >> >> switch (priv->lanes) { >> case 4: >> phycnt |= PHYCNT_ENABLE_3 | PHYCNT_ENABLE_2; >> case 2: >> phycnt |= PHYCNT_ENABLE_1; >> case 1: >> phycnt |= PHYCNT_ENABLE_0; >> break; >> >> default: >> return -EINVAL; >> } >> >> But that's really up to you. > > Wouldn't Niklas' version generate simpler code as it uses direct assignments ? Alternatively, you could check for a valid number of lanes, and use knowledge about the internal lane bits: phycnt = PHYCNT_ENABLECLK; phycnt |= (1 << priv->lanes) - 1; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH v2 04/21] fbdev: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/video/fbdev/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 11e699f1062b78ea..abee481f5fb778dd 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2174,7 +2174,8 @@ config FB_XILINX config FB_GOLDFISH tristate "Goldfish Framebuffer" - depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST) + depends on FB + depends on GOLDFISH || COMPILE_TEST select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 2.7.4
[PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency
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. Note: - The various SND_SOC_LPASS_* symbols had to loose their dependencies on HAS_DMA, as they are selected by SND_SOC_STORM and/or SND_SOC_APQ8016_SBC. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA, - Split per subsystem. --- sound/soc/bcm/Kconfig | 3 +-- sound/soc/kirkwood/Kconfig | 1 - sound/soc/pxa/Kconfig | 1 - sound/soc/qcom/Kconfig | 7 ++- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig index edf367100ebd2f17..02f50b7a966ff262 100644 --- a/sound/soc/bcm/Kconfig +++ b/sound/soc/bcm/Kconfig @@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S config SND_SOC_CYGNUS tristate "SoC platform audio for Broadcom Cygnus chips" depends on ARCH_BCM_CYGNUS || COMPILE_TEST - depends on HAS_DMA help Say Y if you want to add support for ASoC audio on Broadcom Cygnus chips (bcm958300, bcm958305, bcm911360) - If you don't know what to do here, say N. \ No newline at end of file + If you don't know what to do here, say N. diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig index bc3c7b5ac752e471..132bb83f8e99aff3 100644 --- a/sound/soc/kirkwood/Kconfig +++ b/sound/soc/kirkwood/Kconfig @@ -1,7 +1,6 @@ config SND_KIRKWOOD_SOC tristate "SoC Audio for the Marvell Kirkwood and Dove chips" depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST - depends on HAS_DMA help Say Y or M if you want to add support for codecs attached to the Kirkwood I2S interface. You will also need to select the diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 484ab3c2ad672fc8..960744e46edc0549 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -1,7 +1,6 @@ config SND_PXA2XX_SOC tristate "SoC Audio for the Intel PXA2xx chip" depends on ARCH_PXA || COMPILE_TEST - depends on HAS_DMA select SND_PXA2XX_LIB help Say Y or M if you want to add support for codecs attached to diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 8ec9a074b38bd702..3cc252e55468eaab 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/Kconfig @@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU config SND_SOC_LPASS_PLATFORM tristate - depends on HAS_DMA select REGMAP_MMIO config SND_SOC_LPASS_IPQ806X tristate - depends on HAS_DMA select SND_SOC_LPASS_CPU select SND_SOC_LPASS_PLATFORM config SND_SOC_LPASS_APQ8016 tristate - depends on HAS_DMA select SND_SOC_LPASS_CPU select SND_SOC_LPASS_PLATFORM config SND_SOC_STORM tristate "ASoC I2S support for Storm boards" - depends on SND_SOC_QCOM && HAS_DMA + depends on SND_SOC_QCOM select SND_SOC_LPASS_IPQ806X select SND_SOC_MAX98357A help @@ -37,7 +34,7 @@ config SND_SOC_STORM config SND_SOC_APQ8016_SBC tristate "SoC Audio support for APQ8016 SBC platforms" - depends on SND_SOC_QCOM && HAS_DMA + depends on SND_SOC_QCOM select SND_SOC_LPASS_APQ8016 help Support for Qualcomm Technologies LPASS audio block in -- 2.7.4
[PATCH v2 16/21] remoteproc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/remoteproc/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index b609e1d3654ba65f..b60d8132113de0f7 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -23,7 +23,6 @@ config IMX_REMOTEPROC config OMAP_REMOTEPROC tristate "OMAP remoteproc support" - depends on HAS_DMA depends on ARCH_OMAP4 || SOC_OMAP5 depends on OMAP_IOMMU select MAILBOX -- 2.7.4
[PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/crypto/Kconfig | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 4b741b83e23ff4de..3d27da7a430c0bc2 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM select CRYPTO_AES select CRYPTO_BLKCIPHER help @@ -473,7 +473,6 @@ config CRYPTO_DEV_BFIN_CRC config CRYPTO_DEV_ATMEL_AUTHENC tristate "Support for Atmel IPSEC/SSL hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_AUTHENC select CRYPTO_DEV_ATMEL_AES @@ -486,7 +485,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC config CRYPTO_DEV_ATMEL_AES tristate "Support for Atmel AES hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_AES select CRYPTO_AEAD @@ -501,7 +499,6 @@ config CRYPTO_DEV_ATMEL_AES config CRYPTO_DEV_ATMEL_TDES tristate "Support for Atmel DES/TDES hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_DES select CRYPTO_BLKCIPHER @@ -515,7 +512,6 @@ config CRYPTO_DEV_ATMEL_TDES config CRYPTO_DEV_ATMEL_SHA tristate "Support for Atmel SHA hw accelerator" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select CRYPTO_HASH help @@ -581,7 +577,8 @@ config CRYPTO_DEV_CAVIUM_ZIP config CRYPTO_DEV_QCE tristate "Qualcomm crypto engine accelerator" - depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM + depends on ARCH_QCOM || COMPILE_TEST + depends on HAS_IOMEM select CRYPTO_AES select CRYPTO_DES select CRYPTO_ECB @@ -605,7 +602,6 @@ source "drivers/crypto/vmx/Kconfig" config CRYPTO_DEV_IMGTEC_HASH tristate "Imagination Technologies hardware hash accelerator" depends on MIPS || COMPILE_TEST - depends on HAS_DMA select CRYPTO_MD5 select CRYPTO_SHA1 select CRYPTO_SHA256 @@ -657,7 +653,6 @@ config CRYPTO_DEV_ROCKCHIP config CRYPTO_DEV_MEDIATEK tristate "MediaTek's EIP97 Cryptographic Engine driver" - depends on HAS_DMA depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST select CRYPTO_AES select CRYPTO_AEAD @@ -695,7 +690,7 @@ source "drivers/crypto/stm32/Kconfig" config CRYPTO_DEV_SAFEXCEL tristate "Inside Secure's SafeXcel cryptographic engine driver" - depends on HAS_DMA && OF + depends on OF depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT) select CRYPTO_AES select CRYPTO_BLKCIPHER @@ -713,7 +708,6 @@ config CRYPTO_DEV_SAFEXCEL config CRYPTO_DEV_ARTPEC6 tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration." depends on ARM && (ARCH_ARTPEC || COMPILE_TEST) - depends on HAS_DMA depends on OF select CRYPTO_AEAD select CRYPTO_AES -- 2.7.4
[PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency
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. Notes: - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(), which does not exist if HAS_DMA=n (Do we need a dummy? The use of set_dma_ops() in this driver is questionable), - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their dependency on HAS_DMA, as they are selected from SND_SOC_APQ8016_SBC. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/lightnvm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig index 10c08982185a572f..9c03f35d9df113c6 100644 --- a/drivers/lightnvm/Kconfig +++ b/drivers/lightnvm/Kconfig @@ -4,7 +4,7 @@ menuconfig NVM bool "Open-Channel SSD target support" - depends on BLOCK && HAS_DMA && PCI + depends on BLOCK && PCI select BLK_DEV_NVME help Say Y here to get to enable Open-channel SSDs. -- 2.7.4
[PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)
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/ho
[PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/iio/adc/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 72bc2b71765ae2ff..57f46e88f5c2536e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -158,7 +158,6 @@ config AT91_SAMA5D2_ADC tristate "Atmel AT91 SAMA5D2 ADC" depends on ARCH_AT91 || COMPILE_TEST depends on HAS_IOMEM - depends on HAS_DMA select IIO_TRIGGERED_BUFFER help Say yes here to build support for Atmel SAMA5D2 ADC which is @@ -647,7 +646,6 @@ config SD_ADC_MODULATOR config STM32_ADC_CORE tristate "STMicroelectronics STM32 adc core" depends on ARCH_STM32 || COMPILE_TEST - depends on HAS_DMA depends on OF depends on REGULATOR select IIO_BUFFER -- 2.7.4
[PATCH v2 07/21] i2c: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/i2c/busses/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index e2954fb86d659f36..2ce9bbd5d56ed06a 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -725,7 +725,6 @@ config I2C_MPC config I2C_MT65XX tristate "MediaTek I2C adapter" depends on ARCH_MEDIATEK || COMPILE_TEST - depends on HAS_DMA help This selects the MediaTek(R) Integrated Inter Circuit bus driver for MT65xx and MT81xx. @@ -903,7 +902,6 @@ config I2C_SH7760 config I2C_SH_MOBILE tristate "SuperH Mobile I2C Controller" - depends on HAS_DMA depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST help If you say yes to this option, support will be included for the @@ -1106,7 +1104,6 @@ config I2C_XLP9XX config I2C_RCAR tristate "Renesas R-Car I2C Controller" - depends on HAS_DMA depends on ARCH_RENESAS || COMPILE_TEST select I2C_SLAVE help -- 2.7.4
[PATCH v2 09/21] iommu: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/iommu/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index f3a21343e636a8f2..32e91398c0555272 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE config IOMMU_IO_PGTABLE_LPAE bool "ARMv7/v8 Long Descriptor Format" select IOMMU_IO_PGTABLE - depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)) + depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64) help Enable support for the ARM long descriptor pagetable format. This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page @@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST config IOMMU_IO_PGTABLE_ARMV7S bool "ARMv7/v8 Short Descriptor Format" select IOMMU_IO_PGTABLE - depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST) + depends on ARM || ARM64 || COMPILE_TEST help Enable support for the ARM Short-descriptor pagetable format. This supports 32-bit virtual and physical addresses mapped using @@ -374,7 +374,6 @@ config QCOM_IOMMU # Note: iommu drivers cannot (yet?) be built as modules bool "Qualcomm IOMMU Support" depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64) - depends on HAS_DMA select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU -- 2.7.4
[PATCH v2 05/21] firewire: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/firewire/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig index 145974f9662b63e6..4199849e37585181 100644 --- a/drivers/firewire/Kconfig +++ b/drivers/firewire/Kconfig @@ -1,5 +1,4 @@ menu "IEEE 1394 (FireWire) support" - depends on HAS_DMA depends on PCI || COMPILE_TEST # firewire-core does not depend on PCI but is # not useful without PCI controller driver -- 2.7.4
[PATCH v2 12/21] media: Remove depends on HAS_DMA in case of platform dependency
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. Note: - The various VIDEOBUF*DMA* symbols had to loose their dependencies on HAS_DMA, as they are selected by several individual drivers. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA, - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on HAS_DMA, - Split per subsystem. --- 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/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - 19 files changed, 20 insertions(+), 55 deletions(-) diff --git a/drivers/media/common/videobuf2/Kconfig b/drivers/media/common/videobuf2/Kconfig index 17c32ea58395d78f..4ed11b46676ac4d0 100644 --- a/drivers/media/common/videobuf2/Kconfig +++ b/drivers/media/common/videobuf2/Kconfig @@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS config VIDEOBUF2_DMA_CONTIG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS select DMA_SHARED_BUFFER @@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC config VIDEOBUF2_DMA_SG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644 --- a/drivers/media/pci/dt3155/Kconfig +++ b/drivers/media/pci/dt3155/Kconfig @@ -1,7 +1,6 @@ config VIDEO_DT3155 tristate "DT3155 frame grabber" depends on PCI && VIDEO_DEV && VIDEO_V4L2 - depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n ---help--- diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig index a82d3fe277d2cdec..2533ec1cb1177715 100644 --- a/drivers/media/pci/intel/ipu3/Kconfig +++ b/drivers/media/pci/intel/ipu3/Kconfig @@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2 depends on VIDEO_V4L2_SUBDEV_API depends on X86 || COMPILE_TEST depends on MEDIA_CONTROLLER - depends on HAS_DMA depends on ACPI select V4L2_FWNODE select VIDEOBUF2_DMA_SG diff --git a/drivers/media/pci/solo6x10/Kconfig b/drivers/media/pci/solo6x10/Kconfig index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644 --- a/drivers/media/pci/solo6x10/Kconfig +++ b/drivers/media/pci/solo6x10/Kconfig @@ -1,7 +1,6 @@ config VIDEO_SOLO6X10 tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)" depends on PCI && VIDEO_DEV && SND && I2C - depends on HAS_DMA select BITREVERSE select FONT_SUPPORT select FONT_8x16 diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig index e03587b1af714199..7b856395ede9295c 100644 --- a/drivers/media/pci/sta2x11/Kconfig +++ b/drivers/media/pci/sta2x11/Kconfig @@ -1,7 +1,6 @@ config STA2X11_VIP tristate "STA2X11 VIP Video For Linux" depends on STA2X11 - depends on HAS_DMA select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT select VIDEOBUF2_DMA_CONTIG depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig index 87c8f327e2d49dfa..760fb11dfeaef47b 100644 --- a/drivers/media/pci/tw5864/Kconfig +++ b/drivers/media/pci/tw5864/Kconfig @@ -1,7 +1,6 @@ config VIDEO_TW5864 tristate &
[PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/spi/Kconfig | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 603783976b8152d4..7bd3a94f58511c41 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -71,7 +71,6 @@ config SPI_ARMADA_3700 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 @@ -252,7 +251,6 @@ 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 @@ -374,7 +372,6 @@ config SPI_FSL_SPI config SPI_FSL_DSPI tristate "Freescale DSPI controller" select REGMAP_MMIO - depends on HAS_DMA depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || COMPILE_TEST help This enables support for the Freescale DSPI controller in master @@ -450,7 +447,6 @@ config SPI_OMAP_UWIRE config SPI_OMAP24XX tristate "McSPI driver for OMAP" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || COMPILE_TEST select SG_SPLIT help @@ -459,7 +455,6 @@ config SPI_OMAP24XX config SPI_TI_QSPI tristate "DRA7xxx QSPI controller support" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || COMPILE_TEST help QSPI master controller for DRA7xxx used for flash devices. @@ -488,7 +483,6 @@ config SPI_PIC32 config SPI_PIC32_SQI tristate "Microchip PIC32 Quad SPI driver" depends on MACH_PIC32 || COMPILE_TEST - depends on HAS_DMA help SPI driver for PIC32 Quad SPI controller. @@ -591,7 +585,7 @@ config SPI_SC18IS602 config SPI_SH_MSIOF tristate "SuperH MSIOF SPI controller" - depends on HAVE_CLK && HAS_DMA + depends on HAVE_CLK depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST help SPI driver for SuperH and SH Mobile MSIOF blocks. @@ -669,7 +663,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 && HAS_DMA + depends on RESET_CONTROLLER help SPI driver for NVIDIA Tegra114 SPI Controller interface. This controller is different than the older SoCs SPI controller and also register interface @@ -687,7 +681,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 && HAS_DMA + depends on RESET_CONTROLLER help SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface. -- 2.7.4
[PATCH v2 02/21] ata: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- 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
[PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/mmc/host/Kconfig | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 620c2d90a646f387..f6d43348b4a3e5d4 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support" depends on ARCH_MESON || COMPILE_TEST depends on COMMON_CLK - depends on HAS_DMA depends on OF help This selects support for the SD/MMC Host Controller on @@ -401,7 +400,6 @@ config MMC_OMAP config MMC_OMAP_HS tristate "TI OMAP High Speed Multimedia Card Interface support" - depends on HAS_DMA depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST help This selects the TI OMAP High Speed Multimedia card Interface. @@ -511,7 +509,6 @@ config MMC_DAVINCI config MMC_GOLDFISH tristate "goldfish qemu Multimedia Card Interface support" - depends on HAS_DMA depends on GOLDFISH || COMPILE_TEST help This selects the Goldfish Multimedia card Interface emulation @@ -605,7 +602,7 @@ config MMC_SDHI config MMC_SDHI_SYS_DMAC tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC" - depends on MMC_SDHI && HAS_DMA + depends on MMC_SDHI default MMC_SDHI if (SUPERH || ARM) help This provides DMA support for SDHI SD/SDIO controllers @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC config MMC_SDHI_INTERNAL_DMAC tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering" depends on ARM64 || COMPILE_TEST - depends on MMC_SDHI && HAS_DMA + depends on MMC_SDHI default MMC_SDHI if ARM64 help This provides DMA support for SDHI SD/SDIO controllers @@ -688,7 +685,6 @@ config MMC_CAVIUM_THUNDERX config MMC_DW tristate "Synopsys DesignWare Memory Card Interface" - depends on HAS_DMA depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST help This selects support for the Synopsys DesignWare Mobile Storage IP @@ -758,7 +754,6 @@ config MMC_DW_ZX config MMC_SH_MMCIF tristate "SuperH Internal MMCIF support" - depends on HAS_DMA depends on SUPERH || ARCH_RENESAS || COMPILE_TEST help This selects the MMC Host Interface controller (MMCIF) found in various @@ -878,7 +873,6 @@ config MMC_TOSHIBA_PCI config MMC_BCM2835 tristate "Broadcom BCM2835 SDHOST MMC Controller support" depends on ARCH_BCM2835 || COMPILE_TEST - depends on HAS_DMA help This selects the BCM2835 SDHOST MMC controller. If you have a BCM2835 platform with SD or MMC devices, say Y or M here. -- 2.7.4
[PATCH v2 21/21] usb: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> [drivers/usb/gadget/] --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/usb/gadget/udc/Kconfig | 4 ++-- drivers/usb/mtu3/Kconfig | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig index 0875d38476ee9395..9c3b4f86965e80c7 100644 --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -179,7 +179,7 @@ config USB_R8A66597 config USB_RENESAS_USBHS_UDC tristate 'Renesas USBHS controller' - depends on USB_RENESAS_USBHS && HAS_DMA + depends on USB_RENESAS_USBHS help Renesas USBHS is a discrete USB host and peripheral controller chip that supports both full and high speed USB 2.0 data transfers. @@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC config USB_RENESAS_USB3 tristate 'Renesas USB3.0 Peripheral controller' depends on ARCH_RENESAS || COMPILE_TEST - depends on EXTCON && HAS_DMA + depends on EXTCON help Renesas USB3.0 Peripheral controller is a USB peripheral controller that supports super, high, and full speed USB 3.0 data transfers. diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig index 25cd61947beea51e..c0c0eb88e5eafc74 100644 --- a/drivers/usb/mtu3/Kconfig +++ b/drivers/usb/mtu3/Kconfig @@ -2,7 +2,7 @@ config USB_MTU3 tristate "MediaTek USB3 Dual Role controller" - depends on EXTCON && (USB || USB_GADGET) && HAS_DMA + depends on EXTCON && (USB || USB_GADGET) depends on ARCH_MEDIATEK || COMPILE_TEST select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD help -- 2.7.4
[PATCH v2 20/21] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/staging/vc04_services/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/vc04_services/Kconfig b/drivers/staging/vc04_services/Kconfig index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644 --- a/drivers/staging/vc04_services/Kconfig +++ b/drivers/staging/vc04_services/Kconfig @@ -1,6 +1,5 @@ menuconfig BCM_VIDEOCORE tristate "Broadcom VideoCore support" - depends on HAS_DMA depends on OF depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE) default y -- 2.7.4
[PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/tty/serial/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 3682fd3e960cbd64..a0ea146a2ef5af53 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -115,7 +115,6 @@ config SERIAL_SB1250_DUART_CONSOLE config SERIAL_ATMEL bool "AT91 on-chip serial port support" - depends on HAS_DMA depends on ARCH_AT91 || COMPILE_TEST select SERIAL_CORE select SERIAL_MCTRL_GPIO if GPIOLIB @@ -586,7 +585,6 @@ config BFIN_UART3_CTSRTS config SERIAL_IMX tristate "IMX serial port support" - depends on HAS_DMA depends on ARCH_MXC || COMPILE_TEST select SERIAL_CORE select RATIONAL @@ -1436,7 +1434,6 @@ config SERIAL_PCH_UART_CONSOLE config SERIAL_MXS_AUART tristate "MXS AUART support" - depends on HAS_DMA depends on ARCH_MXS || MACH_ASM9260 || COMPILE_TEST select SERIAL_CORE select SERIAL_MCTRL_GPIO if GPIOLIB @@ -1656,7 +1653,6 @@ config SERIAL_SPRD_CONSOLE config SERIAL_STM32 tristate "STMicroelectronics STM32 serial port support" select SERIAL_CORE - depends on HAS_DMA depends on ARCH_STM32 || COMPILE_TEST help This driver is for the on-chip Serial Controller on -- 2.7.4
[PATCH v2 15/21] net: Remove depends on HAS_DMA in case of platform dependency
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. Note: - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(). set_dma_ops() does not exist if NO_DMA=y, and its use in this driver is questionable. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- 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 +- 12 files changed, 12 insertions(+), 19 deletions(-) diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig index d5c15e8bb3de706b..f273af136fc7c995 100644 --- a/drivers/net/ethernet/amd/Kconfig +++ b/drivers/net/ethernet/amd/Kconfig @@ -173,7 +173,7 @@ config SUNLANCE config AMD_XGBE tristate "AMD 10GbE Ethernet driver" - depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && HAS_DMA + depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM depends on X86 || ARM64 || COMPILE_TEST select BITREVERSE select CRC32 diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig b/drivers/net/ethernet/apm/xgene-v2/Kconfig index 1205861b631896a0..eedd3f3dd22e2201 100644 --- a/drivers/net/ethernet/apm/xgene-v2/Kconfig +++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig @@ -1,6 +1,5 @@ config NET_XGENE_V2 tristate "APM X-Gene SoC Ethernet-v2 Driver" - depends on HAS_DMA depends on ARCH_XGENE || COMPILE_TEST help This is the Ethernet driver for the on-chip ethernet interface diff --git a/drivers/net/ethernet/apm/xgene/Kconfig b/drivers/net/ethernet/apm/xgene/Kconfig index afccb033177b3923..e4e33c900b577161 100644 --- a/drivers/net/ethernet/apm/xgene/Kconfig +++ b/drivers/net/ethernet/apm/xgene/Kconfig @@ -1,6 +1,5 @@ config NET_XGENE tristate "APM X-Gene SoC Ethernet Driver" - depends on HAS_DMA depends on ARCH_XGENE || COMPILE_TEST select PHYLIB select MDIO_XGENE diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig index e743ddf46343302f..5d0ab8e74b680cc6 100644 --- a/drivers/net/ethernet/arc/Kconfig +++ b/drivers/net/ethernet/arc/Kconfig @@ -24,7 +24,8 @@ config ARC_EMAC_CORE config ARC_EMAC tristate "ARC EMAC support" select ARC_EMAC_CORE - depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST) + depends on OF_IRQ && OF_NET + depends on ARC || COMPILE_TEST ---help--- On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x non-standard on-chip ethernet device ARC EMAC 10/100 is used. @@ -33,7 +34,8 @@ config ARC_EMAC config EMAC_ROCKCHIP tristate "Rockchip EMAC support" select ARC_EMAC_CORE - depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP || COMPILE_TEST) + depends on OF_IRQ && OF_NET && REGULATOR + depends on ARCH_ROCKCHIP || COMPILE_TEST ---help--- Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers. This selects Rockchip SoC glue layer support for the diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig index af75156919edfead..4c3bfde6e8de00f2 100644 --- a/drivers/net/ethernet/broadcom/Kconfig +++ b/drivers/net/ethernet/broadcom/Kconfig @@ -157,7 +157,6 @@ config BGMAC config BGMAC_BCMA tristate "Broadcom iProc GBit BCMA support" depends on BCMA && BCMA_HOST_SOC - depends on HAS_DMA depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST select BGMAC select PHYLIB @@ -170,7 +169,6 @@ config BGMAC_BCMA config BGMAC_PL
[PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA, - Split per subsystem. --- drivers/mtd/nand/Kconfig| 8 ++-- drivers/mtd/spi-nor/Kconfig | 2 +- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 736ac887303c88ba..55a2f8a2fa90cd87 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -46,7 +46,7 @@ config MTD_NAND_DENALI config MTD_NAND_DENALI_PCI tristate "Support Denali NAND controller on Intel Moorestown" select MTD_NAND_DENALI - depends on HAS_DMA && PCI + depends on PCI help Enable the driver for NAND flash on Intel Moorestown, using the Denali NAND controller core. @@ -184,7 +184,6 @@ config MTD_NAND_S3C2410_CLKSTOP config MTD_NAND_TANGO tristate "NAND Flash support for Tango chips" depends on ARCH_TANGO || COMPILE_TEST - depends on HAS_DMA help Enables the NAND Flash controller on Tango chips. @@ -328,7 +327,7 @@ config MTD_NAND_MARVELL tristate "NAND controller support on Marvell boards" depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \ COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM help This enables the NAND flash controller driver for Marvell boards, including: @@ -490,7 +489,6 @@ config MTD_NAND_SH_FLCTL tristate "Support for NAND on Renesas SuperH FLCTL" depends on SUPERH || COMPILE_TEST depends on HAS_IOMEM - depends on HAS_DMA help Several Renesas SuperH CPU has FLCTL. This option enables support for NAND Flash using FLCTL. @@ -558,7 +556,6 @@ config MTD_NAND_SUNXI config MTD_NAND_HISI504 tristate "Support for NAND controller on Hisilicon SoC Hip04" depends on ARCH_HISI || COMPILE_TEST - depends on HAS_DMA help Enables support for NAND controller on Hisilicon SoC Hip04. @@ -572,7 +569,6 @@ config MTD_NAND_QCOM config MTD_NAND_MTK tristate "Support for NAND controller on MTK SoCs" depends on ARCH_MEDIATEK || COMPILE_TEST - depends on HAS_DMA help Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 89da88e591215db1..c493b8230a38c059 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI config SPI_HISI_SFC tristate "Hisilicon SPI-NOR Flash Controller(SFC)" depends on ARCH_HISI || COMPILE_TEST - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM help This enables support for hisilicon SPI-NOR flash controller. -- 2.7.4
[PATCH v2 11/21] mailbox: Remove depends on HAS_DMA in case of platform dependency
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. Notes: - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(), which does not exist if HAS_DMA=n (Do we need a dummy? The use of set_dma_ops() in this driver is questionable), - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their dependency on HAS_DMA, as they are selected from SND_SOC_APQ8016_SBC. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/mailbox/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index ba2f1525f4eef454..f3c68fe15180d035 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -154,7 +154,6 @@ config XGENE_SLIMPRO_MBOX config BCM_PDC_MBOX tristate "Broadcom FlexSparx DMA Mailbox" depends on ARCH_BCM_IPROC || COMPILE_TEST - depends on HAS_DMA help Mailbox implementation for the Broadcom FlexSparx DMA ring manager, which provides access to various offload engines on Broadcom @@ -164,7 +163,6 @@ config BCM_FLEXRM_MBOX tristate "Broadcom FlexRM Mailbox" depends on ARM64 depends on ARCH_BCM_IPROC || COMPILE_TEST - depends on HAS_DMA select GENERIC_MSI_IRQ_DOMAIN default m if ARCH_BCM_IPROC help -- 2.7.4
[PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- 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
[PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency
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 <ge...@linux-m68k.org> Reviewed-by: Mark Brown <broo...@kernel.org> Acked-by: Robin Murphy <robin.mur...@arm.com> --- v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/fpga/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index f47ef848bcd056d5..fd539132542e30ee 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP config FPGA_MGR_ZYNQ_FPGA tristate "Xilinx Zynq FPGA" depends on ARCH_ZYNQ || COMPILE_TEST - depends on HAS_DMA help FPGA manager driver support for Xilinx Zynq FPGAs. -- 2.7.4
Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures
On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> wrote: > The use of the packed attribute can cause a performance penalty for > all accesses to the struct members, as the compiler will assume that the > structure has the potential to have an unaligned base. > > These structures are all correctly aligned and contain no holes, thus > the attribute is redundant and negatively impacts performance, so we > remove the attributes entirely. > > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] dt-bindings: media: rcar_vin: Use status "okay"
According to the Devicetree Specification, "ok" is not a valid status. Fixes: 47c71bd61b772cd7 ("[media] rcar_vin: add devicetree support") Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- For the checkpatch TODO list? https://www.devicetree.org/ Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 68c5c497b7fa5551..a19517e1c669eb35 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -81,7 +81,7 @@ Board setup example for Gen2 platforms (vin1 composite video input) --- { -status = "ok"; +status = "okay"; pinctrl-0 = <_pins>; pinctrl-names = "default"; @@ -104,7 +104,7 @@ Board setup example for Gen2 platforms (vin1 composite video input) pinctrl-0 = <_pins>; pinctrl-names = "default"; -status = "ok"; +status = "okay"; port { #address-cells = <1>; -- 2.7.4
Re: [PATCH v2] i2c: adv748x: afe: fix sparse warning
On Thu, Mar 8, 2018 at 12:02 AM, Niklas Söderlund <niklas.soderl...@ragnatech.se> wrote: > CC linux-media. > > It's linux-media@vger.kernel.org not linux-me...@vger.kernel.or, sorry > for the noise. > > On 2018-03-07 23:58:16 +0100, Niklas Söderlund wrote: >> This fixes the following sparse warning: >> >> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:expected unsigned int >> [usertype] *signal >> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:got int * >> drivers/media/i2c/adv748x/adv748x-afe.c:294:34: warning: incorrect type in >> argument 2 (different signedness) >> >> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] media: platform: Drop OF dependency of VIDEO_RENESAS_VSP1
VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF. As ARCH_RENESAS implies OF, the latter can be dropped. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 614fbef08ddcabb0..2b8b1ad0edd9eb31 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -448,7 +448,7 @@ config VIDEO_RENESAS_FCP config VIDEO_RENESAS_VSP1 tristate "Renesas VSP1 Video Processing Engine" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA - depends on (ARCH_RENESAS && OF) || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP select VIDEOBUF2_DMA_CONTIG select VIDEOBUF2_VMALLOC -- 2.7.4
Re: [PATCH] i2c: adv748x: afe: fix sparse warning
Hi Niklas, On Thu, Feb 22, 2018 at 12:21 AM, Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> wrote: > This fixes the following sparse warning: > > drivers/media/i2c/adv748x/adv748x-afe.c:294:34:expected unsigned int > [usertype] *signal > drivers/media/i2c/adv748x/adv748x-afe.c:294:34:got int * > drivers/media/i2c/adv748x/adv748x-afe.c:294:34: warning: incorrect type in > argument 2 (different signedness) > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > --- > drivers/media/i2c/adv748x/adv748x-afe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c > b/drivers/media/i2c/adv748x/adv748x-afe.c > index 5188178588c9067d..39a9996d0db08c31 100644 > --- a/drivers/media/i2c/adv748x/adv748x-afe.c > +++ b/drivers/media/i2c/adv748x/adv748x-afe.c > @@ -275,7 +275,8 @@ static int adv748x_afe_s_stream(struct v4l2_subdev *sd, > int enable) > { > struct adv748x_afe *afe = adv748x_sd_to_afe(sd); > struct adv748x_state *state = adv748x_afe_to_state(afe); > - int ret, signal = V4L2_IN_ST_NO_SIGNAL; > + unsigned int signal = V4L2_IN_ST_NO_SIGNAL; u32, as adv748x_afe_status() takes an u32 signal pointer? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/5] auxdisplay: charlcd: no need to call charlcd_gotoxy() if nothing changes
On Mon, Feb 12, 2018 at 2:42 PM, Miguel Ojeda <miguel.ojeda.sando...@gmail.com> wrote: > On Mon, Jan 15, 2018 at 10:58 AM, Sean Young <s...@mess.org> wrote: >> If the line extends beyond the width to the screen, nothing changes. The >> existing code will call charlcd_gotoxy every time for this case. >> >> Signed-off-by: Sean Young <s...@mess.org> >> --- >> drivers/auxdisplay/charlcd.c | 7 --- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c >> index 642afd88870b..45ec5ce697c4 100644 >> --- a/drivers/auxdisplay/charlcd.c >> +++ b/drivers/auxdisplay/charlcd.c >> @@ -192,10 +192,11 @@ static void charlcd_print(struct charlcd *lcd, char c) >> c = lcd->char_conv[(unsigned char)c]; >> lcd->ops->write_data(lcd, c); >> priv->addr.x++; >> + >> + /* prevents the cursor from wrapping onto the next line */ >> + if (priv->addr.x == lcd->bwidth) >> + charlcd_gotoxy(lcd); >> } >> - /* prevents the cursor from wrapping onto the next line */ >> - if (priv->addr.x == lcd->bwidth) >> - charlcd_gotoxy(lcd); >> } >> > > Willy, Geert: is this fine with you? Seems fine: charlcd_write_char() > right now does an unconditional write_cmd() when writing a normal > character; so unless some HW requires the command for some reason even > if there is nothing changed, we can skip it. Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 0/4] tree-wide: fix comparison to bitshift when dealing with a mask
Hi Wolfram, On Mon, Feb 5, 2018 at 9:09 PM, Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > In one Renesas driver, I found a typo which turned an intended bit shift > ('<<') > into a comparison ('<'). Because this is a subtle issue, I looked tree wide > for > similar patterns. This small patch series is the outcome. > > Buildbot and checkpatch are happy. Only compile-tested. To be applied > individually per sub-system, I think. I'd think only the net: amd: patch needs > to be conisdered for stable, but I leave this to people who actually know this > driver. > > CCing Dan. Maybe he has an idea how to add a test to smatch? In my setup, only > cppcheck reported a 'coding style' issue with a low prio. I found two more using "git grep 'define.*0x[0-9a-f]* < '": drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < RXFC_FWM_SHIFT) drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n) (0x00100 < (n)) /* 0 < n < 4 */ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v7 00/11] Renesas Capture Engine Unit (CEU) V4L2 driver
Hi Jacopo, On Fri, Jan 26, 2018 at 2:54 PM, jacopo mondi <jac...@jmondi.org> wrote: > UUUPS > > please ignore this submission as it contains patches from a previous > version (you may have noticed some patches in the series reports > [xx/09] in the subject). > > I will resend. Good. So there's still time to fix e.g. "RZ/A1-H" to "RZ/A1H" (same for M and L). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: clk: Relax clk rate match test
Hi Jacopo, On Thu, Jan 25, 2018 at 3:14 PM, jacopo mondi <jac...@jmondi.org> wrote: > On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote: >> CC linux-clk (yes I know this is about the legacy SH clock framework, but >> the public API is/should be the same) >> >> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi >> <jacopo+rene...@jmondi.org> wrote: >> > When asking for a clk rate to be set, the sh core clock matches only >> > exact rate values against the calculated frequency table entries. If the >> > rate does not match exactly the test fails, and the whole frequency >> > table is walked, resulting in selection of the last entry, corresponding to >> > the lowest available clock rate. >> >> IIUIC, the code does not select the last entry, but returns an error code, >> which is propagated all the way up? >> >> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" >> > line), >> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is >> > actually set to 5201920 Hz, which is the last available entry of the >> > frequencies >> > table. >> >> Perhaps 5201920 is just the default (or old value)? >> >> > Relax the clock frequency match test, allowing selection of clock rates >> > immediately slower than the required one. >> > >> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> >> > >> > --- >> > Hello renesas lists, >> > >> > I'm now working on handling frame rate for the ov7720 image sensor to have >> > that >> > driver accepted as part of v4l2. The sensor is installed on on Migo-R >> > board. >> > In order to properly calculate pixel clock and the framerate I noticed the >> > clock signal fed to the sensor from the SH7722 chip was always the lowest >> > available one. >> > >> > This patch fixes the issues and allows me to properly select which clock >> > frequency supply to the sensor, which according to datasheet does not >> > support >> > input clock frequencies slower than 10MHz (but works anyhow). >> > >> > As all patches for SH architecture I wonder where they should be picked up >> > from, >> > as SH seems not maintained at the moment. >> > >> > Thanks >> >j >> > >> > --- >> > drivers/sh/clk/core.c | 9 ++--- >> > 1 file changed, 6 insertions(+), 3 deletions(-) >> > >> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c >> > index 92863e3..d2cb94c 100644 >> > --- a/drivers/sh/clk/core.c >> > +++ b/drivers/sh/clk/core.c >> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk, >> > { >> > struct cpufreq_frequency_table *pos; >> > >> > - cpufreq_for_each_valid_entry(pos, freq_table) >> > - if (pos->frequency == rate) >> > - return pos - freq_table; >> > + cpufreq_for_each_valid_entry(pos, freq_table) { >> > + if (pos->frequency > rate) >> > + continue; >> >> This assumes all frequency tables are sorted. >> >> Shouldn't you pick the closest frequency? >> >> However, that's what clk_rate_table_round() does, which is called from >> sh_clk_div_round_rate(), and thus already used as .round_rate: >> >> static struct sh_clk_ops sh_clk_div_enable_clk_ops = { >> .recalc = sh_clk_div_recalc, >> .set_rate = sh_clk_div_set_rate, >> .round_rate = sh_clk_div_round_rate, >> .enable = sh_clk_div_enable, >> .disable= sh_clk_div_disable, >> }; > > Does this implies clock rates should be set using clk_round_rate() and > not clk_set_rate() if I understand this right? Not necessarily... Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate() in the CCF implementation for DIV6 clocks use rounding. >> (clk_rate_table_find() is called from sh_clk_div_set_rate()) >> >> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz >> come from? > > From board initialization code, in order to provide a valid input > clock to OV7720 sensor. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: clk: Relax clk rate match test
Hi Jacopo, CC linux-clk (yes I know this is about the legacy SH clock framework, but the public API is/should be the same) On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > When asking for a clk rate to be set, the sh core clock matches only > exact rate values against the calculated frequency table entries. If the > rate does not match exactly the test fails, and the whole frequency > table is walked, resulting in selection of the last entry, corresponding to > the lowest available clock rate. IIUIC, the code does not select the last entry, but returns an error code, which is propagated all the way up? > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line), > the calculated clock frequency 10088572 Hz gets ignored, and the clock is > actually set to 5201920 Hz, which is the last available entry of the > frequencies > table. Perhaps 5201920 is just the default (or old value)? > Relax the clock frequency match test, allowing selection of clock rates > immediately slower than the required one. > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > > --- > Hello renesas lists, > > I'm now working on handling frame rate for the ov7720 image sensor to have > that > driver accepted as part of v4l2. The sensor is installed on on Migo-R board. > In order to properly calculate pixel clock and the framerate I noticed the > clock signal fed to the sensor from the SH7722 chip was always the lowest > available one. > > This patch fixes the issues and allows me to properly select which clock > frequency supply to the sensor, which according to datasheet does not support > input clock frequencies slower than 10MHz (but works anyhow). > > As all patches for SH architecture I wonder where they should be picked up > from, > as SH seems not maintained at the moment. > > Thanks >j > > --- > drivers/sh/clk/core.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c > index 92863e3..d2cb94c 100644 > --- a/drivers/sh/clk/core.c > +++ b/drivers/sh/clk/core.c > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk, > { > struct cpufreq_frequency_table *pos; > > - cpufreq_for_each_valid_entry(pos, freq_table) > - if (pos->frequency == rate) > - return pos - freq_table; > + cpufreq_for_each_valid_entry(pos, freq_table) { > + if (pos->frequency > rate) > + continue; This assumes all frequency tables are sorted. Shouldn't you pick the closest frequency? However, that's what clk_rate_table_round() does, which is called from sh_clk_div_round_rate(), and thus already used as .round_rate: static struct sh_clk_ops sh_clk_div_enable_clk_ops = { .recalc = sh_clk_div_recalc, .set_rate = sh_clk_div_set_rate, .round_rate = sh_clk_div_round_rate, .enable = sh_clk_div_enable, .disable= sh_clk_div_disable, }; (clk_rate_table_find() is called from sh_clk_div_set_rate()) Or are you supposed to ask for the exact clock rate? Where does the 10 MHz come from? > + > + return pos - freq_table; > + } > > return -ENOENT; > } Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()
Hi Niklas, On Thu, Jan 25, 2018 at 1:34 AM, Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> wrote: > A recent change to the media_entity_to_video_device() macro breaks some > use-cases for the macro due to a symbol collision. Before the change > this worked: > > vdev = media_entity_to_video_device(link->sink->entity); > > While after the change it results in a compiler error "error: 'struct > video_device' has no member named 'link'; did you mean 'lock'?". While > the following still works after the change. > > struct media_entity *entity = link->sink->entity; > vdev = media_entity_to_video_device(entity); > > Fix the collision by renaming the macro argument to 'media_entity'. Thanks! Given there also exists a "struct media_entity", using "_media_entity" seems safe to me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -next] media: rcar_drif: fix error return code in rcar_drif_alloc_dmachannels()
On Wed, Jan 17, 2018 at 12:24 PM, Wei Yongjun <weiyongj...@huawei.com> wrote: > Fix to return error code -ENODEV from the dma_request_slave_channel() > error handling case instead of 0, as done elsewhere in this function. > rc can be overwrite to 0 by dmaengine_slave_config() in the for loop. > > Signed-off-by: Wei Yongjun <weiyongj...@huawei.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] v4l: async: Protect against double notifier registrations
Hi Kieran, On Wed, Jan 17, 2018 at 12:47 AM, Kieran Bingham <kieran.bing...@ideasonboard.com> wrote: > From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> > > It can be easy to attempt to register the same notifier twice > in mis-handled error cases such as working with -EPROBE_DEFER. > > This results in odd kernel crashes where the notifier_list becomes > corrupted due to adding the same entry twice. > > Protect against this so that a developer has some sense of the pending > failure, and use a WARN_ON to identify the fault. > > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> Thanks for your patch! However, I have several comments: 1. Instead of walking notifier_list (O(n)), can't you just check if notifier.list is part of a list or not (O(1))? 2. Isn't notifier usually (always?) allocated dynamically, so if will be a different pointer after a previous -EPROBE_DEFER anyway? 3. If you enable CONFIG_DEBUG_LIST, it should scream, too. > --- a/drivers/media/v4l2-core/v4l2-async.c > +++ b/drivers/media/v4l2-core/v4l2-async.c > @@ -374,17 +374,26 @@ static int __v4l2_async_notifier_register(struct > v4l2_async_notifier *notifier) > struct device *dev = > notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL; > struct v4l2_async_subdev *asd; > + struct v4l2_async_notifier *n; > int ret; > int i; > > if (notifier->num_subdevs > V4L2_MAX_SUBDEVS) > return -EINVAL; > > + mutex_lock(_lock); > + > + /* Avoid re-registering a notifier. */ > + list_for_each_entry(n, _list, list) { > + if (WARN_ON(n == notifier)) { > + ret = -EEXIST; > + goto err_unlock; > + } > + } > + > INIT_LIST_HEAD(>waiting); > INIT_LIST_HEAD(>done); > > - mutex_lock(_lock); > - > for (i = 0; i < notifier->num_subdevs; i++) { > asd = notifier->subdevs[i]; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v4 3/9] v4l: platform: Add Renesas CEU driver
Hi Laurent, On Fri, Jan 12, 2018 at 12:12 AM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Tuesday, 9 January 2018 18:25:25 EET Jacopo Mondi wrote: >> Add driver for Renesas Capture Engine Unit (CEU). >> >> The CEU interface supports capturing 'data' (YUV422) and 'images' >> (NV[12|21|16|61]). >> >> This driver aims to replace the soc_camera-based sh_mobile_ceu one. >> >> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ >> platform GR-Peach. >> >> Tested with ov7725 camera sensor on SH4 platform Migo-R. >> >> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> >> --- >> drivers/media/platform/Kconfig |9 + >> drivers/media/platform/Makefile |1 + >> drivers/media/platform/renesas-ceu.c | 1648 >> ++ 3 files changed, 1658 insertions(+) >> create mode 100644 drivers/media/platform/renesas-ceu.c > > [snip] > >> diff --git a/drivers/media/platform/renesas-ceu.c >> b/drivers/media/platform/renesas-ceu.c new file mode 100644 >> index 000..d261704 >> --- /dev/null >> +++ b/drivers/media/platform/renesas-ceu.c >> @@ -0,0 +1,1648 @@ >> +// SPDX-License-Identifier: GPL-2.0 > > It was recently brought to my attention that SPDX headers should use either > GPL-2.0-only or GPL-2.0-or-later, no the ambiguous GPL-2.0. Could you please > update all patches in this series ? IMHO it's a bit premature to do that. As long as Documentation/process/license-rules.rst isn't updated, I wouldn't follow this change. See also https://www.spinics.net/lists/linux-xfs/msg14536.html Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 1/9] dt-bindings: media: Add Renesas CEU bindings
On Thu, Jan 4, 2018 at 11:28 PM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Thursday, 4 January 2018 18:03:09 EET Jacopo Mondi wrote: >> Add bindings documentation for Renesas Capture Engine Unit (CEU). >> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt >> @@ -0,0 +1,85 @@ >> +Renesas Capture Engine Unit (CEU) >> +-- >> + >> +The Capture Engine Unit is the image capture interface found in the Renesas >> +SH Mobile and RZ SoCs. >> + >> +The interface supports a single parallel input with data bus width of 8 or >> 16 >> +bits. >> + >> +Required properties: >> +- compatible: Must be one of the following. >> + - "renesas,r7s72100-ceu" for CEU units found in R7S72100 (RZ/A1) SoCs. >> + - "renesas,ceu" as a generic fallback. > > As asked in my review of patch 3/9, what's your policy for compatible strings > ? As far as I understand there's no generic CEU, as the SH4 and RZ versions > are not compatible. Should the "renesas,ceu" compatible string then be > replaced by "renesas,rz-ceu" ? If they're not compatible, it indeed doesn't make much sense to have a generic "renesas,ceu". Note that anything with "rz-" is a bad idea, as after RZ/A1, Renesas introduced RZ/G1, RZ/N1, and RZ/T1, which are completely different (yes I know we have a few of these in use, unfortunately). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
Hi Jacopo, On Thu, Dec 28, 2017 at 3:01 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Add Capture Engine Unit (CEU) node to device tree. Thanks for your patch! > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> With the issue below fixed: Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- a/arch/arm/boot/dts/r7s72100.dtsi > +++ b/arch/arm/boot/dts/r7s72100.dtsi > @@ -667,4 +667,13 @@ > power-domains = <_clocks>; > status = "disabled"; > }; > + > + ceu: ceu@e821 { > + reg = <0xe821 0x209c>; Given the last documented register is at offset 0x209C, the region above is too small (also in the example in the DT bindings). But due to MMU granularity, it will be accessible anyway. reg = <0xe821 0x3000>; I assume the mandatory "remote-endpoint" property will come with the board (GR-Peach) DTS patch? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/9] dt-bindings: media: Add Renesas CEU bindings
Hi Jacopo, On Thu, Dec 28, 2017 at 3:01 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Add bindings documentation for Renesas Capture Engine Unit (CEU). Thanks for your patch! > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt > @@ -0,0 +1,85 @@ > +Renesas Capture Engine Unit (CEU) > +-- > + > +The Capture Engine Unit is the image capture interface found on Renesas > +RZ chip series and on SH Mobile ones. > + > +The interface supports a single parallel input with data bus width up to > +8/16 bits. > + > +Required properties: > +- compatible > + Must be one of: > + - "renesas,ceu" Isn't "renesas,ceu" the generic fallback? > + - "renesas,r7s72100-ceu" > +- reg > + Physical address base and size. > +- interrupts > + The interrupt specifier. > +- pinctrl-names, pinctrl-0 > + phandle of pin controller sub-node configuring pins for CEU > operations. > +- remote-endpoint > + phandle to an 'endpoint' subnode of a remote device node. "remote-endpoint" is not a direct property, but must be part of nested "ports" and "endpoint" subnodes, like in the example? > +Example: > + > +The example describes the connection between the Capture Engine Unit and an > +OV7670 image sensor sitting on bus i2c1. > + > +ceu: ceu@e821 { > + reg = <0xe821 0x209c>; > + compatible = "renesas,ceu"; > + interrupts = ; > + > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + > + status = "okay"; > + > + port { > + ceu_in: endpoint { > + remote-endpoint = <_out>; > + > + hsync-active = <1>; > + vsync-active = <0>; > + }; > + }; > +}; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: [GIT PULL for v4.15-rc3] media fixes
Hi Mauro, On Wed, Dec 13, 2017 at 12:53 PM, Mauro Carvalho Chehab <mche...@osg.samsung.com> wrote: > Em Wed, 13 Dec 2017 10:03:56 +0100 > Geert Uytterhoeven <ge...@linux-m68k.org> escreveu: >> On Mon, Dec 11, 2017 at 12:12 PM, Mauro Carvalho Chehab >> <mche...@osg.samsung.com> wrote: >> > Without this series, I was getting 809 lines of bogus warnings (see below), >> > with was preventing me to see new warnings on my incremental builds >> > while applying new patches at the media tree. >> >> $ linux-log-diff build.log{.old,} >> >> (from https://github.com/geertu/linux-scripts) > > That's nice! > > Yet, it is producing some noise. I did a clean build with: > > $ make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 > CHECK='' M=drivers/staging/media | grep -v -e " CC " -e " LD " -e " AR " -e " > CHK " -e " CALL " -e " UPD " -e "scripts/kconfig/conf " -e " CHECK " >old.log > $ make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 > CHECK='' M=drivers/media| grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e > " CALL " -e " UPD " -e "scripts/kconfig/conf " -e " CHECK " >>old.log > > and added a new uninitialized "foo" var to a random driver, doing an > incremental build with: > > $ make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 > CHECK='' | grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e " CALL " -e " > UPD " -e "scripts/kconfig/conf " -e " CHECK " M=drivers/staging/media >new.log > $ make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 > CHECK='' | grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e " CALL " -e " > UPD " -e "scripts/kconfig/conf " -e " CHECK " M=drivers/media >new.log > > Then, I ran the script: > > $ linux-log-diff old.log new.log > > *** ERRORS *** > > > *** WARNINGS *** > > 1 warning regressions: > + drivers/media/dvb-frontends/dibx000_common.c: warning: unused variable > 'foo' [-Wunused-variable]: => 22:5 > > 3 warning improvements: > - ./arch/x86/include/asm/bitops.h: warning: asm output is not an lvalue: > 430:22 => > - > drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h: > warning: function 'mmu_reg_load' with external linkage has definition: 35:30 > => > - > drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h: > warning: function 'mmu_reg_store' with external linkage has definition: > 24:26 => > > It detected the "foo" var warning, but it outputs 3 warning improvements > on files that were not even built the second time. If the file wasn't built, the warning cannot be in the log ;-) So yes, it works best for full builds, only flagging warnings that (dis)appeared (and ignoring changes due to changed line numbers!). If you do lots of incremental builds, you want to append the last incremental log to the existing full log before doing a new build, to avoid false positives from files that weren't built in the previous run: $ cat new.log >> old.log $ make ... > new.log $ linux-log-diff old.log new.log And only new warnings should be reported. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: [GIT PULL for v4.15-rc3] media fixes
Hi Mauro, On Mon, Dec 11, 2017 at 12:12 PM, Mauro Carvalho Chehab <mche...@osg.samsung.com> wrote: > Without this series, I was getting 809 lines of bogus warnings (see below), > with was preventing me to see new warnings on my incremental builds > while applying new patches at the media tree. $ linux-log-diff build.log{.old,} (from https://github.com/geertu/linux-scripts) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v4 0/9] vsp1: TLB optimisation and DL caching
Hi Kieran, On Fri, Nov 17, 2017 at 4:47 PM, Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> wrote: > Each display list currently allocates an area of DMA memory to store register > settings for the VSP1 to process. Each of these allocations adds pressure to > the IPMMU TLB entries. > > We can reduce the pressure by pre-allocating larger areas and dividing the > area > across multiple bodies represented as a pool. > > With this reconfiguration of bodies, we can adapt the configuration code to > separate out constant hardware configuration and cache it for re-use. > > -- > > The patches provided in this series can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git > tags/vsp1/tlb-optimise/v4 This started to conflict with commit dd286a531461748f ("v4l: vsp1: Start and stop DRM pipeline independently of planes"), causing build failures as it changes the signature of vsp1_entity_route_setup(), and removed several VSP1_ENTITY_PARAMS_* definitions. After fixing those, it hangs after: [drm] No driver support for vblank timestamp query. So I dropped the above for today's release. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] media: i2c: adv748x: Restore full DT paths in kernel messages
As of_node_full_name() now returns only the basename, the endpoint information printed became useless: adv748x 4-0070: Endpoint endpoint on port 7 adv748x 4-0070: Endpoint endpoint on port 8 adv748x 4-0070: Endpoint endpoint on port 10 adv748x 4-0070: Endpoint endpoint on port 11 Restore the old behavior by using "%pOF" instead: adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7 adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8 adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@10/endpoint on port 10 adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@11/endpoint on port 11 Fixes: a7e4cfb0a7ca4773 ("of/fdt: only store the device node basename in full_name") Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/media/i2c/adv748x/adv748x-core.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/media/i2c/adv748x/adv748x-core.c b/drivers/media/i2c/adv748x/adv748x-core.c index 5ee14f2c27478e3a..c1001db6a172e256 100644 --- a/drivers/media/i2c/adv748x/adv748x-core.c +++ b/drivers/media/i2c/adv748x/adv748x-core.c @@ -646,14 +646,12 @@ static int adv748x_parse_dt(struct adv748x_state *state) for_each_endpoint_of_node(state->dev->of_node, ep_np) { of_graph_parse_endpoint(ep_np, ); - adv_info(state, "Endpoint %s on port %d", - of_node_full_name(ep.local_node), - ep.port); + adv_info(state, "Endpoint %pOF on port %d", ep.local_node, +ep.port); if (ep.port >= ADV748X_PORT_MAX) { - adv_err(state, "Invalid endpoint %s on port %d", - of_node_full_name(ep.local_node), - ep.port); + adv_err(state, "Invalid endpoint %pOF on port %d", + ep.local_node, ep.port); continue; } -- 2.7.4
Re: [PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
Hi Jacopo, On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Add Capture Engine Unit (CEU) node to device tree. > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> Thanks for your patch! > --- a/arch/arm/boot/dts/r7s72100.dtsi > +++ b/arch/arm/boot/dts/r7s72100.dtsi > @@ -136,8 +136,8 @@ > compatible = "renesas,r7s72100-mstp-clocks", > "renesas,cpg-mstp-clocks"; > reg = <0xfcfe042c 4>; > clocks = <_clk>; You forgot to add an entry to clocks. The parent clock of the CEU module clock is b_clk. > - clock-indices = ; > - clock-output-names = "rtc"; > + clock-indices = ; > + clock-output-names = "rtc", "ceu"; Usually we follow the order from , so CEU should come before RTC. > @@ -666,4 +666,12 @@ > power-domains = <_clocks>; > status = "disabled"; > }; > + > + ceu: ceu@e821 { > + reg = <0xe821 0x209c>; > + compatible = "renesas,renesas-ceu"; > + interrupts = ; > + power-domains = <_clocks>; if you describe the device to be part of the CPG clock domain, you should provide a clocks property: clocks = <_clks R7S72100_CLK_CEU>; > + status = "disabled"; > + }; > }; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro <fabrizio.cas...@bp.renesas.com> wrote: > Change the sorting of the part numbers from descending to ascending to > match with other documentation. > > Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com> > Reviewed-by: Biju Das <biju@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro <fabrizio.cas...@bp.renesas.com> wrote: > Add compatible strings for r8a7743 and r8a7745. No driver change > is needed as "renesas,rcar-gen2-vin" will activate the right code. > However, it is good practice to document compatible strings for the > specific SoC as this allows SoC specific changes to the driver if > needed, in addition to document SoC support and therefore allow > checkpatch.pl to validate compatible string values. > > Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com> > Reviewed-by: Biju Das <biju....@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] [media] c8sectpfe: DVB_C8SECTPFE should depend on HAS_DMA
If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/media/platform/sti/c8sectpfe/c8sectpfe.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> --- drivers/media/platform/sti/c8sectpfe/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/sti/c8sectpfe/Kconfig b/drivers/media/platform/sti/c8sectpfe/Kconfig index 7420a50572d347ef..740190f8a3b606d3 100644 --- a/drivers/media/platform/sti/c8sectpfe/Kconfig +++ b/drivers/media/platform/sti/c8sectpfe/Kconfig @@ -1,6 +1,6 @@ config DVB_C8SECTPFE tristate "STMicroelectronics C8SECTPFE DVB support" - depends on PINCTRL && DVB_CORE && I2C + depends on PINCTRL && DVB_CORE && I2C && HAS_DMA depends on ARCH_STI || ARCH_MULTIPLATFORM || COMPILE_TEST select FW_LOADER select DEBUG_FS -- 2.7.4
Re: [PATCH 1/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
Hi Fabrizio, On Thu, Nov 16, 2017 at 2:45 PM, Fabrizio Castro <fabrizio.cas...@bp.renesas.com> wrote: >> Subject: Re: [PATCH 1/2] dt-bindings: media: rcar_vin: add device tree >> support for r8a774[35] >> >> On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro >> <fabrizio.cas...@bp.renesas.com> wrote: >> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt >> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt >> > @@ -14,7 +14,10 @@ channel which can be either RGB, YUYV or BT656. >> > - "renesas,vin-r8a7790" for the R8A7790 device >> > - "renesas,vin-r8a7779" for the R8A7779 device >> > - "renesas,vin-r8a7778" for the R8A7778 device >> > - - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device. >> > + - "renesas,vin-r8a7745" for the R8A7745 device >> > + - "renesas,vin-r8a7743" for the R8A7743 device >> >> Please keep the list sorted by SoC part number. > > It is sorted, just in descending order. Do you want me to re-order the full > list in ascending order? That may be a good idea, given the current order is non-standard and counter-intuitive. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro <fabrizio.cas...@bp.renesas.com> wrote: > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -14,7 +14,10 @@ channel which can be either RGB, YUYV or BT656. > - "renesas,vin-r8a7790" for the R8A7790 device > - "renesas,vin-r8a7779" for the R8A7779 device > - "renesas,vin-r8a7778" for the R8A7778 device > - - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device. > + - "renesas,vin-r8a7745" for the R8A7745 device > + - "renesas,vin-r8a7743" for the R8A7743 device Please keep the list sorted by SoC part number. > + - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible > + device. > - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device. > > When compatible with the generic version nodes must list the Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 1/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]
On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro <fabrizio.cas...@bp.renesas.com> wrote: > Add compatible strings for r8a7743 and r8a7745. No driver change > change is needed as "renesas,rcar-gen2-vin" will activate the right double "change" > code. However, it is good practice to document compatible strings > for the specific SoC as this allows SoC specific changes to the > driver if needed, in addition to document SoC support and therefore > allow checkpatch.pl to validate compatible string values. > > Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com> > Reviewed-by: Biju Das <biju@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] media: dvb_frontend: Fix uninitialized error in dvb_frontend_handle_ioctl()
With gcc-4.1.2: drivers/media/dvb-core/dvb_frontend.c: In function ‘dvb_frontend_handle_ioctl’: drivers/media/dvb-core/dvb_frontend.c:2110: warning: ‘err’ may be used uninitialized in this function Indeed, there are 13 cases where err is used initialized if one of the dvb_frontend_ops is not implemented. Preinitialize err to -EOPNOTSUPP like before to fix this. Fixes: d73dcf0cdb95a47f ("media: dvb_frontend: cleanup ioctl handling logic") Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> --- drivers/media/dvb-core/dvb_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c index 3ad83359098bde79..9eff8ce60d535379 100644 --- a/drivers/media/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb-core/dvb_frontend.c @@ -2107,7 +2107,7 @@ static int dvb_frontend_handle_ioctl(struct file *file, struct dvb_frontend *fe = dvbdev->priv; struct dvb_frontend_private *fepriv = fe->frontend_priv; struct dtv_frontend_properties *c = >dtv_property_cache; - int i, err; + int i, err = -ENOTSUPP; dev_dbg(fe->dvb->device, "%s:\n", __func__); -- 2.7.4
Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings
Hi Jacopo, On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi <jac...@jmondi.org> wrote: > On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote: >> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi >> <jacopo+rene...@jmondi.org> wrote: >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt >> > @@ -0,0 +1,87 @@ >> > +Renesas Capture Engine Unit (CEU) >> > +-- >> > + >> > +The Capture Engine Unit is the image capture interface found on Renesas >> > +RZ chip series and on SH Mobile ones. >> > + >> > +The interface supports a single parallel input with up 8/16bits data bus >> > width. >> >> ... with data bus widths up to 8/16 bits? >> >> > + >> > +Required properties: >> > +- compatible >> > + Must be "renesas,renesas-ceu". >> >> The double "renesas" part looks odd to me. What about "renesas,ceu"? > > I'm totally open for better "compatible" strings here, so yeah, let's > got for the shorter one you proposed... > >> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu", >> too? > > Well, I actually have no SoC-specific data in the driver, so I don't > need SoC specific "compatible" values. But if it's a good practice > to have them anyway, I will add those in next spin.. You don't necessarily need them in the driver, but in the bindings and DTS, just in case a difference is discovered later. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v1 06/10] sh: sh7722: Rename CEU clock
Hi Jacopo, On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Rename CEU clock to match the new platform driver name used in Migo-R. > > There are no other sh7722 based devices Migo-R apart, so we can safely > rename this. > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > --- > arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c > b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c > index 8f07a1a..d85091e 100644 > --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c > +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c > @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = { > CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]), > CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]), > CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]), > - CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]), > + CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]), > CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]), > CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]), > CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]), Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver", to avoid breaking bisection? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v1 01/10] dt-bindings: media: Add Renesas CEU bindings
Hi Jacopo, CC devicetree folks On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote: > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> > --- > .../devicetree/bindings/media/renesas,ceu.txt | 87 > ++ > 1 file changed, 87 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt > > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt > b/Documentation/devicetree/bindings/media/renesas,ceu.txt > new file mode 100644 > index 000..a88e9cb > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt > @@ -0,0 +1,87 @@ > +Renesas Capture Engine Unit (CEU) > +-- > + > +The Capture Engine Unit is the image capture interface found on Renesas > +RZ chip series and on SH Mobile ones. > + > +The interface supports a single parallel input with up 8/16bits data bus > width. ... with data bus widths up to 8/16 bits? > + > +Required properties: > +- compatible > + Must be "renesas,renesas-ceu". The double "renesas" part looks odd to me. What about "renesas,ceu"? Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu", too? > +- reg > + Physical address base and size. > +- interrupts > + The interrupt line number. interrupt specifier > +- pinctrl-names, pinctrl-0 > + phandle of pin controller sub-node configuring pins for CEU > operations. > + > +CEU supports a single parallel input and should contain a single 'port' > subnode > +with a single 'endpoint'. Optional endpoint properties applicable to parallel > +input bus are described in "video-interfaces.txt". > + > +Example: > + > +The example describes the connection between the Capture Engine Unit and a ... an > +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock. > + > +ceu: ceu@e821 { > + reg = <0xe821 0x209c>; > + compatible = "renesas,renesas-ceu"; > + interrupts = ; > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + > + status = "okay"; > + > + port { > + ceu_in: endpoint { > + remote-endpoint = <_out>; > + > + bus-width = <8>; > + hsync-active = <1>; > + vsync-active = <1>; > + pclk-sample = <1>; > + data-active = <1>; > + }; > + }; > +}; > + > +i2c1: i2c@fcfee400 { > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + > + status = "okay"; > + clock-frequency = <10>; > + > + ov7670: camera@21 { > + compatible = "ovti,ov7670"; > + reg = <0x21>; > + > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + > + reset-gpios = < 11 GPIO_ACTIVE_LOW>; > + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>; > + > + clocks = <>; > + clock-names = "xclk"; > + > + xclk: fixed_clk { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <2400>; > + }; > + > + port { > + ov7670_out: endpoint { > + remote-endpoint = <_in>; > + > + bus-width = <8>; > + hsync-active = <1>; > + vsync-active = <1>; > + pclk-sample = <1>; > + data-active = <1>; > + }; > + }; > + }; > -- > 2.7.4 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v7 25/25] rcar-vin: enable support for r8a7796
CC DT On Sat, Nov 11, 2017 at 1:38 AM, Niklas Söderlundwrote: > Add the SoC specific information for Renesas r8a7796. > > Signed-off-by: Niklas Söderlund > Reviewed-by: Hans Verkuil > --- > .../devicetree/bindings/media/rcar_vin.txt | 1 + > drivers/media/platform/rcar-vin/rcar-core.c| 64 > ++ > 2 files changed, 65 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index df1abd0fb20386f8..ddf249c2276600d2 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -10,6 +10,7 @@ Depending on the instance the VIN input is connected to > external SoC pins, or > on Gen3 to a CSI-2 receiver. > > - compatible: Must be one or more of the following > + - "renesas,vin-r8a7796" for the R8A7796 device > - "renesas,vin-r8a7795" for the R8A7795 device > - "renesas,vin-r8a7794" for the R8A7794 device > - "renesas,vin-r8a7793" for the R8A7793 device > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c > b/drivers/media/platform/rcar-vin/rcar-core.c > index b22f6596700d2479..e329de4ce0172e8d 100644 > --- a/drivers/media/platform/rcar-vin/rcar-core.c > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > @@ -1084,6 +1084,66 @@ static const struct rvin_info rcar_info_r8a7795es1 = { > }, > }; > > +static const struct rvin_info rcar_info_r8a7796 = { > + .chip = RCAR_GEN3, > + .use_mc = true, > + .max_width = 4096, > + .max_height = 4096, > + > + .num_chsels = 5, > + .chsels = { > + { > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + }, { > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 1 }, > + { .csi = RVIN_CSI20, .chan = 1 }, > + }, { > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 2 }, > + { .csi = RVIN_CSI20, .chan = 2 }, > + }, { > + { .csi = RVIN_CSI40, .chan = 1 }, > + { .csi = RVIN_CSI20, .chan = 1 }, > + { .csi = RVIN_NC, .chan = 1 }, > + { .csi = RVIN_CSI40, .chan = 3 }, > + { .csi = RVIN_CSI20, .chan = 3 }, > + }, { > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + }, { > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 1 }, > + { .csi = RVIN_CSI20, .chan = 1 }, > + }, { > + { .csi = RVIN_NC, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 0 }, > + { .csi = RVIN_CSI20, .chan = 0 }, > + { .csi = RVIN_CSI40, .chan = 2 }, > + { .csi = RVIN_CSI20, .chan = 2 }, > + }, { > + { .csi = RVIN_CSI40, .chan = 1 }, > + { .csi = RVIN_CSI20, .chan = 1 }, > + { .csi = RVIN_NC, .chan = 1 }, > + { .csi = RVIN_CSI40, .chan = 3 }, > + { .csi = RVIN_CSI20, .chan = 3 }, > + }, > + }, > +}; > + > static const struct of_device_id rvin_of_id_table[] = { > { > .compatible = "renesas,vin-r8a7778", > @@ -1117,6 +1177,10 @@ static const struct of_device_id rvin_of_id_table[] = { > .compatible = "renesas,vin-r8a7795", > .data = _info_r8a7795, > }, > + { > + .compatible = "renesas,vin-r8a7796", > + .data = _info_r8a7796, > + }, > { }, > }; > MODULE_DEVICE_TABLE(of, rvin_of_id_table); > -- > 2.15.0
Re: [PATCH v9 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
Hi Niklas, On Fri, Nov 10, 2017 at 12:43 AM, Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> wrote: > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2 > hardware blocks are connected between the video sources and the video > grabbers (VIN). > > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> Thanks for your patch! > --- /dev/null > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c > @@ -0,0 +1,933 @@ > +/* Control Timing Select */ > +#define TREF_REG 0x00 > +#define TREF_TREF (1 << 0) BIT(0)? (many more) > +struct phypll_hsfreqrange { > + unsigned intmbps; > + unsigned char reg; The "unsigned char" doesn't buy you much, due to alignment rules. What about making both u16 instead? > +static const struct rcar_csi2_format *rcar_csi2_code_to_fmt(unsigned int > code) > +{ > + int i; unsigned int > + > + for (i = 0; i < ARRAY_SIZE(rcar_csi2_formats); i++) > + if (rcar_csi2_formats[i].code == code) > + return rcar_csi2_formats + i; > + return NULL; > +} > +struct rcar_csi2_info { > + const struct phypll_hsfreqrange *hsfreqrange; > + bool clear_ulps; > + bool have_phtw; > + unsigned int csi0clkfreqrange; I'd sort by decreasing size/alignment, i.e. the bools last. > +}; > + > +struct rcar_csi2 { > + struct device *dev; > + void __iomem *base; > + const struct rcar_csi2_info *info; > + > + unsigned short lanes; > + unsigned char lane_swap[4]; > + > + struct v4l2_subdev subdev; > + struct media_pad pads[NR_OF_RCAR_CSI2_PAD]; > + > + struct v4l2_mbus_framefmt mf; > + > + struct mutex lock; > + int stream_count; > + > + struct v4l2_async_notifier notifier; > + struct v4l2_async_subdev remote; Likewise. > +static int rcar_csi2_start(struct rcar_csi2 *priv) > +{ > + dev_dbg(priv->dev, "Input size (%dx%d%c)\n", mf->width, %u for __u32 > + mf->height, mf->field == V4L2_FIELD_NONE ? 'p' : 'i'); > +static int rcar_csi2_probe_resources(struct rcar_csi2 *priv, > +struct platform_device *pdev) > +{ > + struct resource *mem; > + int irq; > + > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!mem) No need to check mem, platform_get_resource() and devm_ioremap_resource() are designed to be pipelined. > + return -ENODEV; > + > + priv->base = devm_ioremap_resource(>dev, mem); > +static const struct soc_device_attribute r8a7795es1[] = { > + { .soc_id = "r8a7795", .revision = "ES1.*" }, > + { /* sentinel */ } > +}; > + > +static int rcar_csi2_probe(struct platform_device *pdev) > +{ > + struct rcar_csi2 *priv; > + unsigned int i; > + int ret; > + > + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + priv->info = of_device_get_match_data(>dev); > + > + /* r8a7795 ES1.x behaves different then ES2.0+ but no own compat */ > + if (priv->info == _csi2_info_r8a7795 && > + soc_device_match(r8a7795es1)) > + priv->info = _csi2_info_r8a7795es1; Please store _csi2_info_r8a7795es1 in r8a7795es1[0].data instead. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v9 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
Hi Niklas, On Fri, Nov 10, 2017 at 12:43 AM, Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> wrote: > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers > are located between the video sources (CSI-2 transmitters) and the video > grabbers (VIN) on Gen3 of Renesas R-Car SoC. > > Each CSI-2 device is connected to more then one VIN device which > simultaneously can receive video from the same CSI-2 device. Each VIN > device can also be connected to more then one CSI-2 device. The routing > of which link are used are controlled by the VIN devices. There are only > a few possible routes which are set by hardware limitations, which are > different for each SoC in the Gen3 family. > > To work with the limitations of routing possibilities it is necessary > for the DT bindings to describe which VIN device is connected to which > CSI-2 device. This is why port 1 needs to to assign reg numbers for each > VIN device that be connected to it. To setup and to know which links are > valid for each SoC is the responsibility of the VIN driver since the > register to configure it belongs to the VIN hardware. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > --- > .../devicetree/bindings/media/rcar-csi2.txt| 103 > + > MAINTAINERS| 1 + > 2 files changed, 104 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt > > diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt > b/Documentation/devicetree/bindings/media/rcar-csi2.txt > new file mode 100644 > index ..39d41d82b71b60eb > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt > +Example: > + > + csi20: csi2@fea8 { > + compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2"; > + reg = <0 0xfea8 0 0x1>; > + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>; > + clocks = < CPG_MOD 714>; > + power-domains = < R8A7796_PD_ALWAYS_ON>; resets? I know this is just an example, but your prototype patches to add the csi nodes to r8a7795.dtsi also don't have reset properties. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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