linux-next: build failure after merge of the final tree (pwm tree related)

linux-next: build failure after merge of the final tree (pwm tree related)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/mfd/built-in.o: In function `__crc_pwm_free':
(*ABS*+0x15ee601): multiple definition of `__crc_pwm_free'
drivers/mfd/built-in.o: In function `.pwm_free':
(.text+0x187a0): multiple definition of `.pwm_free'
drivers/pwm/built-in.o:(.text+0x740): first defined here
drivers/mfd/built-in.o: In function `__crc_pwm_request':
(*ABS*+0xaee34e3d): multiple definition of `__crc_pwm_request'
drivers/mfd/built-in.o: In function `__crc_pwm_enable':
(*ABS*+0xd83c7949): multiple definition of `__crc_pwm_enable'
drivers/mfd/built-in.o: In function `.pwm_enable':
(.text+0x18800): multiple definition of `.pwm_enable'
drivers/pwm/built-in.o:(.text+0xbc): first defined here
drivers/mfd/built-in.o: In function `.pwm_request':
(.text+0x1858c): multiple definition of `.pwm_request'
drivers/pwm/built-in.o:(.text+0x1178): first defined here
drivers/mfd/built-in.o: In function `pwm_config':
(.opd+0x2970): multiple definition of `pwm_config'
drivers/pwm/built-in.o:(.opd+0x0): first defined here
drivers/mfd/built-in.o: In function `pwm_free':
(.opd+0x29b8): multiple definition of `pwm_free'
drivers/pwm/built-in.o:(.opd+0xf0): first defined here
drivers/mfd/built-in.o: In function `pwm_request':
(.opd+0x2988): multiple definition of `pwm_request'
drivers/pwm/built-in.o:(.opd+0x180): first defined here
drivers/mfd/built-in.o: In function `__crc_pwm_disable':
(*ABS*+0xa4ee3c79): multiple definition of `__crc_pwm_disable'
drivers/mfd/built-in.o: In function `.pwm_disable':
(.text+0x186b8): multiple definition of `.pwm_disable'
drivers/pwm/built-in.o:(.text+0x198): first defined here
drivers/mfd/built-in.o: In function `pwm_enable':
(.opd+0x29d0): multiple definition of `pwm_enable'
drivers/pwm/built-in.o:(.opd+0x18): first defined here
drivers/mfd/built-in.o: In function `.pwm_config':
(.text+0x184a4): multiple definition of `.pwm_config'
drivers/pwm/built-in.o:(.text+0x0): first defined here
drivers/mfd/built-in.o: In function `pwm_disable':
(.opd+0x29a0): multiple definition of `pwm_disable'
drivers/pwm/built-in.o:(.opd+0x30): first defined here
drivers/mfd/built-in.o: In function `__crc_pwm_config':
(*ABS*+0xdeebfb06): multiple definition of `__crc_pwm_config'

Caused by commit 0c2498f16608 ("pwm: Add PWM framework support").  There
are (e.g.) definitions of pwm_free in arch/mips/jz4740/pwm.c,
arch/unicore32/kernel/pwm.c, drivers/mfd/twl6030-pwm.c,
drivers/misc/ab8500-pwm.c and now drivers/pwm/core.c.   Four of these are
EXPORTed.

I have just left this broken for today - please investigate a solution
quickly.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

