OMAP3 kernels fail to build

PATCH New Russell King - ARM Linux 6 participants 12 messages Aug 8, 2011 – Sep 28, 2011

Subsystems (3)

Arm (32-bit) Arm sub-architectures OMAP2+ support

lore

Share & tools

lore

Russell King - ARM Linux

author

2011-08-08 11:00 UTC #0 lore raw

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

Santosh

2011-08-08 11:09 UTC #1 lore raw

+ Felipe,

Quoted 8 lines · 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'

I thought below patch was suppose to fix it.
https://patchwork.kernel.org/patch/963462/

Regards
Santosh

Russell King - ARM Linux

author

2011-08-08 11:30 UTC #2 lore raw

Quoted 5 lines · Santosh

+ Felipe,
Quoted 2 lines · Russell King - ARM Linux
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:

Quoted 8 lines

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

Tony Lindgren

maintainer

2011-08-09 13:16 UTC #3 lore raw

Quoted 18 lines · Russell King - ARM Linux

Quoted 5 lines · Santosh
+ Felipe,
Quoted 2 lines · Russell King - ARM Linux
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
Quoted 8 lines
Quoted 6 lines
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.

Quoted 6 lines

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

Paul Walmsley

2011-08-10 05:26 UTC #4 lore raw

In reply to Russell King - ARM Linux

Quoted 10 lines · Russell King - ARM Linux

Quoted 9 lines · Santosh
Quoted 8 lines · 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'

Quoted 5 lines

Quoted 2 lines
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.

Quoted 3 lines

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

Russell King - ARM Linux

author

2011-08-10 07:27 UTC #5 lore raw

Quoted 18 lines · Paul Walmsley

Quoted 10 lines · Russell King - ARM Linux
Quoted 9 lines · Santosh
Quoted 8 lines · 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'
Quoted 5 lines
Quoted 2 lines
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.

Quoted 6 lines

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.

Tony Lindgren

maintainer

2011-08-10 09:18 UTC #6 lore raw

Quoted 26 lines · Russell King - ARM Linux

Quoted 18 lines · Paul Walmsley
Quoted 10 lines · Russell King - ARM Linux
Quoted 9 lines · Santosh
Quoted 8 lines · 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'
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
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.

Quoted 5 lines

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

Péter Ujfalusi

2011-08-09 11:17 UTC #7 lore raw

In reply to Russell King - ARM Linux

Hi Russel,

Quoted 11 lines · 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'

Quoted 6 lines

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...

Quoted 3 lines

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?

Signature · 1 line

P?ter

Peter Ujfalusi

2011-08-09 12:36 UTC #8 lore raw

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

In reply to Russell King - ARM Linux

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:

Signed-off-by Peter Ujfalusi <[email protected]>

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(-)

arch/arm/mach-omap2/twl-common.c +41 ~~-37~~

index 2543342..daa056e 100644
@@ -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 */

Signature · 1 line

1.7.6

Tony Lindgren

maintainer

2011-08-10 09:15 UTC #9 lore raw

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

Quoted 12 lines · 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'

Quoted 6 lines

Signed-off-by Peter Ujfalusi <[email protected]>
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 <[email protected]>
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:

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

Signed-off-by Peter Ujfalusi <[email protected]>

[tony at atomide.com: updated comments]

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/twl-common.c +41 ~~-37~~

index 2543342..daa056e 100644
@@ -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 */

Michael Jones

2011-08-11 15:07 UTC #10 lore raw

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

Hi,

Quoted 23 lines · Tony Lindgren

Quoted 12 lines · 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'
Quoted 6 lines
Signed-off-by Peter Ujfalusi <[email protected]>
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.

Quoted 9 lines

Regards,
Tony
From: Peter Ujfalusi <[email protected]>
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

Tony Lindgren

maintainer

2011-09-28 18:28 UTC #11 lore raw

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

Hi,

Sorry for the delay in replying..

Quoted 11 lines · Michael Jones

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