diff mbox series

[2/2] pwm: Enable compile testing for some of drivers

Message ID 20191230172113.17222-2-krzk@kernel.org
State Changes Requested
Headers show
Series [1/2] pwm: Fix minor Kconfig whitespace issues | expand

Commit Message

Krzysztof Kozlowski Dec. 30, 2019, 5:21 p.m. UTC
Some of the PWM drivers can be compile tested to increase build
coverage.

The Meson PWM driver requires COMMON_CLK dependency.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 drivers/pwm/Kconfig | 48 +++++++++++++++++++++++----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

Comments

Florian Fainelli Dec. 30, 2019, 7:30 p.m. UTC | #1
On 12/30/19 9:21 AM, Krzysztof Kozlowski wrote:
> Some of the PWM drivers can be compile tested to increase build
> coverage.
> 
> The Meson PWM driver requires COMMON_CLK dependency.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>

for PWM_BCM2835 and PWM_BRCMSTB, thanks!
Martin Blumenstingl Dec. 31, 2019, 2:52 p.m. UTC | #2
On Mon, Dec 30, 2019 at 6:21 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Some of the PWM drivers can be compile tested to increase build
> coverage.
>
> The Meson PWM driver requires COMMON_CLK dependency.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
for PWM_MESON:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

thank you!


Martin
Claudiu Beznea Jan. 6, 2020, 9:53 a.m. UTC | #3
On 30.12.2019 19:21, Krzysztof Kozlowski wrote:
> Some of the PWM drivers can be compile tested to increase build
> coverage.
> 
> The Meson PWM driver requires COMMON_CLK dependency.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

for PWM_ATMEL:
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Uwe Kleine-König Jan. 7, 2020, 7:26 a.m. UTC | #4
Hello Krzysztof,

On Mon, Dec 30, 2019 at 06:21:13PM +0100, Krzysztof Kozlowski wrote:
> Some of the PWM drivers can be compile tested to increase build
> coverage.
> 
> The Meson PWM driver requires COMMON_CLK dependency.