On Fri, Jun 29, 2012 at 05:48:26PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/mfd/built-in.o: In function `__crc_pwm_free':
> (*ABS*+0x15ee601): multiple definition of `__crc_pwm_free'
> drivers/mfd/built-in.o: In function `.pwm_free':
> (.text+0x187a0): multiple definition of `.pwm_free'
> drivers/pwm/built-in.o:(.text+0x740): first defined here
> drivers/mfd/built-in.o: In function `__crc_pwm_request':
> (*ABS*+0xaee34e3d): multiple definition of `__crc_pwm_request'
> drivers/mfd/built-in.o: In function `__crc_pwm_enable':
> (*ABS*+0xd83c7949): multiple definition of `__crc_pwm_enable'
> drivers/mfd/built-in.o: In function `.pwm_enable':
> (.text+0x18800): multiple definition of `.pwm_enable'
> drivers/pwm/built-in.o:(.text+0xbc): first defined here
> drivers/mfd/built-in.o: In function `.pwm_request':
> (.text+0x1858c): multiple definition of `.pwm_request'
> drivers/pwm/built-in.o:(.text+0x1178): first defined here
> drivers/mfd/built-in.o: In function `pwm_config':
> (.opd+0x2970): multiple definition of `pwm_config'
> drivers/pwm/built-in.o:(.opd+0x0): first defined here
> drivers/mfd/built-in.o: In function `pwm_free':
> (.opd+0x29b8): multiple definition of `pwm_free'
> drivers/pwm/built-in.o:(.opd+0xf0): first defined here
> drivers/mfd/built-in.o: In function `pwm_request':
> (.opd+0x2988): multiple definition of `pwm_request'
> drivers/pwm/built-in.o:(.opd+0x180): first defined here
> drivers/mfd/built-in.o: In function `__crc_pwm_disable':
> (*ABS*+0xa4ee3c79): multiple definition of `__crc_pwm_disable'
> drivers/mfd/built-in.o: In function `.pwm_disable':
> (.text+0x186b8): multiple definition of `.pwm_disable'
> drivers/pwm/built-in.o:(.text+0x198): first defined here
> drivers/mfd/built-in.o: In function `pwm_enable':
> (.opd+0x29d0): multiple definition of `pwm_enable'
> drivers/pwm/built-in.o:(.opd+0x18): first defined here
> drivers/mfd/built-in.o: In function `.pwm_config':
> (.text+0x184a4): multiple definition of `.pwm_config'
> drivers/pwm/built-in.o:(.text+0x0): first defined here
> drivers/mfd/built-in.o: In function `pwm_disable':
> (.opd+0x29a0): multiple definition of `pwm_disable'
> drivers/pwm/built-in.o:(.opd+0x30): first defined here
> drivers/mfd/built-in.o: In function `__crc_pwm_config':
> (*ABS*+0xdeebfb06): multiple definition of `__crc_pwm_config'
> 
> Caused by commit 0c2498f16608 ("pwm: Add PWM framework support").  There
> are (e.g.) definitions of pwm_free in arch/mips/jz4740/pwm.c,
> arch/unicore32/kernel/pwm.c, drivers/mfd/twl6030-pwm.c,
> drivers/misc/ab8500-pwm.c and now drivers/pwm/core.c.   Four of these are
> EXPORTed.
> 
> I have just left this broken for today - please investigate a solution
> quickly.

I hadn't thought about the allyesconfig case yet. Adding a "depends on
!HAVE_PWM" to the PWM symbol should work and is the easiest fix to this
kind of problem while other PWM legacy API implementations are ported to
the PWM subsystem.

