OMAP3 kernels fail to build

OMAP3 kernels fail to build

[Russell King - ARM Linux]

With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:

arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'

This is probably from twl-common.c, which doesn't really look very
common to me (looks like some is specific to OMAP3 and the rest is
OMAP4 specific.)

As this is always built for all OMAP2+, this will also break OMAP2 as
well.  Why it's even built on OMAP2, I've no idea.

I think the OMAP3 specific bits should be separate from the OMAP4
specific bits, which should be separate from the small amount of
common stuff.

Please either fix ASAP, or revert the five changes for twl-common.c

OMAP3 kernels fail to build

[Santosh]

+ Felipe,

On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
>
> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
>
I thought below patch was suppose to fix it.
https://patchwork.kernel.org/patch/963462/


Regards
Santosh

OMAP3 kernels fail to build

[Russell King - ARM Linux]

On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> + Felipe,
>
> On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
>> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
>>
>> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
>>
> I thought below patch was suppose to fix it.
> https://patchwork.kernel.org/patch/963462/

So, the problem has been known about for around a month.  Yet the broken
patch still went upstream.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
IF IT IS KNOWN THAT A PATCH IS BROKEN IT MUST NOT BE SUBMITTED TO MAINLINE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We've seen other instances of that during this merge window, and Linus
has responded thusly to these incidents:

http://lkml.org/lkml/2011/8/4/390

    On Thu, Aug 4, 2011 at 2:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
    >
    > The last three commits in the idle tree that you took from Len were in
    > linux-next until April 15 and then disappeared until yesterday. ?The last
    > of these was broken back then and has been committed exactly the same now
    > and still breaks arm and sh.
    >
    > I have reverted that commit from your tree for today ...

    Len, this is *exactly* why I com plained about the git trees you pushed to me.

    And then I pulled anyway, because you and others convinced me things
    had been in -next despite the commit dates being odd.

    Let's just say that I'm really *really* disappointed. And dammit, you
    need to fix your workflow. Don't add random commits late. If you're
    offline, you're offline, and you send the old tested tree, not some
    last-minute crap.

    Next time I find reason to complain, I just won't pull.  In fact, I'm
    seriously considering a rather draconian measure for next merge
    window: I'll fetch the -next tree when I open the merge window, and if
    I get anything but trivial fixes that don't show up in that "next tree
    at the point of merge window open", I'll just ignore that pull
    request. Because clearly people are just not being careful enough.

    It's really *very* annoying to hear that a bug has been known about
    for weeks (or months) and just not fixed, and then shows up again THE
    SAME DAY that the pull request is sent to me.

                      Linus

OMAP3 kernels fail to build

[Péter Ujfalusi]

Hi Russel,