I'm surprised that there are not more that need this. Is HAVE_CLK not
enough?

Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
config (which does't have HAS_IOMEM) and they all compile fine.

> @@ -318,7 +319,7 @@ config PWM_MEDIATEK
>  
>  config PWM_MXS
>  	tristate "Freescale MXS PWM support"
> -	depends on ARCH_MXS && OF
> +	depends on (ARCH_MXS && OF) || COMPILE_TEST
>  	select STMP_DEVICE
>  	help
>  	  Generic PWM framework driver for Freescale MXS.
> @@ -328,7 +329,8 @@ config PWM_MXS
>  
>  config PWM_OMAP_DMTIMER
>  	tristate "OMAP Dual-Mode Timer PWM support"
> -	depends on OF && ARCH_OMAP && OMAP_DM_TIMER
> +	depends on (ARCH_OMAP && OMAP_DM_TIMER) || COMPILE_TEST
> +	depends on OF

I'm surprised that OF isn't required for PWM_MXS but is is for
PWM_OMAP_DMTIMER. pwm-mxs compiles without CONFIG_OF, didn't test
pwm-omap-dmtimer.

Best regards
Uwe
Krzysztof Kozlowski Jan. 7, 2020, 8:25 a.m. UTC | #5
On Tue, Jan 07, 2020 at 08:26:45AM +0100, Uwe Kleine-König wrote:
> Hello Krzysztof,
> 
> On Mon, Dec 30, 2019 at 06:21:13PM +0100, Krzysztof Kozlowski wrote:
> > Some of the PWM drivers can be compile tested to increase build
> > coverage.
> > 
> > The Meson PWM driver requires COMMON_CLK dependency.
> 
> I'm surprised that there are not more that need this. Is HAVE_CLK not
> enough?

Nope. E.g. for alpha architecture, HAVE_CLK is not set and without
COMMON_CLK:

drivers/pwm/pwm-meson.o: In function `meson_pwm_init_channels':
(.text+0x244): undefined reference to `devm_clk_register'

I guess other solution would be to add stubs for few clk functions...

> Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> config (which does't have HAS_IOMEM) and they all compile fine.

Because of !HAS_IOMEM, since some time ARCH=um does not support
COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
testing (and for regular build it is selected by ARCH).

> 
> > @@ -318,7 +319,7 @@ config PWM_MEDIATEK
> >  
> >  config PWM_MXS
> >  	tristate "Freescale MXS PWM support"
> > -	depends on ARCH_MXS && OF
> > +	depends on (ARCH_MXS && OF) || COMPILE_TEST
> >  	select STMP_DEVICE
> >  	help
> >  	  Generic PWM framework driver for Freescale MXS.
> > @@ -328,7 +329,8 @@ config PWM_MXS
> >  
> >  config PWM_OMAP_DMTIMER
> >  	tristate "OMAP Dual-Mode Timer PWM support"
> > -	depends on OF && ARCH_OMAP && OMAP_DM_TIMER
> > +	depends on (ARCH_OMAP && OMAP_DM_TIMER) || COMPILE_TEST
> > +	depends on OF
> 
> I'm surprised that OF isn't required for PWM_MXS but is is for
> PWM_OMAP_DMTIMER. pwm-mxs compiles without CONFIG_OF, didn't test
> pwm-omap-dmtimer.

Since some time !OF has all necessary stubs so OF is actually needed
only for binding, not compiling.

Best regards,
Krzysztof
Uwe Kleine-König Jan. 7, 2020, 10:42 a.m. UTC | #6
Hello Krzysztof,

On Tue, Jan 07, 2020 at 09:25:39AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Jan 07, 2020 at 08:26:45AM +0100, Uwe Kleine-König wrote:
> > On Mon, Dec 30, 2019 at 06:21:13PM +0100, Krzysztof Kozlowski wrote:
> > > Some of the PWM drivers can be compile tested to increase build
> > > coverage.
> > > 
> > > The Meson PWM driver requires COMMON_CLK dependency.
> > 
> > I'm surprised that there are not more that need this. Is HAVE_CLK not
> > enough?
> 
> Nope. E.g. for alpha architecture, HAVE_CLK is not set and without
> COMMON_CLK:
> 
> drivers/pwm/pwm-meson.o: In function `meson_pwm_init_channels':
> (.text+0x244): undefined reference to `devm_clk_register'

I see. devm_clk_register() only exists in include/linux/clk-provider.h.

> I guess other solution would be to add stubs for few clk functions...
> 
> > Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> > config (which does't have HAS_IOMEM) and they all compile fine.
> 
> Because of !HAS_IOMEM, since some time ARCH=um does not support
> COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
> testing (and for regular build it is selected by ARCH).

Hehe, I didn't notice because for testing I just dropped the "depends on
..." lines in Kconfig instead of adding "|| COMPILE_TEST" :-) Still they
compile fine on UML.

Ah, since bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on
!UML") == v4.8-rc1~52^2~83 COMPILE_TEST cannot be enabled on UML, but
later 1bcbfbfdeb00 ("um: add dummy ioremap and iounmap functions")
== v4.13-rc1~8^2~6 UM got a dummy implementation. So maybe we could
revert bc083a64b6c0 today? (And if not, a comment about why near the
"depends on !UML" in init/Kconfig would be great.)

Orthogonal to that, I wonder if depending on HAS_IOMEM is right even
though the compile testers won't notice it missing. Or should HAS_IOMEM
be dropped?

> > > @@ -318,7 +319,7 @@ config PWM_MEDIATEK
> > >  
> > >  config PWM_MXS
> > >  	tristate "Freescale MXS PWM support"
> > > -	depends on ARCH_MXS && OF
> > > +	depends on (ARCH_MXS && OF) || COMPILE_TEST
> > >  	select STMP_DEVICE
> > >  	help
> > >  	  Generic PWM framework driver for Freescale MXS.
> > > @@ -328,7 +329,8 @@ config PWM_MXS
> > >  
> > >  config PWM_OMAP_DMTIMER
> > >  	tristate "OMAP Dual-Mode Timer PWM support"
> > > -	depends on OF && ARCH_OMAP && OMAP_DM_TIMER
> > > +	depends on (ARCH_OMAP && OMAP_DM_TIMER) || COMPILE_TEST
> > > +	depends on OF
> > 
> > I'm surprised that OF isn't required for PWM_MXS but is is for
> > PWM_OMAP_DMTIMER. pwm-mxs compiles without CONFIG_OF, didn't test
> > pwm-omap-dmtimer.
> 
> Since some time !OF has all necessary stubs so OF is actually needed
> only for binding, not compiling.

That doesn't explain why you handle PWM_MXS and PWM_OMAP_DMTIMER
differently though.

Best regards
Uwe
Krzysztof Kozlowski Jan. 7, 2020, 11:03 a.m. UTC | #7
On Tue, Jan 07, 2020 at 11:42:34AM +0100, Uwe Kleine-König wrote:
> > I guess other solution would be to add stubs for few clk functions...
> > 
> > > Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> > > config (which does't have HAS_IOMEM) and they all compile fine.
> > 
> > Because of !HAS_IOMEM, since some time ARCH=um does not support
> > COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
> > testing (and for regular build it is selected by ARCH).
> 
> Hehe, I didn't notice because for testing I just dropped the "depends on
> ..." lines in Kconfig instead of adding "|| COMPILE_TEST" :-) Still they
> compile fine on UML.
> 
> Ah, since bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on
> !UML") == v4.8-rc1~52^2~83 COMPILE_TEST cannot be enabled on UML, but
> later 1bcbfbfdeb00 ("um: add dummy ioremap and iounmap functions")
> == v4.13-rc1~8^2~6 UM got a dummy implementation. So maybe we could
> revert bc083a64b6c0 today? (And if not, a comment about why near the
> "depends on !UML" in init/Kconfig would be great.)
> 
> Orthogonal to that, I wonder if depending on HAS_IOMEM is right even
> though the compile testers won't notice it missing. Or should HAS_IOMEM
> be dropped?

I think yes, it can be dropped, but this would require:
1. Fixing any dependencies on HAS_IOMEM, e.g.:
    WARNING: unmet direct dependencies detected for MFD_SYSCON
      Depends on [n]: HAS_IOMEM [=n]
      Selected by [y]:
      - PHY_DA8XX_USB [=y] && (ARCH_DAVINCI_DA8XX || COMPILE_TEST [=y])

2. Checking if all of stubs are implemented (not only IOMEM but maybe
   DMA as well). Also 1bcbfbfdeb00 brought only few stubs. Still we
   need devm_ioremap_resource() and others.

Quick test shows mentioned "unmet direct dependencies" and:
    phy-pxa-usb.c:(.text+0x2f5): undefined reference to `devm_ioremap_resource'
    dma-iommu.c:(.text+0x179): undefined reference to `dma_pgprot'

> 
> > > > @@ -318,7 +319,7 @@ config PWM_MEDIATEK
> > > >  
> > > >  config PWM_MXS
> > > >  	tristate "Freescale MXS PWM support"
> > > > -	depends on ARCH_MXS && OF
> > > > +	depends on (ARCH_MXS && OF) || COMPILE_TEST
> > > >  	select STMP_DEVICE
> > > >  	help
> > > >  	  Generic PWM framework driver for Freescale MXS.
> > > > @@ -328,7 +329,8 @@ config PWM_MXS
> > > >  
> > > >  config PWM_OMAP_DMTIMER
> > > >  	tristate "OMAP Dual-Mode Timer PWM support"
> > > > -	depends on OF && ARCH_OMAP && OMAP_DM_TIMER
> > > > +	depends on (ARCH_OMAP && OMAP_DM_TIMER) || COMPILE_TEST
> > > > +	depends on OF
> > > 
> > > I'm surprised that OF isn't required for PWM_MXS but is is for
> > > PWM_OMAP_DMTIMER. pwm-mxs compiles without CONFIG_OF, didn't test
> > > pwm-omap-dmtimer.
> > 
> > Since some time !OF has all necessary stubs so OF is actually needed
> > only for binding, not compiling.
> 
> That doesn't explain why you handle PWM_MXS and PWM_OMAP_DMTIMER
> differently though.

You're right, I missed this. None of them require OF for building so
separate "depends on OF" makes sense only for readability of this.  Let
me send v2 to make it similar to PWM_MXS.


Best regards,
Krzysztof
Uwe Kleine-König Jan. 7, 2020, 11:33 a.m. UTC | #8
On Tue, Jan 07, 2020 at 12:03:59PM +0100, Krzysztof Kozlowski wrote:
> On Tue, Jan 07, 2020 at 11:42:34AM +0100, Uwe Kleine-König wrote:
> > > I guess other solution would be to add stubs for few clk functions...
> > > 
> > > > Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> > > > config (which does't have HAS_IOMEM) and they all compile fine.
> > > 
> > > Because of !HAS_IOMEM, since some time ARCH=um does not support
> > > COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
> > > testing (and for regular build it is selected by ARCH).
> > 
> > Hehe, I didn't notice because for testing I just dropped the "depends on
> > ..." lines in Kconfig instead of adding "|| COMPILE_TEST" :-) Still they
> > compile fine on UML.
> > 
> > Ah, since bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on
> > !UML") == v4.8-rc1~52^2~83 COMPILE_TEST cannot be enabled on UML, but
> > later 1bcbfbfdeb00 ("um: add dummy ioremap and iounmap functions")
> > == v4.13-rc1~8^2~6 UM got a dummy implementation. So maybe we could
> > revert bc083a64b6c0 today? (And if not, a comment about why near the
> > "depends on !UML" in init/Kconfig would be great.)
> > 
> > Orthogonal to that, I wonder if depending on HAS_IOMEM is right even
> > though the compile testers won't notice it missing. Or should HAS_IOMEM
> > be dropped?
> 
> I think yes, it can be dropped, but this would require:
> 1. Fixing any dependencies on HAS_IOMEM, e.g.:
>     WARNING: unmet direct dependencies detected for MFD_SYSCON
>       Depends on [n]: HAS_IOMEM [=n]
>       Selected by [y]:
>       - PHY_DA8XX_USB [=y] && (ARCH_DAVINCI_DA8XX || COMPILE_TEST [=y])

I don't understand that warning. What did you modify to trigger that?
Probably related to the big "if HAS_IOMEM" in drivers/mfd/Kconfig?!

> 2. Checking if all of stubs are implemented (not only IOMEM but maybe
>    DMA as well). Also 1bcbfbfdeb00 brought only few stubs. Still we
>    need devm_ioremap_resource() and others.

A problem is that it's unclear (to me at least) what the presence of
HAS_IOMEM actually implies. I thought it's about ioremap + readl +
writel (including their respective variants). Does it really include dma
stuff, too?

> Quick test shows mentioned "unmet direct dependencies" and:
>     phy-pxa-usb.c:(.text+0x2f5): undefined reference to `devm_ioremap_resource'
>     dma-iommu.c:(.text+0x179): undefined reference to `dma_pgprot'

dma_pgprot seems to depend on HAS_DMA though, not HAS_IOMEM.

(Oh, HAS_DMA is defined using "depends on !NO_DMA" + "default y".
NO_DMA has three different definitions. Two of them (in
drivers/crypto/ccree/cc_hw_queue_defs.h and arch/arm/include/asm/dma.h)
unrelated.)

Best regards
Uwe
Krzysztof Kozlowski Jan. 7, 2020, 11:54 a.m. UTC | #9
On Tue, Jan 07, 2020 at 12:33:54PM +0100, Uwe Kleine-König wrote:
> On Tue, Jan 07, 2020 at 12:03:59PM +0100, Krzysztof Kozlowski wrote:
> > On Tue, Jan 07, 2020 at 11:42:34AM +0100, Uwe Kleine-König wrote:
> > > > I guess other solution would be to add stubs for few clk functions...
> > > > 
> > > > > Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> > > > > config (which does't have HAS_IOMEM) and they all compile fine.
> > > > 
> > > > Because of !HAS_IOMEM, since some time ARCH=um does not support
> > > > COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
> > > > testing (and for regular build it is selected by ARCH).
> > > 
> > > Hehe, I didn't notice because for testing I just dropped the "depends on
> > > ..." lines in Kconfig instead of adding "|| COMPILE_TEST" :-) Still they
> > > compile fine on UML.
> > > 
> > > Ah, since bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on
> > > !UML") == v4.8-rc1~52^2~83 COMPILE_TEST cannot be enabled on UML, but
> > > later 1bcbfbfdeb00 ("um: add dummy ioremap and iounmap functions")
> > > == v4.13-rc1~8^2~6 UM got a dummy implementation. So maybe we could
> > > revert bc083a64b6c0 today? (And if not, a comment about why near the
> > > "depends on !UML" in init/Kconfig would be great.)
> > > 
> > > Orthogonal to that, I wonder if depending on HAS_IOMEM is right even
> > > though the compile testers won't notice it missing. Or should HAS_IOMEM
> > > be dropped?
> > 
> > I think yes, it can be dropped, but this would require:
> > 1. Fixing any dependencies on HAS_IOMEM, e.g.:
> >     WARNING: unmet direct dependencies detected for MFD_SYSCON
> >       Depends on [n]: HAS_IOMEM [=n]
> >       Selected by [y]:
> >       - PHY_DA8XX_USB [=y] && (ARCH_DAVINCI_DA8XX || COMPILE_TEST [=y])
> 
> I don't understand that warning. What did you modify to trigger that?
> Probably related to the big "if HAS_IOMEM" in drivers/mfd/Kconfig?!

OK, that's actually from my other patch to illustrate the problem:
https://lore.kernel.org/linux-arm-kernel/20200103164710.4829-2-krzk@kernel.org/

After reverting of bc083a64b6c0, every driver that selects MFD_SYSCON
(or some other parts) has to depend on HAS_IOMEM.

> 
> > 2. Checking if all of stubs are implemented (not only IOMEM but maybe
> >    DMA as well). Also 1bcbfbfdeb00 brought only few stubs. Still we
> >    need devm_ioremap_resource() and others.
> 
> A problem is that it's unclear (to me at least) what the presence of
> HAS_IOMEM actually implies. I thought it's about ioremap + readl +
> writel (including their respective variants). Does it really include dma
> stuff, too?
> 
> > Quick test shows mentioned "unmet direct dependencies" and:
> >     phy-pxa-usb.c:(.text+0x2f5): undefined reference to `devm_ioremap_resource'
> >     dma-iommu.c:(.text+0x179): undefined reference to `dma_pgprot'
> 
> dma_pgprot seems to depend on HAS_DMA though, not HAS_IOMEM.
> 
> (Oh, HAS_DMA is defined using "depends on !NO_DMA" + "default y".
> NO_DMA has three different definitions. Two of them (in
> drivers/crypto/ccree/cc_hw_queue_defs.h and arch/arm/include/asm/dma.h)
> unrelated.)

Yes, HAS_DMA is the second missing piece for UM.

Best regards,
Krzysztof
Uwe Kleine-König Jan. 7, 2020, 12:09 p.m. UTC | #10
Hello Krzysztof,

On Tue, Jan 07, 2020 at 12:54:29PM +0100, Krzysztof Kozlowski wrote:
> On Tue, Jan 07, 2020 at 12:33:54PM +0100, Uwe Kleine-König wrote:
> > On Tue, Jan 07, 2020 at 12:03:59PM +0100, Krzysztof Kozlowski wrote:
> > > On Tue, Jan 07, 2020 at 11:42:34AM +0100, Uwe Kleine-König wrote:
> > > > > I guess other solution would be to add stubs for few clk functions...
> > > > > 
> > > > > > Also HAS_IOMEM is a typical requirement, but I tested with an ARCH=um
> > > > > > config (which does't have HAS_IOMEM) and they all compile fine.
> > > > > 
> > > > > Because of !HAS_IOMEM, since some time ARCH=um does not support
> > > > > COMPILE_TEST. Therefore HAS_IOMEM dependency is not needed for compile
> > > > > testing (and for regular build it is selected by ARCH).
> > > > 
> > > > Hehe, I didn't notice because for testing I just dropped the "depends on
> > > > ..." lines in Kconfig instead of adding "|| COMPILE_TEST" :-) Still they
> > > > compile fine on UML.
> > > > 
> > > > Ah, since bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on
> > > > !UML") == v4.8-rc1~52^2~83 COMPILE_TEST cannot be enabled on UML, but
> > > > later 1bcbfbfdeb00 ("um: add dummy ioremap and iounmap functions")
> > > > == v4.13-rc1~8^2~6 UM got a dummy implementation. So maybe we could
> > > > revert bc083a64b6c0 today? (And if not, a comment about why near the
> > > > "depends on !UML" in init/Kconfig would be great.)
> > > > 
> > > > Orthogonal to that, I wonder if depending on HAS_IOMEM is right even
> > > > though the compile testers won't notice it missing. Or should HAS_IOMEM
> > > > be dropped?
> > > 
> > > I think yes, it can be dropped, but this would require:
> > > 1. Fixing any dependencies on HAS_IOMEM, e.g.:
> > >     WARNING: unmet direct dependencies detected for MFD_SYSCON
> > >       Depends on [n]: HAS_IOMEM [=n]
> > >       Selected by [y]:
> > >       - PHY_DA8XX_USB [=y] && (ARCH_DAVINCI_DA8XX || COMPILE_TEST [=y])
> > 
> > I don't understand that warning. What did you modify to trigger that?
> > Probably related to the big "if HAS_IOMEM" in drivers/mfd/Kconfig?!
> 
> OK, that's actually from my other patch to illustrate the problem:
> https://lore.kernel.org/linux-arm-kernel/20200103164710.4829-2-krzk@kernel.org/
> 
> After reverting of bc083a64b6c0, every driver that selects MFD_SYSCON
> (or some other parts) has to depend on HAS_IOMEM.

OK, understood, thanks.

> > > 2. Checking if all of stubs are implemented (not only IOMEM but maybe
> > >    DMA as well). Also 1bcbfbfdeb00 brought only few stubs. Still we
> > >    need devm_ioremap_resource() and others.
> > 
> > A problem is that it's unclear (to me at least) what the presence of
> > HAS_IOMEM actually implies. I thought it's about ioremap + readl +
> > writel (including their respective variants). Does it really include dma
> > stuff, too?
> > 
> > > Quick test shows mentioned "unmet direct dependencies" and:
> > >     phy-pxa-usb.c:(.text+0x2f5): undefined reference to `devm_ioremap_resource'
> > >     dma-iommu.c:(.text+0x179): undefined reference to `dma_pgprot'
> > 
> > dma_pgprot seems to depend on HAS_DMA though, not HAS_IOMEM.
> > 
> > (Oh, HAS_DMA is defined using "depends on !NO_DMA" + "default y".
> > NO_DMA has three different definitions. Two of them (in
> > drivers/crypto/ccree/cc_hw_queue_defs.h and arch/arm/include/asm/dma.h)
> > unrelated.)
> 
> Yes, HAS_DMA is the second missing piece for UM.

So something like:

	# Usermode linux doesn't provide HAS_DMA and HAS_IOMEM.  To not have to
	# clutter most dependencies with these just exclude UML from compile
	# testing.

as comment for COMPILE_TEST's depend line should be fine, right?

Best regards
Uwe
Krzysztof Kozlowski Jan. 7, 2020, 12:15 p.m. UTC | #11
On Tue, Jan 07, 2020 at 01:09:26PM +0100, Uwe Kleine-König wrote:
> > > (Oh, HAS_DMA is defined using "depends on !NO_DMA" + "default y".
> > > NO_DMA has three different definitions. Two of them (in
> > > drivers/crypto/ccree/cc_hw_queue_defs.h and arch/arm/include/asm/dma.h)
> > > unrelated.)
> > 
> > Yes, HAS_DMA is the second missing piece for UM.
> 
> So something like:
> 
> 	# Usermode linux doesn't provide HAS_DMA and HAS_IOMEM.  To not have to
> 	# clutter most dependencies with these just exclude UML from compile
> 	# testing.
> 
> as comment for COMPILE_TEST's depend line should be fine, right?
> 

I think yes.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c865d688f6b4..d5661a227321 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -44,7 +44,7 @@  config PWM_AB8500
 
 config PWM_ATMEL
 	tristate "Atmel PWM support"
-	depends on ARCH_AT91 && OF
+	depends on (ARCH_AT91 || COMPILE_TEST) && OF
 	help
 	  Generic PWM framework driver for Atmel SoC.
 
@@ -100,7 +100,7 @@  config PWM_BCM_KONA
 
 config PWM_BCM2835
 	tristate "BCM2835 PWM support"
-	depends on ARCH_BCM2835
+	depends on ARCH_BCM2835 || COMPILE_TEST
 	help
 	  PWM framework driver for BCM2835 controller (Raspberry Pi)
 
@@ -109,7 +109,7 @@  config PWM_BCM2835
 
 config PWM_BERLIN
 	tristate "Marvell Berlin PWM support"
-	depends on ARCH_BERLIN
+	depends on ARCH_BERLIN || COMPILE_TEST
 	help
 	  PWM framework driver for Marvell Berlin SoCs.
 
@@ -118,7 +118,7 @@  config PWM_BERLIN
 
 config PWM_BRCMSTB
 	tristate "Broadcom STB PWM support"
-	depends on ARCH_BRCMSTB || BMIPS_GENERIC
+	depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST
 	help
 	  Generic PWM framework driver for the Broadcom Set-top-Box
 	  SoCs (BCM7xxx).
@@ -152,7 +152,7 @@  config PWM_CROS_EC
 
 config PWM_EP93XX
 	tristate "Cirrus Logic EP93xx PWM support"
-	depends on ARCH_EP93XX
+	depends on ARCH_EP93XX || COMPILE_TEST
 	help
 	  Generic PWM framework driver for Cirrus Logic EP93xx.
 
@@ -195,7 +195,7 @@  config PWM_IMG
 
 config PWM_IMX1
 	tristate "i.MX1 PWM support"
-	depends on ARCH_MXC
+	depends on ARCH_MXC || COMPILE_TEST
 	help
 	  Generic PWM framework driver for i.MX1 and i.MX21
 
@@ -204,7 +204,7 @@  config PWM_IMX1
 
 config PWM_IMX27
 	tristate "i.MX27 PWM support"
-	depends on ARCH_MXC
+	depends on ARCH_MXC || COMPILE_TEST
 	help
 	  Generic PWM framework driver for i.MX27 and later i.MX SoCs.
 
@@ -244,7 +244,7 @@  config PWM_LP3943
 
 config PWM_LPC18XX_SCT
 	tristate "LPC18xx/43xx PWM/SCT support"
-	depends on ARCH_LPC18XX
+	depends on ARCH_LPC18XX || COMPILE_TEST
 	help
 	  Generic PWM framework driver for NXP LPC18xx PWM/SCT which
 	  supports 16 channels.
@@ -256,7 +256,7 @@  config PWM_LPC18XX_SCT
 
 config PWM_LPC32XX
 	tristate "LPC32XX PWM support"
-	depends on ARCH_LPC32XX
+	depends on ARCH_LPC32XX || COMPILE_TEST
 	help
 	  Generic PWM framework driver for LPC32XX. The LPC32XX SOC has two
 	  PWM controllers.
@@ -289,7 +289,8 @@  config PWM_LPSS_PLATFORM
 
 config PWM_MESON
 	tristate "Amlogic Meson PWM driver"
-	depends on ARCH_MESON
+	depends on ARCH_MESON || COMPILE_TEST
+	depends on COMMON_CLK
 	help
 	  The platform driver for Amlogic Meson PWM controller.
 
@@ -318,7 +319,7 @@  config PWM_MEDIATEK
 
 config PWM_MXS
 	tristate "Freescale MXS PWM support"
-	depends on ARCH_MXS && OF
+	depends on (ARCH_MXS && OF) || COMPILE_TEST
 	select STMP_DEVICE
 	help
 	  Generic PWM framework driver for Freescale MXS.
@@ -328,7 +329,8 @@  config PWM_MXS
 
 config PWM_OMAP_DMTIMER
 	tristate "OMAP Dual-Mode Timer PWM support"
-	depends on OF && ARCH_OMAP && OMAP_DM_TIMER
+	depends on (ARCH_OMAP && OMAP_DM_TIMER) || COMPILE_TEST
+	depends on OF
 	help
 	  Generic PWM framework driver for OMAP Dual-Mode Timer PWM output
 
@@ -356,7 +358,7 @@  config PWM_PUV3
 
 config PWM_PXA
 	tristate "PXA PWM support"
-	depends on ARCH_PXA
+	depends on ARCH_PXA || COMPILE_TEST
 	help
 	  Generic PWM framework driver for PXA.
 
@@ -387,14 +389,14 @@  config PWM_RENESAS_TPU
 
 config PWM_ROCKCHIP
 	tristate "Rockchip PWM support"
-	depends on ARCH_ROCKCHIP
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	help
 	  Generic PWM framework driver for the PWM controller found on
 	  Rockchip SoCs.
 
 config PWM_SAMSUNG
 	tristate "Samsung PWM support"
-	depends on PLAT_SAMSUNG || ARCH_EXYNOS
+	depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
 	help
 	  Generic PWM framework driver for Samsung.
 
@@ -414,7 +416,7 @@  config PWM_SIFIVE
 
 config PWM_SPEAR
 	tristate "STMicroelectronics SPEAr PWM support"
-	depends on PLAT_SPEAR
+	depends on PLAT_SPEAR || COMPILE_TEST
 	depends on OF
 	help
 	  Generic PWM framework driver for the PWM controller on ST
@@ -436,7 +438,7 @@  config PWM_SPRD
 
 config PWM_STI
 	tristate "STiH4xx PWM support"
-	depends on ARCH_STI
+	depends on ARCH_STI || COMPILE_TEST
 	depends on OF
 	help
 	  Generic PWM framework driver for STiH4xx SoCs.
@@ -446,7 +448,7 @@  config PWM_STI
 
 config PWM_STM32
 	tristate "STMicroelectronics STM32 PWM"
-	depends on MFD_STM32_TIMERS
+	depends on MFD_STM32_TIMERS || COMPILE_TEST
 	help
 	  Generic PWM framework driver for STM32 SoCs.
 
@@ -482,7 +484,7 @@  config PWM_SUN4I
 
 config PWM_TEGRA
 	tristate "NVIDIA Tegra PWM support"
-	depends on ARCH_TEGRA
+	depends on ARCH_TEGRA || COMPILE_TEST
 	help
 	  Generic PWM framework driver for the PWFM controller found on NVIDIA
 	  Tegra SoCs.
@@ -492,7 +494,7 @@  config PWM_TEGRA
 
 config PWM_TIECAP
 	tristate "ECAP PWM support"
-	depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE || ARCH_K3
+	depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST
 	help
 	  PWM driver support for the ECAP APWM controller found on TI SOCs
 
@@ -501,7 +503,7 @@  config PWM_TIECAP
 
 config PWM_TIEHRPWM
 	tristate "EHRPWM PWM support"
-	depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_K3
+	depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_K3 || COMPILE_TEST
 	help
 	  PWM driver support for the EHRPWM controller found on TI SOCs
 
@@ -528,7 +530,7 @@  config PWM_TWL_LED
 
 config PWM_VT8500
 	tristate "vt8500 PWM support"
-	depends on ARCH_VT8500
+	depends on ARCH_VT8500 || COMPILE_TEST
 	help
 	  Generic PWM framework driver for vt8500.
 
@@ -537,7 +539,7 @@  config PWM_VT8500
 
 config PWM_ZX
 	tristate "ZTE ZX PWM support"
-	depends on ARCH_ZX
+	depends on ARCH_ZX || COMPILE_TEST
 	help
 	  Generic PWM framework driver for ZTE ZX family SoCs.