| Message ID | 20191230172113.17222-2-krzk@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] pwm: Fix minor Kconfig whitespace issues | expand |
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!
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
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>
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
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
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
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
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
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
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
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 --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.
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(-)