public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Luis de Bethencourt <luisbg@osg.samsung.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	linux-kernel@vger.kernel.org,
	Michael Turquette <mturquette@baylibre.com>,
	Scott Branden <sbranden@broadcom.com>,
	Ray Jui <rjui@broadcom.com>,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled
Date: Thu, 15 Oct 2015 09:35:34 +0200	[thread overview]
Message-ID: <561F5746.9030302@osg.samsung.com> (raw)
In-Reply-To: <561F541D.6010006@samsung.com>

Hello Krzysztof,

On 10/15/2015 09:22 AM, Krzysztof Kozlowski wrote:
> On 15.10.2015 16:11, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>>>>
>>>>
>>>> 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.
>>>
>>> I see you guys with Luis are adding a lot of COMPILE_TEST. But
>>
>> Yes, the motivation for this was that I've been helping Mauro with a big
>> rework in the media subsystem [0] and was annoying to audit that all the
>> drivers were converted to the new APIs and no compile regressions were
>> introduced in drivers that could not be built with COMPILE_TEST enabled.
>>
>> Most media drivers are able to be build though so I thought it would be
>> a good idea to extend the build coverage in all the other subsystems.
>>
>>> building only on these two architectures *is not enough*. Run at least
>>> armv8, PPC and the x86_64. MIPS would be nice as well (I use the
>>> CodeSourcery's MIPS). All of these (ARM64, X86_64, PPC, MIPS) can be
>>> easily installed on typical debian-like Linux distro. Really easily.
>>>
>>
>> Thanks, Stephen also pointed out to the toolchains in kernel.org [1].
>>  
>>> By adding this non-tested build coverage you can actually fail some
>>> other architecture's allyesconfig/allmodconfig builds.
>>>
>>
>> Agreed, unfortunately having more build coverage is not as trivial as I
>> originally thought. Not only because it can break the build in obscure
>> archs that I don't have a toolchain to test but also exposes more build
>> warnings (as reported by the 0-day bot) that I've the bandwidth to fix.
>>
>> So personally I'll stop trying to enabled COMPILE_TEST just to be safe.
> 
> I mean that in general I agree with the idea of COMPILE_TEST. I had
> similar problems when I was changing the power supply API. Build testing
> of each modified file required a lot of effort... but it was doable. I
> just set up a configuration for build server doing all necessary archs
> and configs. With COMPILE_TEST it would be much, much easier!
>

Indeed.
 
> You don't have to give up entirely. Just use more compilers and in the
> same time fix the warnings and errors. Send a patch fixing driver and
> another one adding COMPILE_TEST.
>

Yes, although as I said, you may miss some possible build setup and I
certainly don't want to be blamed for introducing a build regression.

Additionally, maybe I can ask Fengguang if I can get a branch pulled
by 0-day build bot so I can have early feedback of the patches before
are sent to the mailing lists and first fix all the build errors and
warnings before posting, to be sure that it won't cause any issues.
 
> Best regards,
> Krzysztof
> 
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

      reply	other threads:[~2015-10-15  7:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-13 14:18 [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled Javier Martinez Canillas
2015-10-13 17:23 ` kbuild test robot
2015-10-13 17:38 ` Scott Branden
2015-10-14 18:38 ` Stephen Boyd
2015-10-14 19:08   ` Javier Martinez Canillas
2015-10-14 19:39     ` Javier Martinez Canillas
2015-10-14 21:13       ` Stephen Boyd
2015-10-16 12:18         ` Javier Martinez Canillas
2015-10-16 19:09           ` Stephen Boyd
2015-10-15  2:04     ` Krzysztof Kozlowski
2015-10-15  7:11       ` Javier Martinez Canillas
2015-10-15  7:22         ` Krzysztof Kozlowski
2015-10-15  7:35           ` Javier Martinez Canillas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=561F5746.9030302@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luisbg@osg.samsung.com \
    --cc=mturquette@baylibre.com \
    --cc=rjui@broadcom.com \
    --cc=sboyd@codeaurora.org \
    --cc=sbranden@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox