Hi Samuel,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/mfd/ab8500-core.c:21:0:
include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
include/linux/mfd/dbx500-prcmu.h:692:20: error: redefinition of 'prcmu_ac_wake_req'
include/linux/mfd/db8500-prcmu.h:683:20: note: previous definition of 'prcmu_ac_wake_req' was here
include/linux/mfd/dbx500-prcmu.h:694:20: error: redefinition of 'prcmu_ac_sleep_req'
include/linux/mfd/db8500-prcmu.h:685:20: note: previous definition of 'prcmu_ac_sleep_req' was here
Caused (exposed?) by commit d28f1db8187d ("mfd: Remove confusing
ab8500-i2c file and merge into ab8500-core"). I assume that this has
only had very restricted build testing :-(
I have used the mfd tree from next-20120511 again for today.
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen,
> After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/mfd/ab8500-core.c:21:0:
> include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
> include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
> include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
> include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
> include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
> include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
> include/linux/mfd/dbx500-prcmu.h:692:20: error: redefinition of 'prcmu_ac_wake_req'
> include/linux/mfd/db8500-prcmu.h:683:20: note: previous definition of 'prcmu_ac_wake_req' was here
> include/linux/mfd/dbx500-prcmu.h:694:20: error: redefinition of 'prcmu_ac_sleep_req'
> include/linux/mfd/db8500-prcmu.h:685:20: note: previous definition of 'prcmu_ac_sleep_req' was here
>
> Caused (exposed?) by commit d28f1db8187d ("mfd: Remove confusing
> ab8500-i2c file and merge into ab8500-core"). I assume that this has
> only had very restricted build testing :-(
The patch itself has had extensive build and run testing, with DT both
enabled and disabled. I'm guessing some other changes may be having and
influence here. I'm happy to take a look for you. Can you tell me where
I can pull the offending branch from please?
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/mfd/ab8500-core.c:21:0:
> include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
> include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
> include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
> include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
> include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
> include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
> include/linux/mfd/dbx500-prcmu.h:692:20: error: redefinition of 'prcmu_ac_wake_req'
> include/linux/mfd/db8500-prcmu.h:683:20: note: previous definition of 'prcmu_ac_wake_req' was here
> include/linux/mfd/dbx500-prcmu.h:694:20: error: redefinition of 'prcmu_ac_sleep_req'
> include/linux/mfd/db8500-prcmu.h:685:20: note: previous definition of 'prcmu_ac_sleep_req' was here
>
> Caused (exposed?) by commit d28f1db8187d ("mfd: Remove confusing
> ab8500-i2c file and merge into ab8500-core"). I assume that this has
> only had very restricted build testing :-(
I 'believe' that you 'might' be missing MFD_DB8500_PRCMU from your
config. Can you check this for me please Stephen?
MFD_DB8500_PRCMU is selected by
UX500_SOC_DB8500 is selected by
MACH_MOP500 is selected by
MACH_HREFV60 | MACH_SNOWBALL is selected by
u8500_defconfig
Can I ask how you build the kernel and which defconfig you are using please?
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On Mon, 21 May 2012 09:08:56 +0100 Lee Jones <[email protected]> wrote:
>
> The patch itself has had extensive build and run testing, with DT both
> enabled and disabled. I'm guessing some other changes may be having and
> influence here. I'm happy to take a look for you. Can you tell me where
> I can pull the offending branch from please?
The mfd tree can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git#for-next
Did you try building it for X86_64? What failed for me was an x86_64
allmodconfig.
--
Cheers,
Stephen Rothwell [email protected]
On 21/05/12 09:40, Stephen Rothwell wrote:
> Hi Lee,
>
> On Mon, 21 May 2012 09:08:56 +0100 Lee Jones<[email protected]> wrote:
>>
>> The patch itself has had extensive build and run testing, with DT both
>> enabled and disabled. I'm guessing some other changes may be having and
>> influence here. I'm happy to take a look for you. Can you tell me where
>> I can pull the offending branch from please?
>
> The mfd tree can be found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git#for-next
>
> Did you try building it for X86_64? What failed for me was an x86_64
> allmodconfig.
That seems broken to me.
Why would any of the X86_64 systems be building ab8500-core code?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On Mon, 21 May 2012 09:30:47 +0100 Lee Jones <[email protected]> wrote:
>
> > After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > In file included from drivers/mfd/ab8500-core.c:21:0:
> > include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
> > include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
> > include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
> > include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
> > include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
> > include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
> > include/linux/mfd/dbx500-prcmu.h:692:20: error: redefinition of 'prcmu_ac_wake_req'
> > include/linux/mfd/db8500-prcmu.h:683:20: note: previous definition of 'prcmu_ac_wake_req' was here
> > include/linux/mfd/dbx500-prcmu.h:694:20: error: redefinition of 'prcmu_ac_sleep_req'
> > include/linux/mfd/db8500-prcmu.h:685:20: note: previous definition of 'prcmu_ac_sleep_req' was here
> >
> > Caused (exposed?) by commit d28f1db8187d ("mfd: Remove confusing
> > ab8500-i2c file and merge into ab8500-core"). I assume that this has
> > only had very restricted build testing :-(
>
> I 'believe' that you 'might' be missing MFD_DB8500_PRCMU from your
> config. Can you check this for me please Stephen?
That is not relevent to the config I am building ...
> Can I ask how you build the kernel and which defconfig you are using please?
Its an X86_64 allmodconfig build.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Lee,
On Mon, 21 May 2012 10:01:20 +0100 Lee Jones <[email protected]> wrote:
>
> That seems broken to me.
>
> Why would any of the X86_64 systems be building ab8500-core code?
Because the Kconfig allows it to ...
--
Cheers,
Stephen Rothwell [email protected]
On 21/05/12 10:10, Stephen Rothwell wrote:
> Hi Lee,
>
> On Mon, 21 May 2012 10:01:20 +0100 Lee Jones<[email protected]> wrote:
>>
>> That seems broken to me.
>>
>> Why would any of the X86_64 systems be building ab8500-core code?
>
> Because the Kconfig allows it to ...
I think the issue may be on the x86 side. In -next I see:
> arch/arm/configs/u8500_defconfig:CONFIG_AB8500_CORE=y
> drivers/mfd/Kconfig:config AB8500_CORE
Expected
> drivers/gpio/Kconfig: depends on AB8500_CORE && BROKEN
> drivers/input/misc/Kconfig: depends on AB8500_CORE
> drivers/mfd/Kconfig: depends on AB8500_CORE && MFD_DB8500_PRCMU
> drivers/mfd/Kconfig: depends on AB8500_CORE && DEBUG_FS
> drivers/mfd/Kconfig: depends on AB8500_CORE && REGULATOR_AB8500
> drivers/misc/Kconfig: depends on AB8500_CORE && ARCH_U8500
> drivers/power/Kconfig: depends on AB8500_CORE && AB8500_GPADC
> drivers/regulator/Kconfig: depends on AB8500_CORE
> drivers/rtc/Kconfig: depends on AB8500_CORE
> drivers/usb/otg/Kconfig: depends on AB8500_CORE
I've just checked these, they are all AB8500 related Kconfig entries.
> include/linux/mfd/abx500/ab8500-sysctrl.h:#ifdef CONFIG_AB8500_CORE
> include/linux/mfd/abx500/ab8500-sysctrl.h:#endif /* CONFIG_AB8500_CORE */
> drivers/mfd/Makefile:obj-$(CONFIG_AB8500_CORE) += ab8500-core.o ab8500-sysctrl.o
So somewhere along the line an X86 config is selecting CONFIG_AB8500_CORE when it shouldn't.
I can't see anything relevant in my tree. I'll try to pull yours as have a look.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Mon, May 21, 2012 at 10:19:32AM +0100, Lee Jones wrote:
> > include/linux/mfd/abx500/ab8500-sysctrl.h:#endif /* CONFIG_AB8500_CORE */
>
> > drivers/mfd/Makefile:obj-$(CONFIG_AB8500_CORE) += ab8500-core.o ab8500-sysctrl.o
> So somewhere along the line an X86 config is selecting CONFIG_AB8500_CORE when it shouldn't.
> I can't see anything relevant in my tree. I'll try to pull yours as have a look.
Since there's no dependencies which would stop it being selected
anything like allyesconfig or randconfig might enable it. In general
it's normal to allow this in order to make it easier to build test
things like subsystem wide changes.
> Since there's no dependencies which would stop it being selected
> anything like allyesconfig or randconfig might enable it. In general
> it's normal to allow this in order to make it easier to build test
> things like subsystem wide changes.
Ah, I see. In which case Stephen was correct in that it's an issue with
Kconfig logic (but not an issue with the patch alluded to). I'm going to
have to pass this one over to Linus (CC'ed), as it's his train-set and I
don't want to do the wrong thing.
Linus,
When CONFIG_AB8500_CORE is set, building ab8500-core.c and
!(CONFIG_UX500_SOC_DB8500 | CONFIG_MFD_DB8500_PRCMU), both
db8500-prcmu.h and dbx500-prcmu.h take it upon themselves to _both_
create 'return 0' inline functions for the following:
prcmu_abb_read()
prcmu_abb_write()
prcmu_config_clkout()
prcmu_ac_wake_req()
prcmu_ac_sleep_req()
I think we need a Kconfig rule to prevent this from happening, but I'm
not sure what the correct logic would be. The other option would be to
explicitly include db8500-prcmu.h instead of dbx500-prcmu.h in
ab0500-core.c (which in turn includes db8500-prcmu.h (and used to
include db5500-prcmu.h)), but this seems wrong to me.
As you have a clearer insight to these things would you care to take
this on?
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On Mon, May 21, 2012 at 11:28:23AM +0100, Lee Jones wrote:
> When CONFIG_AB8500_CORE is set, building ab8500-core.c and
> !(CONFIG_UX500_SOC_DB8500 | CONFIG_MFD_DB8500_PRCMU), both
> db8500-prcmu.h and dbx500-prcmu.h take it upon themselves to _both_
> create 'return 0' inline functions for the following:
>
> prcmu_abb_read()
> prcmu_abb_write()
> prcmu_config_clkout()
> prcmu_ac_wake_req()
> prcmu_ac_sleep_req()
>
> I think we need a Kconfig rule to prevent this from happening, but
> I'm not sure what the correct logic would be.
Do you want the above routines to be NOOPs when !CONFIG_MFD_DB8500_PRCMU or
when !CONFIG_UX500_SOC_DB8500 ? It would make more sense to define them as
NOOP when !CONFIG_MFD_DB8500_PRCMU and remove all those definitions from
dbx500-prmcu.h
But I may be missing some of your architecture dependencies.
Something like that:
diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index d7674eb..8515547 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -366,12 +366,8 @@ static inline void prcmu_get_abb_event_buffer(void __iomem **buf)
db8500_prcmu_get_abb_event_buffer(buf);
}
-int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size);
-int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size);
int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask, u8 size);
-int prcmu_config_clkout(u8 clkout, u8 source, u8 div);
-
static inline int prcmu_request_clock(u8 clock, bool enable)
{
if (cpu_is_u5500())
@@ -447,8 +443,6 @@ static inline u16 prcmu_get_reset_code(void)
return db8500_prcmu_get_reset_code();
}
-void prcmu_ac_wake_req(void);
-void prcmu_ac_sleep_req(void);
static inline void prcmu_modem_reset(void)
{
if (cpu_is_u5500())
@@ -611,27 +605,12 @@ static inline void prcmu_enable_wakeups(u32 wakeups) {}
static inline void prcmu_disable_wakeups(void) {}
-static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
-{
- return -ENOSYS;
-}
-
-static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
-{
- return -ENOSYS;
-}
-
static inline int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask,
u8 size)
{
return -ENOSYS;
}
-static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
-{
- return 0;
-}
-
static inline int prcmu_request_clock(u8 clock, bool enable)
{
return 0;
@@ -689,10 +668,6 @@ static inline u16 prcmu_get_reset_code(void)
return 0;
}
-static inline void prcmu_ac_wake_req(void) {}
-
-static inline void prcmu_ac_sleep_req(void) {}
-
static inline void prcmu_modem_reset(void) {}
static inline bool prcmu_is_ac_wake_requested(void)
I would appreciate if we could have a fix for this one sooner than later as
I'm planning to send my pull request by the end of this week.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Hi Samuel,
On Wed, 23 May 2012 00:42:14 +0200 Samuel Ortiz <[email protected]> wrote:
>
> I would appreciate if we could have a fix for this one sooner than later as
> I'm planning to send my pull request by the end of this week.
Just so you know, nothing you have added to your tree since May 11 has
been in linux-next due to 3 separate build problems. As far as I can see
the same will be true today due to the problem you were discussing here.
You quickest way forward may be to either revert commit d28f1db8187d
("mfd: Remove confusing ab8500-i2c file and merge into ab8500-core") (if
possible) or make the building of drivers/mfd/ab8500-core.c depend on
some platform where it is clear it will build.
--
Cheers,
Stephen Rothwell [email protected]
Hi Samuel,
This should sort you out.
The old code protected under 'AB8500_I2C_CORE' depended on 'MFD_DB8500_PRCMU'.
From: Lee Jones <[email protected]>
Date: Wed, 23 May 2012 10:08:51 +0100
Subject: [PATCH] MFD: Assign MFD_DB8500_PRCMU dependency for building ab8500-core
A recent move to eliminate excess historical baggage from ab8500 core
code resulting in errors when building with x86_64 allmodconfig:
In file included from drivers/mfd/ab8500-core.c:21:0:
include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
include/linux/mfd/dbx500-prcmu.h:692:20: error: redefinition of 'prcmu_ac_wake_req'
include/linux/mfd/db8500-prcmu.h:683:20: note: previous definition of 'prcmu_ac_wake_req' was here
include/linux/mfd/dbx500-prcmu.h:694:20: error: redefinition of 'prcmu_ac_sleep_req'
include/linux/mfd/db8500-prcmu.h:685:20: note: previous definition of 'prcmu_ac_sleep_req' was here
Problem:
When CONFIG_AB8500_CORE is set, building ab8500-core.c and
!(CONFIG_UX500_SOC_DB8500 | CONFIG_MFD_DB8500_PRCMU), both db8500-prcmu.h
and dbx500-prcmu.h take it upon themselves to _both_ create 'return 0'
inline functions for the following:
prcmu_abb_read()
prcmu_abb_write()
prcmu_config_clkout()
prcmu_ac_wake_req()
prcmu_ac_sleep_req()
Solution:
Depend on MFD_DB8500_PRCMU, which in turn depends on UX500_SOC_DB8500.
Reported-By: Stephen Rothwell <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/mfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9846424..43e6142 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -683,7 +683,7 @@ config EZX_PCAP
config AB8500_CORE
bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
- depends on GENERIC_HARDIRQS && ABX500_CORE
+ depends on GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU
select MFD_CORE
help
Select this option to enable access to AB8500 power management
--
1.7.9.5
Hi Stephen,
On Wed, May 23, 2012 at 08:52:26AM +1000, Stephen Rothwell wrote:
> Hi Samuel,
>
> On Wed, 23 May 2012 00:42:14 +0200 Samuel Ortiz <[email protected]> wrote:
> >
> > I would appreciate if we could have a fix for this one sooner than later as
> > I'm planning to send my pull request by the end of this week.
>
> Just so you know, nothing you have added to your tree since May 11 has
> been in linux-next due to 3 separate build problems. As far as I can see
> the same will be true today due to the problem you were discussing here.
I applied a fix for this one, and a couple of other commits for 2 more build
failures. The mfd tree should build fine now.
Sorry for the delay.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/