linux-kernel - Re: [PATCH] clk: Allow drivers to build if COMPILE

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]

Message-ID: <561EA831.2070001@osg.samsung.com>
Date:	Wed, 14 Oct 2015 21:08:33 +0200
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	linux-kernel@...r.kernel.org,
	Luis de Bethencourt <luisbg@....samsung.com>,
	Michael Turquette <mturquette@...libre.com>,
	Scott Branden <sbranden@...adcom.com>,
	Ray Jui <rjui@...adcom.com>, linux-clk@...r.kernel.org
Subject: Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled

Hello Stephen,

On 10/14/2015 08:38 PM, Stephen Boyd wrote:
> On 10/13, Javier Martinez Canillas wrote:
>> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
>> index 1530c9352a76..fc50b6264bed 100644
>> --- a/drivers/clk/versatile/Kconfig
>> +++ b/drivers/clk/versatile/Kconfig
>> @@ -1,6 +1,6 @@
>>  config COMMON_CLK_VERSATILE
>>  	bool "Clock driver for ARM Reference designs"
>> -	depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
>> +	depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 || COMPILE_TEST
> 
> Have you compiled these drivers on an architecture that doesn't
> have IOMEM? Perhaps tile or um? I'm all for more build coverage,
> but it's not always as simple as just sprinkling some
> COMPILE_TEST around the Kconfigs.
>

No, I only build tested on arm32 and x86. The 0-day bot haven't reported a
build error yet and I didn't see any platform dependent code in the drivers.

But you are right that COMPILE_TEST is a little tricky, so maybe is safest
to drop this patch.

Is just that it would be nice to build as much as possible to make sure that
subystemms or kernel wide changes don't introduce regressions since that is
also tricky even when using tools like coccinelle.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/