Subject: Re: linux-next: build failure after merge of the spi tree

From: Stephen Rothwell <[email-masked]>
Date: Mon, 29 Jul 2013 15:56:09 +1000

Hi Mark,

On Mon, 29 Jul 2013 06:00:11 +0100 Mark Brown <[email-masked]> wrote:
>
> On Mon, Jul 29, 2013 at 01:42:23PM +1000, Stephen Rothwell wrote:
> 
> > drivers/spi/spi-pxa2xx-pxadma.c: In function 'wait_dma_channel_stop':
> > drivers/spi/spi-pxa2xx-pxadma.c:136:2: error: implicit declaration of function 'DCSR' [-Werror=implicit-function-declaration]
> >   while (!(DCSR(channel) & DCSR_STOPSTATE) && --limit)
> 
> > Frankly, Mark, if you are unable or unwilling to do some basic cross
> > build testing, please do not do any more of these patches that add
> > CONFIG_COMPILE_TEST.  Leave them to someone who can.
> 
> This was cross built.  It didn't show up due to the fact that the
> minimal configs I use for build coverage (and in fact every single
> config I was building) didn't have PCI turned on (which is a dependency
> for this option actually building anything) which allowed this config
> symbol to be enabled without showing the problem due to the slightly odd
> way the config for the driver is structured; any system with PCI that's
> not PXA would be affected.
> 
> Most (though not all) of the other issues have been due to similar
> stuff.  I do rely on the 0 day tester for the full builds but I do pretty
> routinely test (especially on x86) these days though with minimal
> configs and on my full working tree.

Did the 0 day tester find these?  If so, then maybe you should wait a
while longer before adding these things to your published trees.  If not,
then I wonder why not.

Even so as a developer, you should not really be submitting patches that
have not been at least build tested.   You can find out which files are
affected by these config changes and then really simply do:
(assuming an x86 native platform - adjust for cross compiling)

$ mkdir ../test.obj
$ make O=../test.obj allmodconfig
<make sure that the CONFIG options got turned on>
$ make O=../test.obj <files affected s/.c/.o/>

You don't need to do full builds to find most of this stuff.  Of course,
this will not find link time errors or missing module symbols.
-- 
Cheers,
Stephen Rothwell                    [email-masked]