Sascha, Arnd (Cc'ed): what do you think?

I don't know if I'll get enough time to test this over the weekend but I
should get to it when I'm back in the office on Monday.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Saturday 30 June 2012, Thierry Reding wrote:
> I hadn't thought about the allyesconfig case yet. Adding a "depends on
> !HAVE_PWM" to the PWM symbol should work and is the easiest fix to this
> kind of problem while other PWM legacy API implementations are ported to
> the PWM subsystem.
> 
> Sascha, Arnd (Cc'ed): what do you think?
> 
> I don't know if I'll get enough time to test this over the weekend but I
> should get to it when I'm back in the office on Monday.
> 
You cannot depend on a symbol in the same place that provides it -- that
would be a recursive dependency (or a paradox).

I think that all the drivers that are not converted to the common PWM
layer yet should depend on not enabling the common code. Once they
are all moved over, that dependency will go away.

	Arnd

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Sat, Jun 30, 2012 at 07:20:21PM +0000, Arnd Bergmann wrote:
> On Saturday 30 June 2012, Thierry Reding wrote:
> > I hadn't thought about the allyesconfig case yet. Adding a "depends on
> > !HAVE_PWM" to the PWM symbol should work and is the easiest fix to this
> > kind of problem while other PWM legacy API implementations are ported to
> > the PWM subsystem.
> > 
> > Sascha, Arnd (Cc'ed): what do you think?
> > 
> > I don't know if I'll get enough time to test this over the weekend but I
> > should get to it when I'm back in the office on Monday.
> > 
> You cannot depend on a symbol in the same place that provides it -- that
> would be a recursive dependency (or a paradox).

The PWM symbol doesn't provide HAVE_PWM.

> I think that all the drivers that are not converted to the common PWM
> layer yet should depend on not enabling the common code. Once they
> are all moved over, that dependency will go away.

Right. That's exactly what I meant. If we add depends on !HAVE_PWM to
the PWM symbol that should result in both options conflicting, and
therefore not being built at the same time.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Saturday 30 June 2012, Thierry Reding wrote:
> > I think that all the drivers that are not converted to the common PWM
> > layer yet should depend on not enabling the common code. Once they
> > are all moved over, that dependency will go away.
> 
> Right. That's exactly what I meant. If we add depends on !HAVE_PWM to
> the PWM symbol that should result in both options conflicting, and
> therefore not being built at the same time.

But I would add it to all other ones then, not the generic one!

One question though: if the generic pwm implementation does not set
HAVE_PWM, how can a driver check its presence?

	Arnd

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Sat, Jun 30, 2012 at 08:12:32PM +0000, Arnd Bergmann wrote:
> On Saturday 30 June 2012, Thierry Reding wrote:
> > > I think that all the drivers that are not converted to the common PWM
> > > layer yet should depend on not enabling the common code. Once they
> > > are all moved over, that dependency will go away.
> > 
> > Right. That's exactly what I meant. If we add depends on !HAVE_PWM to
> > the PWM symbol that should result in both options conflicting, and
> > therefore not being built at the same time.
> 
> But I would add it to all other ones then, not the generic one!

But if we make the new PWM symbol conflict with HAVE_PWM, then it'll do
the right thing for any of the legacy PWM implementations, without
having to track them down. Furthermore it'll also keep the legacy
version by default and not allow the generic one to be enabled in that
case. This is more likely to cause less side-effects than the other way
around.

> One question though: if the generic pwm implementation does not set
> HAVE_PWM, how can a driver check its presence?

The driver depends on PWM. HAVE_PWM is the symbol for the legacy
implementations, while PWM is the new PWM API symbol.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Hi all,

On Sun, 1 Jul 2012 08:56:39 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
>
> But if we make the new PWM symbol conflict with HAVE_PWM, then it'll do
> the right thing for any of the legacy PWM implementations, without
> having to track them down. Furthermore it'll also keep the legacy
> version by default and not allow the generic one to be enabled in that
> case. This is more likely to cause less side-effects than the other way
> around.
> 
> > One question though: if the generic pwm implementation does not set
> > HAVE_PWM, how can a driver check its presence?
> 
> The driver depends on PWM. HAVE_PWM is the symbol for the legacy
> implementations, while PWM is the new PWM API symbol.

I am still getting the mutliple definition errors from my powerpc
allyesconfg build.

$ grep PWM .config
CONFIG_TWL6030_PWM=y
CONFIG_BACKLIGHT_PWM=y
CONFIG_PWM=y

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Tue, Jul 03, 2012 at 03:43:18PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Sun, 1 Jul 2012 08:56:39 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
> >
> > But if we make the new PWM symbol conflict with HAVE_PWM, then it'll do
> > the right thing for any of the legacy PWM implementations, without
> > having to track them down. Furthermore it'll also keep the legacy
> > version by default and not allow the generic one to be enabled in that
> > case. This is more likely to cause less side-effects than the other way
> > around.
> > 
> > > One question though: if the generic pwm implementation does not set
> > > HAVE_PWM, how can a driver check its presence?
> > 
> > The driver depends on PWM. HAVE_PWM is the symbol for the legacy
> > implementations, while PWM is the new PWM API symbol.
> 
> I am still getting the mutliple definition errors from my powerpc
> allyesconfg build.
> 
> $ grep PWM .config
> CONFIG_TWL6030_PWM=y
> CONFIG_BACKLIGHT_PWM=y
> CONFIG_PWM=y

I don't see how that can happen. If you have CONFIG_TWL6030_PWM=y, then
you should also have CONFIG_HAVE_PWM=y, which would in turn conflict
with CONFIG_PWM=y.

I'll have to fetch a powerpc toolchain and try to reproduce this.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

Hi Thierry,

On Tue, 3 Jul 2012 08:11:15 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
>
> I don't see how that can happen. If you have CONFIG_TWL6030_PWM=y, then
> you should also have CONFIG_HAVE_PWM=y, which would in turn conflict
> with CONFIG_PWM=y.
> 
> I'll have to fetch a powerpc toolchain and try to reproduce this.

CONFIG_HAVE_PWM only exists on arm, mips and unicore32 ... so the "select
HAVE_PWM" will not do anything on any other architecture.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Tue, Jul 03, 2012 at 04:18:46PM +1000, Stephen Rothwell wrote:
> Hi Thierry,
> 
> On Tue, 3 Jul 2012 08:11:15 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
> >
> > I don't see how that can happen. If you have CONFIG_TWL6030_PWM=y, then
> > you should also have CONFIG_HAVE_PWM=y, which would in turn conflict
> > with CONFIG_PWM=y.
> > 
> > I'll have to fetch a powerpc toolchain and try to reproduce this.
> 
> CONFIG_HAVE_PWM only exists on arm, mips and unicore32 ... so the "select
> HAVE_PWM" will not do anything on any other architecture.

So one option would be to add HAVE_PWM on powerpc, or alternatively to
explicitly add a conflict to the TWL6030_PWM symbol (and any others that
implement the legacy API). I'd think the second alternative is
preferable and actually matches what Arnd proposed previously. Maybe
this was exactly the reason he suggested that solution in the first
place.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Tuesday 03 July 2012, Thierry Reding wrote:
> On Tue, Jul 03, 2012 at 04:18:46PM +1000, Stephen Rothwell wrote:
> > Hi Thierry,
> > 
> > On Tue, 3 Jul 2012 08:11:15 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
> > >
> > > I don't see how that can happen. If you have CONFIG_TWL6030_PWM=y, then
> > > you should also have CONFIG_HAVE_PWM=y, which would in turn conflict
> > > with CONFIG_PWM=y.
> > > 
> > > I'll have to fetch a powerpc toolchain and try to reproduce this.
> > 
> > CONFIG_HAVE_PWM only exists on arm, mips and unicore32 ... so the "select
> > HAVE_PWM" will not do anything on any other architecture.
> 
> So one option would be to add HAVE_PWM on powerpc, or alternatively to
> explicitly add a conflict to the TWL6030_PWM symbol (and any others that
> implement the legacy API). I'd think the second alternative is
> preferable and actually matches what Arnd proposed previously. Maybe
> this was exactly the reason he suggested that solution in the first
> place.

It's not what I was thinking of explicitly, but it's a good
reason nonetheless ;-)

	Arnd

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]

On Tue, Jul 03, 2012 at 08:06:49AM +0000, Arnd Bergmann wrote:
> On Tuesday 03 July 2012, Thierry Reding wrote:
> > On Tue, Jul 03, 2012 at 04:18:46PM +1000, Stephen Rothwell wrote:
> > > Hi Thierry,
> > > 
> > > On Tue, 3 Jul 2012 08:11:15 +0200 Thierry Reding <thierry.reding@avionic-design.de> wrote:
> > > >
> > > > I don't see how that can happen. If you have CONFIG_TWL6030_PWM=y, then
> > > > you should also have CONFIG_HAVE_PWM=y, which would in turn conflict
> > > > with CONFIG_PWM=y.
> > > > 
> > > > I'll have to fetch a powerpc toolchain and try to reproduce this.
> > > 
> > > CONFIG_HAVE_PWM only exists on arm, mips and unicore32 ... so the "select
> > > HAVE_PWM" will not do anything on any other architecture.
> > 
> > So one option would be to add HAVE_PWM on powerpc, or alternatively to
> > explicitly add a conflict to the TWL6030_PWM symbol (and any others that
> > implement the legacy API). I'd think the second alternative is
> > preferable and actually matches what Arnd proposed previously. Maybe
> > this was exactly the reason he suggested that solution in the first
> > place.
> 
> It's not what I was thinking of explicitly, but it's a good
> reason nonetheless ;-)

