linux-kernel - Re: [PATCH] TWL6040: fix build error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 May 2012 12:10:05 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Sasha Levin <levinsasha928@...il.com>,
	<broonie@...nsource.wolfsonicro.com>,
	<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] TWL6040: fix build error

On 12-05-11 11:49 AM, Dmitry Torokhov wrote:
> On Fri, May 11, 2012 at 10:03:36AM -0400, Paul Gortmaker wrote:
>> On 12-05-11 03:20 AM, Dmitry Torokhov wrote:
>>> On Fri, May 11, 2012 at 10:03:51AM +0300, Peter Ujfalusi wrote:
>>>> Hi,
>>>>
>>>> On 05/11/2012 01:49 AM, Paul Gortmaker wrote:
>>>>> On Thu, May 10, 2012 at 2:44 PM, Sasha Levin <levinsasha928@...il.com> wrote:
>>>>>> 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.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/