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 [email protected]
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
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
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
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