Thread (15 messages) 15 messages, 6 authors, 2012-05-13

Re: [PATCH] TWL6040: fix build error

From: Paul Gortmaker <hidden>
Date: 2012-05-11 16:10:14
Also in: lkml

On 12-05-11 11:49 AM, Dmitry Torokhov wrote:
On Fri, May 11, 2012 at 10:03:36AM -0400, Paul Gortmaker wrote:
quoted
On 12-05-11 03:20 AM, Dmitry Torokhov wrote:
quoted
On Fri, May 11, 2012 at 10:03:51AM +0300, Peter Ujfalusi wrote:
quoted
Hi,

On 05/11/2012 01:49 AM, Paul Gortmaker wrote:
quoted
On Thu, May 10, 2012 at 2:44 PM, Sasha Levin [off-list ref] wrote:
quoted
Fixes build error due to missing of_property_read_u32.
Yes, I saw the same on x86-64 allyesconfig -- which means that in addition to
this missing header, it needs to have a Kconfig dependency that limits
it to just being enabled on the platforms where it physically is possible to
have the hardware.  I'm guessing limiting to ARM would be a good start?
Yes it is only usable on ARM, most specifically on OMAP4+ platforms.
If I make the twl6040 MFD core to depend on ARM (or even on OMAP) this
won't happen again.
Is there any other errors beside missing include of.h (and extra
of_device.h?). The driver seems to be compiling fine on x86_64 so no
need to limit to ARM only...
Hi Dmitry,

It should be limited to the platforms where the hardware is available,
so that coverage builds aren't needlessly spending cycles building
stuff that can't possibly ever be used.  Also if it is limited to
ARM, then we can't have an ARM bug like this one mask the x86_64
allyesconfig build from uncovering possible errors that we really
care about seeing.
Hi Paul,

I strongly disagree. The bug that we are talking about was not an
arch-specific bug; it eventually would have shown up on ARM with a
randconfig as well. So it is a _good_ thing that the build was not
limited just to ARM so that the bug got noticed early and fixed after
being present in -next for about a day.
I guess we'll have to agree to disagree then.  Regardless of whether
this instance coincidentally helped shine a light on some issue,
having arch specific _drivers_ built on the arch where they can never
be used makes no sense to me.  We don't try and build sparc specific
drivers on mips or vice versa.  So we shouldn't build ARM specific
code on x86 either.

Paul.
So please do not add any additional constraints; better compile coverage
is a good thing.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help