Re: OMAP3 kernels fail to build
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
* Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
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. vv 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 kernels fail to build
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
+ 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
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. vv 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 s...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