On Monday 08 August 2011 13:00:56 Russell King - ARM Linux wrote:
> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> 
> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
> `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0):
> undefined reference to `omap4430_phy_exit'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
> `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf9a8):
> undefined reference to `omap4430_phy_set_clk'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
> `omap4430_phy_suspend'
>
> This is probably from twl-common.c, which doesn't really look very
> common to me (looks like some is specific to OMAP3 and the rest is
> OMAP4 specific.)
> 
> As this is always built for all OMAP2+, this will also break OMAP2 as
> well.  Why it's even built on OMAP2, I've no idea.

I'm sure if you have it other way around (OMAP4=y, OMAP3=n) will fail as well, 
but differently...

> I think the OMAP3 specific bits should be separate from the OMAP4
> specific bits, which should be separate from the small amount of
> common stuff.

Is it acceptable if I use
#if defined(CONFIG_ARCH_OMAP3), and
#if defined(CONFIG_ARCH_OMAP4)

to protect the OMAP3 and OMAP4 related code in the twl-common.c?

-- 
P?ter

[PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

[Peter Ujfalusi]

Avoid compiling code for OMAP arch which is not selected by the
config.

Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:

arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Hi Russel, Tony,

This patch fixes the linking error caused by the twl-common.c file,
when the kernel is built for OMAP2/3/4 only.

Regards,
Peter
---
 arch/arm/mach-omap2/twl-common.c |   78 ++++++++++++++++++++------------------
 1 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..daa056e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,14 +48,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
 	omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
 }
 
-static struct twl4030_usb_data omap4_usb_pdata = {
-	.phy_init	= omap4430_phy_init,
-	.phy_exit	= omap4430_phy_exit,
-	.phy_power	= omap4430_phy_power,
-	.phy_set_clock	= omap4430_phy_set_clk,
-	.phy_suspend	= omap4430_phy_suspend,
-};
-
+#if defined(CONFIG_ARCH_OMAP3)
 static struct twl4030_usb_data omap3_usb_pdata = {
 	.usb_mode	= T2_USB_MODE_ULPI,
 };
@@ -122,6 +115,45 @@ static struct regulator_init_data omap3_vpll2_idata = {
 	.consumer_supplies		= omap3_vpll2_supplies,
 };
 
+void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
+				  u32 pdata_flags, u32 regulators_flags)
+{
+	if (!pmic_data->irq_base)
+		pmic_data->irq_base = TWL4030_IRQ_BASE;
+	if (!pmic_data->irq_end)
+		pmic_data->irq_end = TWL4030_IRQ_END;
+
+	/* Common platform data configurations */
+	if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
+		pmic_data->usb = &omap3_usb_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
+		pmic_data->bci = &omap3_bci_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
+		pmic_data->madc = &omap3_madc_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
+		pmic_data->audio = &omap3_audio_pdata;
+
+	/* Common regulator configurations */
+	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
+		pmic_data->vdac = &omap3_vdac_idata;
+
+	if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
+		pmic_data->vpll2 = &omap3_vpll2_idata;
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP4)
+static struct twl4030_usb_data omap4_usb_pdata = {
+	.phy_init	= omap4430_phy_init,
+	.phy_exit	= omap4430_phy_exit,
+	.phy_power	= omap4430_phy_power,
+	.phy_set_clock	= omap4430_phy_set_clk,
+	.phy_suspend	= omap4430_phy_suspend,
+};
+
 static struct regulator_init_data omap4_vdac_idata = {
 	.constraints = {
 		.min_uV			= 1800000,
@@ -273,32 +305,4 @@ void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
 	    !pmic_data->clk32kg)
 		pmic_data->clk32kg = &omap4_clk32kg_idata;
 }
-
-void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
-				  u32 pdata_flags, u32 regulators_flags)
-{
-	if (!pmic_data->irq_base)
-		pmic_data->irq_base = TWL4030_IRQ_BASE;
-	if (!pmic_data->irq_end)
-		pmic_data->irq_end = TWL4030_IRQ_END;
-
-	/* Common platform data configurations */
-	if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
-		pmic_data->usb = &omap3_usb_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
-		pmic_data->bci = &omap3_bci_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
-		pmic_data->madc = &omap3_madc_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
-		pmic_data->audio = &omap3_audio_pdata;
-
-	/* Common regulator configurations */
-	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
-		pmic_data->vdac = &omap3_vdac_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
-		pmic_data->vpll2 = &omap3_vpll2_idata;
-}
+#endif /* CONFIG_ARCH_OMAP4 */
-- 
1.7.6

OMAP3 kernels fail to build

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110808 04:25]:
> On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > + Felipe,
> >
> > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> >>
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
> >>
> > I thought below patch was suppose to fix it.
> > https://patchwork.kernel.org/patch/963462/
> 
> So, the problem has been known about for around a month.  Yet the broken
> patch still went upstream.
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> IF IT IS KNOWN THAT A PATCH IS BROKEN IT MUST NOT BE SUBMITTED TO MAINLINE
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> We've seen other instances of that during this merge window, and Linus
> has responded thusly to these incidents:

Sorry I guess I just went into vacation mode and stopped applying patches.

Regards,

Tony

OMAP3 kernels fail to build

[Paul Walmsley]

On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:

> On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> >>
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
> >>
> > I thought below patch was suppose to fix it.
> > https://patchwork.kernel.org/patch/963462/
> 
> So, the problem has been known about for around a month.  Yet the broken
> patch still went upstream.

Which known "broken patch still went upstream" ?

The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c ("usb: 
otg: OMAP4430: Powerdown the internal PHY when USB is disabled") and 
fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power down 
the PHY during board init").  The above link makes this clear.  

> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> IF IT IS KNOWN THAT A PATCH IS BROKEN IT MUST NOT BE SUBMITTED TO MAINLINE
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is certainly good advice when it's relevant.


- Paul

OMAP3 kernels fail to build

[Russell King - ARM Linux]

On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
> On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
> 
> > On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> > >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> > >>
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
> > >>
> > > I thought below patch was suppose to fix it.
> > > https://patchwork.kernel.org/patch/963462/
> > 
> > So, the problem has been known about for around a month.  Yet the broken
> > patch still went upstream.
> 
> Which known "broken patch still went upstream" ?
> 
> The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c ("usb: 
> otg: OMAP4430: Powerdown the internal PHY when USB is disabled") and 
> fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power down 
> the PHY during board init").  The above link makes this clear.  

The fact that there are _build_ _errors_ indicate that a patch which
introduced this crap _was_ _broken_.  The fact that it was _reported_
as broken well before the merge window and still went in during the
merge window indicates that the OMAP workflow with regard to patches
is simply BROKEN.

And the fact that you can't recognise that makes _you_ part of the
problem.

There are no excuses for this.

And more - wtf those commit IDs you mention have to do with my build
error with twl-common.c I've no idea.  The breakage was not introduced
by either of the commits you mention, but b22f954 (OMAP4: Move common
twl6030 configuration to twl-common).

So please, stop this disinformation right now and get more of a clue.

Thanks.

[PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [110809 05:31]:
> Avoid compiling code for OMAP arch which is not selected by the
> config.
> 
> Fixes issues like:
> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> 
> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> 
> Hi Russel, Tony,
> 
> This patch fixes the linking error caused by the twl-common.c file,
> when the kernel is built for OMAP2/3/4 only.

Thanks, I'll queue this one as a fix with updated comments as below.

Regards,

Tony


From: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date: Tue, 9 Aug 2011 15:36:50 +0300
Subject: [PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

Commit b22f954 (OMAP4: Move common twl6030 configuration to twl-common)
caused compile failures for code for OMAP arch which is not selected by
the config.

Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:

arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'

Fix the problem by moving the code to ifdef sections for omap3 and omap4.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[tony at atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..daa056e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,14 +48,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
 	omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
 }
 
-static struct twl4030_usb_data omap4_usb_pdata = {
-	.phy_init	= omap4430_phy_init,
-	.phy_exit	= omap4430_phy_exit,
-	.phy_power	= omap4430_phy_power,
-	.phy_set_clock	= omap4430_phy_set_clk,
-	.phy_suspend	= omap4430_phy_suspend,
-};
-
+#if defined(CONFIG_ARCH_OMAP3)
 static struct twl4030_usb_data omap3_usb_pdata = {
 	.usb_mode	= T2_USB_MODE_ULPI,
 };
@@ -122,6 +115,45 @@ static struct regulator_init_data omap3_vpll2_idata = {
 	.consumer_supplies		= omap3_vpll2_supplies,
 };
 
+void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
+				  u32 pdata_flags, u32 regulators_flags)
+{
+	if (!pmic_data->irq_base)
+		pmic_data->irq_base = TWL4030_IRQ_BASE;
+	if (!pmic_data->irq_end)
+		pmic_data->irq_end = TWL4030_IRQ_END;
+
+	/* Common platform data configurations */
+	if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
+		pmic_data->usb = &omap3_usb_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
+		pmic_data->bci = &omap3_bci_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
+		pmic_data->madc = &omap3_madc_pdata;
+
+	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
+		pmic_data->audio = &omap3_audio_pdata;
+
+	/* Common regulator configurations */
+	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
+		pmic_data->vdac = &omap3_vdac_idata;
+
+	if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
+		pmic_data->vpll2 = &omap3_vpll2_idata;
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP4)
+static struct twl4030_usb_data omap4_usb_pdata = {
+	.phy_init	= omap4430_phy_init,
+	.phy_exit	= omap4430_phy_exit,
+	.phy_power	= omap4430_phy_power,
+	.phy_set_clock	= omap4430_phy_set_clk,
+	.phy_suspend	= omap4430_phy_suspend,
+};
+
 static struct regulator_init_data omap4_vdac_idata = {
 	.constraints = {
 		.min_uV			= 1800000,
@@ -273,32 +305,4 @@ void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
 	    !pmic_data->clk32kg)
 		pmic_data->clk32kg = &omap4_clk32kg_idata;
 }
-
-void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
-				  u32 pdata_flags, u32 regulators_flags)
-{
-	if (!pmic_data->irq_base)
-		pmic_data->irq_base = TWL4030_IRQ_BASE;
-	if (!pmic_data->irq_end)
-		pmic_data->irq_end = TWL4030_IRQ_END;
-
-	/* Common platform data configurations */
-	if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
-		pmic_data->usb = &omap3_usb_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
-		pmic_data->bci = &omap3_bci_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
-		pmic_data->madc = &omap3_madc_pdata;
-
-	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
-		pmic_data->audio = &omap3_audio_pdata;
-
-	/* Common regulator configurations */
-	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
-		pmic_data->vdac = &omap3_vdac_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
-		pmic_data->vpll2 = &omap3_vpll2_idata;
-}
+#endif /* CONFIG_ARCH_OMAP4 */

OMAP3 kernels fail to build

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110810 00:21]:
> On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
> > On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
> > 
> > > On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > > > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> > > >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> > > >>
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
> > > >>
> > > > I thought below patch was suppose to fix it.
> > > > https://patchwork.kernel.org/patch/963462/
> > > 
> > > So, the problem has been known about for around a month.  Yet the broken
> > > patch still went upstream.
> > 
> > Which known "broken patch still went upstream" ?
> > 
> > The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c ("usb: 
> > otg: OMAP4430: Powerdown the internal PHY when USB is disabled") and 
> > fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power down 
> > the PHY during board init").  The above link makes this clear.  
> 
> The fact that there are _build_ _errors_ indicate that a patch which
> introduced this crap _was_ _broken_.  The fact that it was _reported_
> as broken well before the merge window and still went in during the
> merge window indicates that the OMAP workflow with regard to patches
> is simply BROKEN.

Or people go on vacation and just drop the ball like I did :)

Anyways, the best way to detect issues like this would be to get
make randconfig working for ARM.. And then have some machines doing
that with next tree.

Tony

[PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

[Michael Jones]

Hi,

On 08/10/2011 11:15 AM, Tony Lindgren wrote:
> 
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [110809 05:31]:
>> Avoid compiling code for OMAP arch which is not selected by the
>> config.
>>
>> Fixes issues like:
>> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
>>
>> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
>> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>
>> Hi Russel, Tony,
>>
>> This patch fixes the linking error caused by the twl-common.c file,
>> when the kernel is built for OMAP2/3/4 only.
> 
> Thanks, I'll queue this one as a fix with updated comments as below.
> 
> Regards,
> 
> Tony
> 
> 
> From: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Date: Tue, 9 Aug 2011 15:36:50 +0300
> Subject: [PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds
> 
[snip]

I still stumbled upon these linker errors when building for my OMAP3
board, using the current linux-omap master branch. I inadvertently had
CONFIG_ARCH_OMAP4=y (leftover from my starting point,
omap2plus_defconfig), but didn't have any of the boards with
omap_phy_internal.o selected (OMAP_4430SDP, OMAP4_PANDA, PCM049, PCM049,
OMAP3517EVM). Maybe this isn't a concern anyway, since anybody building
with CONFIG_ARCH_OMAP4 will presumably also be building one of those
boards? I don't know if it is our goal to build successfully with every
wacky CONFIG_ combination, but I thought I would report it here just in
case.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

[PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

[Tony Lindgren]

Hi,

Sorry for the delay in replying..

* Michael Jones <michael.jones@matrix-vision.de> [110811 07:34]:
> 
> I still stumbled upon these linker errors when building for my OMAP3
> board, using the current linux-omap master branch. I inadvertently had
> CONFIG_ARCH_OMAP4=y (leftover from my starting point,
> omap2plus_defconfig), but didn't have any of the boards with
> omap_phy_internal.o selected (OMAP_4430SDP, OMAP4_PANDA, PCM049, PCM049,
> OMAP3517EVM). Maybe this isn't a concern anyway, since anybody building
> with CONFIG_ARCH_OMAP4 will presumably also be building one of those
> boards? I don't know if it is our goal to build successfully with every
> wacky CONFIG_ combination, but I thought I would report it here just in
> case.

Probably the best way is to get omap specific randconfigs going based
on something what Arnd posted few days ago. Even with the old defconfig
files we'll still be missing many corner cases.

Regards,

Tony