I came up with the attached patch. What do you think? It fixes the
PowerPC allyesconfig issue for me.

Thierry

[-- Attachment #1.2: 0001-pwm-Conflict-with-legacy-PWM-API.patch --]
[-- Type: text/plain, Size: 1036 bytes --]

From 33859c48f1c771584312885bc37d14433bd2de7f Mon Sep 17 00:00:00 2001
From: Thierry Reding <thierry.reding@avionic-design.de>
Date: Mon, 2 Jul 2012 21:29:45 +0200
Subject: [PATCH] pwm: Conflict with legacy PWM API

In order to avoid duplicate symbols with legacy PWM API implementations,
the new PWM framework needs to conflict with any of the existing legacy
implementations. This can be removed once all legacy implementations
have been moved to the PWM subsystem.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 drivers/pwm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5227415..6e49f81 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -1,5 +1,6 @@
 menuconfig PWM
 	bool "PWM Support"
+	depends on !MACH_JZ4740 && !PUV3_NB0916 && !TWL6030_PWM && !AB8500_PWM
 	help
 	  This enables PWM support through the generic PWM framework.
 	  You only need to enable this, if you also want to enable
-- 
1.7.11.1


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Tuesday 03 July 2012, Thierry Reding wrote:
> I came up with the attached patch. What do you think? It fixes the
> PowerPC allyesconfig issue for me.

This one looks correct, but I would still do it the other way around,
putting the depends statements into the locations of the other drivers.
The main difference is that we can then independently convert the
remaining drivers, without having merge conflicts in the same line
every time we remove one of the dependencies.

	Arnd

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, Jul 03, 2012 at 08:59:11AM +0000, Arnd Bergmann wrote:
> On Tuesday 03 July 2012, Thierry Reding wrote:
> > I came up with the attached patch. What do you think? It fixes the
> > PowerPC allyesconfig issue for me.
> 
> This one looks correct, but I would still do it the other way around,
> putting the depends statements into the locations of the other drivers.
> The main difference is that we can then independently convert the
> remaining drivers, without having merge conflicts in the same line
> every time we remove one of the dependencies.

The downside of that approach, however, is to make PWM override other
settings. For instance if you have TWL6030_PWM selected and then decide
to also select PWM, then the former will be automatically deselected to
satisfy the dependency. I'm not sure if that's desired.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Tuesday 03 July 2012, Thierry Reding wrote:
>   Show Details
>   On Tue, Jul 03, 2012 at 08:59:11AM +0000, Arnd Bergmann wrote:
> > On Tuesday 03 July 2012, Thierry Reding wrote:
> > > I came up with the attached patch. What do you think? It fixes the
> > > PowerPC allyesconfig issue for me.
> > 
> > This one looks correct, but I would still do it the other way around,
> > putting the depends statements into the locations of the other drivers.
> > The main difference is that we can then independently convert the
> > remaining drivers, without having merge conflicts in the same line
> > every time we remove one of the dependencies.
> 
> The downside of that approach, however, is to make PWM override other
> settings. For instance if you have TWL6030_PWM selected and then decide
> to also select PWM, then the former will be automatically deselected to
> satisfy the dependency. I'm not sure if that's desired.

It's true that this may be confusing, but I think it's the right
approach for future multiplatform kernels. If we have e.g. a combined
omap+ux500+imx kernel, we can only have one implementation of the
PWM interfaces, and that should be the new one.

It's less clear for the other architectures. Maybe a mixed approach
is better there, making CONFIG_PWM depend on !MACH_JZ4740 &&
!PUV3_NB0916 && !BLACKFIN, but letting the remaining ARM versions
of the PWM code depend on !PWM.

	Arnd

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

On Tue, Jul 03, 2012 at 11:06:42AM +0000, Arnd Bergmann wrote:
> On Tuesday 03 July 2012, Thierry Reding wrote:
> >   Show Details
> >   On Tue, Jul 03, 2012 at 08:59:11AM +0000, Arnd Bergmann wrote:
> > > On Tuesday 03 July 2012, Thierry Reding wrote:
> > > > I came up with the attached patch. What do you think? It fixes the
> > > > PowerPC allyesconfig issue for me.
> > > 
> > > This one looks correct, but I would still do it the other way around,
> > > putting the depends statements into the locations of the other drivers.
> > > The main difference is that we can then independently convert the
> > > remaining drivers, without having merge conflicts in the same line
> > > every time we remove one of the dependencies.
> > 
> > The downside of that approach, however, is to make PWM override other
> > settings. For instance if you have TWL6030_PWM selected and then decide
> > to also select PWM, then the former will be automatically deselected to
> > satisfy the dependency. I'm not sure if that's desired.
> 
> It's true that this may be confusing, but I think it's the right
> approach for future multiplatform kernels. If we have e.g. a combined
> omap+ux500+imx kernel, we can only have one implementation of the
> PWM interfaces, and that should be the new one.

It will certainly be an incentive to port other PWM implementations to
the new framework.

> It's less clear for the other architectures. Maybe a mixed approach
> is better there, making CONFIG_PWM depend on !MACH_JZ4740 &&
> !PUV3_NB0916 && !BLACKFIN, but letting the remaining ARM versions
> of the PWM code depend on !PWM.

Yes, that would certainly be less confusing if somebody wants to build
with e.g. JZ4740 support because Kconfig will then disable the new PWM
instead of the other way around. Then again, maybe that's exactly the
opposite of what we want.

Also note that I already ported the blackfin PWM driver.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Geert Uytterhoeven]

On Sat, Jun 30, 2012 at 9:20 PM, Arnd Bergmann <arnd.bergmann@linaro.org> wrote:
> On Saturday 30 June 2012, Thierry Reding wrote:
>> I hadn't thought about the allyesconfig case yet. Adding a "depends on
>> !HAVE_PWM" to the PWM symbol should work and is the easiest fix to this
>> kind of problem while other PWM legacy API implementations are ported to
>> the PWM subsystem.
>>
>> Sascha, Arnd (Cc'ed): what do you think?
>>
>> I don't know if I'll get enough time to test this over the weekend but I
>> should get to it when I'm back in the office on Monday.
>>
> You cannot depend on a symbol in the same place that provides it -- that
> would be a recursive dependency (or a paradox).
>
> I think that all the drivers that are not converted to the common PWM
> layer yet should depend on not enabling the common code. Once they
> are all moved over, that dependency will go away.

Hence you cannot have a single kernel image that contains both legacy and new
drivers. I don't know whether there's any such combination that makes sense,
though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: build failure after merge of the final tree (pwm tree related)

[Arnd Bergmann]

On Tuesday 03 July 2012, Geert Uytterhoeven wrote:
> > I think that all the drivers that are not converted to the common PWM
> > layer yet should depend on not enabling the common code. Once they
> > are all moved over, that dependency will go away.
> 
> Hence you cannot have a single kernel image that contains both legacy and new
> drivers. I don't know whether there's any such combination that makes sense,
> though.

No, it's not a problem really: Before the new layer was added, any combination
of PWM drivers would conflict, the entire point of the common PWM code is
to make it possible that to put some drivers into the same kernel. Over time
I'd hope that all drivers get moved over, so we can have any combination.

	Arnd