linux-next: origin tree build failure

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Hi Alan,

Today's linux-next build (x86_64 allmodconfig) failed like this:

make[3]: *** No rule to make target `drivers/serial/max3100.c', needed by `drivers/serial/max3100.o'.  Stop.

The commit 1dcb884ca8048efb4ce2999d367c26369ab2227c ("Add support for the
MAX3100 SPI UART.") added everything except the file above.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi Phillip,

On Wed, 13 Jan 2010 00:14:13 +0000 Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
>
> > Phillip, you need to merge Linus' tree (or rebase on it) and fix those up
> > for the introduction of the LZO decompression stuff.
> 
> Done.

Excellent, thanks.  I will pick it up tomorrow.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: origin tree build failure

[Phillip Lougher]

Stephen Rothwell wrote:
> On Tue, 12 Jan 2010 13:32:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> I guess there is something else in the partially
>> created linux-next today that has triggered this build failure.   I will
>> investigate further.
> 
> Yes, there are two commits in the squashfs tree that rearrange some of
> the decompression code.  They are:
> 
> "lzma: Make lzma available to non initramfs/initrd code"
> "lzma: make lzma reentrant"
> 
> Phillip, you need to merge Linus' tree (or rebase on it) and fix those up
> for the introduction of the LZO decompression stuff.
> 

Done.

Thanks

Phillip

Re: linux-next: origin tree build failure

[Joakim Tjernlund]

Stephen Rothwell <sfr@canb.auug.org.au> wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
> optimize inffast when copying direct from output").  autoconf.h moved
> from include/linux to include/generated in commit
> 264a26838056fc2d759f58bec2e720e01fcb1bdb ("kbuild: move autoconf.h to
> include/generated") which was in linux-next since 14 Dec 2009 and in
> Linus' tree since 18 Dec 2009.
>
[SNIP]
>
> This latter build problem is probably only noticed if you build with a
> separate object directory (i.e. with O=.. on the make command).  The
> previous PowerPC maintainer tells me that defining __KERNEL__ in the
> BOOTFLAGS is wrong and should have been noticed.

Is this any better w.r.t __KERNEL__?

>From 1a79993a42e17be665d3488663d81c0513b8bbfe Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 12 Jan 2010 13:31:58 +0100
Subject: [PATCH] powerpc: move __KERNEL__ define in bootwrapper.

Apparently using -D__KERNEL__ in BOOTCFLAGS is a bad thing.
Move __KERNEL__ into inffast.c where it is needed.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/powerpc/boot/Makefile |    2 +-
 lib/zlib_inflate/inffast.c |    4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 79ebd6f..766fb88 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,7 +20,7 @@
 all: $(obj)/zImage

 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-		 -fno-strict-aliasing -Os -msoft-float -pipe -D__KERNEL__\
+		 -fno-strict-aliasing -Os -msoft-float -pipe \
 		 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
 		 -isystem $(shell $(CROSS32CC) -print-file-name=include)
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 05e1559..919c162 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -2,7 +2,9 @@
  * Copyright (C) 1995-2004 Mark Adler
  * For conditions of distribution and use, see copyright notice in zlib.h
  */
-
+#ifndef __KERNEL__
+#define __KERNEL__
+#endif
 #include <linux/zutil.h>
 #include <asm/unaligned.h>
 #include <asm/byteorder.h>
--
1.6.4.4

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Tue, 12 Jan 2010 13:32:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I guess there is something else in the partially
> created linux-next today that has triggered this build failure.   I will
> investigate further.

Yes, there are two commits in the squashfs tree that rearrange some of
the decompression code.  They are:

"lzma: Make lzma available to non initramfs/initrd code"
"lzma: make lzma reentrant"

Phillip, you need to merge Linus' tree (or rebase on it) and fix those up
for the introduction of the LZO decompression stuff.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Hi Linus,

On Mon, 11 Jan 2010 17:26:33 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Hmm. I think the real problem is that it allowed LZO to be enabled at all, 
> despite HAVE_KERNEL_LZO not being enabled.
> 
> In other words, I think the config dependencies for RD_LZO are just 
> totally broken.

That may be true, however ...

OK, I grabbed your tree, reverted commit
ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib: optimize inffast when
copying direct from output") (see my other build error email) and then
the tree built.  :-(  I guess there is something else in the partially
created linux-next today that has triggered this build failure.   I will
investigate further.

Sorry about that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Tue, 12 Jan 2010, Stephen Rothwell wrote:
> 
> I then got these:
> 
> lib/decompress_unlzo.c: In function 'unlzo':
> lib/decompress_unlzo.c:106: error: 'error' undeclared (first use in this function)
> lib/decompress_unlzo.c:111: error: implicit declaration of function 'error'
> 
> So I just reverted commit
> cacb246f8db2b9eba89d44a0f0dd4f6ed93bc113 ("Add LZO compression support
> for initramfs and old-style initrd") after removing my fix above.

Hmm. I think the real problem is that it allowed LZO to be enabled at all, 
despite HAVE_KERNEL_LZO not being enabled.

In other words, I think the config dependencies for RD_LZO are just 
totally broken.

Does this work for you?

(Totally untested and not very much thought about, this is just a "that 
looks really _wrong_" kind of patch)

		Linus

---
 usr/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/usr/Kconfig b/usr/Kconfig
index e2721f5..0254cce 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -75,7 +75,7 @@ config RD_LZMA
 config RD_LZO
 	bool "Support initial ramdisks compressed using LZO" if EMBEDDED
 	default !EMBEDDED
-	depends on BLK_DEV_INITRD
+	depends on BLK_DEV_INITRD && HAVE_KERNEL_LZO
 	select DECOMPRESS_LZO
 	help
 	  Support loading of a LZO encoded initial ramdisk or cpio buffer

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

lib/decompress_unlzo.c:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'parse_header'
lib/decompress_unlzo.c:90: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'unlzo'

Caused by commit 7dd65feb6c603e13eba501c34c662259ab38e70e ("lib: add
support for LZO-compressed kernels") and commit
cacb246f8db2b9eba89d44a0f0dd4f6ed93bc113 ("Add LZO compression support
for initramfs and old-style initrd").

I can't figure out how that was supposed to build, so I added the
following patch (which is most likely not correct).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 12 Jan 2010 11:50:16 +1100
Subject: [PATCH] lib: fixup for unlzo build

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 lib/decompress_unlzo.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index db521f4..b4d423f 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -50,6 +50,10 @@ static const unsigned char lzop_magic[] = {
 #define LZO_BLOCK_SIZE        (256*1024l)
 #define HEADER_HAS_FILTER      0x00000800L
 
+#ifndef INIT
+#define INIT
+#endif
+
 STATIC inline int INIT parse_header(u8 *input, u8 *skip)
 {
 	int l;
-- 
1.6.6

I then got these:

lib/decompress_unlzo.c: In function 'unlzo':
lib/decompress_unlzo.c:106: error: 'error' undeclared (first use in this function)
lib/decompress_unlzo.c:111: error: implicit declaration of function 'error'

So I just reverted commit
cacb246f8db2b9eba89d44a0f0dd4f6ed93bc113 ("Add LZO compression support
for initramfs and old-style initrd") after removing my fix above.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: origin tree build failure

[Joakim Tjernlund]

Stephen Rothwell <sfr@canb.auug.org.au> wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
> optimize inffast when copying direct from output").  autoconf.h moved
> from include/linux to include/generated in commit
> 264a26838056fc2d759f58bec2e720e01fcb1bdb ("kbuild: move autoconf.h to
> include/generated") which was in linux-next since 14 Dec 2009 and in
> Linus' tree since 18 Dec 2009.
>
> I added the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 12 Jan 2010 10:23:43 +1100
> Subject: [PATCH] powerpc: fix boot Makefile for autoconf.h moving
>
> autoconf.h moved from include/linux to include/generated
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/powerpc/boot/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 826a30a..fb32a8e 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -34,7 +34,7 @@ BOOTCFLAGS   += -fno-stack-protector
>  endif
>
>  BOOTCFLAGS   += -I$(obj) -I$(srctree)/$(obj)
> -BOOTCFLAGS   += -include include/linux/autoconf.h -Iarch/powerpc/include
> +BOOTCFLAGS   += -include include/generated/autoconf.h -Iarch/powerpc/include
>  BOOTCFLAGS   += -Iinclude
>
>  DTS_FLAGS   ?= -p 1024
> --
> 1.6.6
>
> However, this then produced these errors:
>
> arch/powerpc/boot/inffast.c:7:27: error: asm/unaligned.h: No such file or directory
> arch/powerpc/boot/inffast.c:8:27: error: asm/byteorder.h: No such file or directory
> arch/powerpc/boot/inffast.c: In function 'inflate_fast':
> arch/powerpc/boot/inffast.c:263: warning: implicit declaration of function
> 'get_unaligned'
> arch/powerpc/boot/inffast.c:277:2: error: #error __BIG_ENDIAN nor
> __LITTLE_ENDIAN is defined
>
> So I just reverted the original commit (after removing my fix above).
>
> This latter build problem is probably only noticed if you build with a
> separate object directory (i.e. with O=.. on the make command).  The
> previous PowerPC maintainer tells me that defining __KERNEL__ in the
> BOOTFLAGS is wrong and should have been noticed.

I guess that the above problem will fixed by adding $(srctree):
BOOTCFLAGS   += -include include/generated/autoconf.h -I$(srctree)/arch/powerpc/include
BOOTCFLAGS   += -I$(srctree)/include

But what to do with the __KERNEL__ define. If it isn't allowed I
don't know what to do.

  Jocke

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

cc1: error: include/linux/autoconf.h: No such file or directory

(while building the boot wrappers - lots more of the same)

Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
optimize inffast when copying direct from output").  autoconf.h moved
from include/linux to include/generated in commit
264a26838056fc2d759f58bec2e720e01fcb1bdb ("kbuild: move autoconf.h to
include/generated") which was in linux-next since 14 Dec 2009 and in
Linus' tree since 18 Dec 2009.

I added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 12 Jan 2010 10:23:43 +1100
Subject: [PATCH] powerpc: fix boot Makefile for autoconf.h moving

autoconf.h moved from include/linux to include/generated

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/boot/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 826a30a..fb32a8e 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -34,7 +34,7 @@ BOOTCFLAGS	+= -fno-stack-protector
 endif
 
 BOOTCFLAGS	+= -I$(obj) -I$(srctree)/$(obj)
-BOOTCFLAGS	+= -include include/linux/autoconf.h -Iarch/powerpc/include
+BOOTCFLAGS	+= -include include/generated/autoconf.h -Iarch/powerpc/include
 BOOTCFLAGS	+= -Iinclude
 
 DTS_FLAGS	?= -p 1024
-- 
1.6.6

However, this then produced these errors:

arch/powerpc/boot/inffast.c:7:27: error: asm/unaligned.h: No such file or directory
arch/powerpc/boot/inffast.c:8:27: error: asm/byteorder.h: No such file or directory
arch/powerpc/boot/inffast.c: In function 'inflate_fast':
arch/powerpc/boot/inffast.c:263: warning: implicit declaration of function 'get_unaligned'
arch/powerpc/boot/inffast.c:277:2: error: #error __BIG_ENDIAN nor __LITTLE_ENDIAN is defined

So I just reverted the original commit (after removing my fix above).

This latter build problem is probably only noticed if you build with a
separate object directory (i.e. with O=.. on the make command).  The
previous PowerPC maintainer tells me that defining __KERNEL__ in the
BOOTFLAGS is wrong and should have been noticed.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

In file included from drivers/scsi/ibmvscsi/ibmvstgt.c:30:
include/scsi/libsrp.h:24: error: field 'queue' has incomplete type

Caused by commit 45465487897a1c6d508b14b904dc5777f7ec7e04 ("kfifo: move
struct kfifo in place").

I added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Dec 2009 11:44:28 +1100
Subject: [PATCH] kfifo: include linux/fifo.h in libsrp.h for definition of stuct kfifo

This fixes this compiler error:

In file included from drivers/scsi/ibmvscsi/ibmvstgt.c:30:
include/scsi/libsrp.h:24: error: field 'queue' has incomplete type

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/scsi/libsrp.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/scsi/libsrp.h b/include/scsi/libsrp.h
index 07e3add..f4105c9 100644
--- a/include/scsi/libsrp.h
+++ b/include/scsi/libsrp.h
@@ -2,6 +2,7 @@
 #define __LIBSRP_H__
 
 #include <linux/list.h>
+#include <linux/kfifo.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_host.h>
 #include <scsi/srp.h>
-- 
1.6.5.4


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: origin tree build failure

[Samuel Ortiz]

Hi Stephen,

On Wed, Dec 16, 2009 at 09:45:41AM +1100, Stephen Rothwell wrote:
> Hi Tony,
> 
> On Tue, 15 Dec 2009 09:27:17 -0800 Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [091215 06:52]:
> > > On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote:
> > > 
> > > > I have applied this patch for today (please check):
> > > 
> > > Looks good to me too, fwiw:
> > > 
> > > Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > 
> > Good thing we have for-next to catch things like this.
> 
> Except if the renaming patch had gone through linux-next (even for one
> day) we would have found the problem *before* it was in Linus' tree ...
Mea maxima culpa. I could come up with several reason why I rushed this patch
in, but none of them would be good. I apologize here.


> (/me is a little grumpy :-))
I understand, sorry again.

Cheers,
Samuel.


> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/



-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Tue, 15 Dec 2009 15:02:17 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> I think maybe Tony was being ironic, exactly because of this.

Yeah, that occurred to me just after sending the email.
Sorry, Tony.

(/me is grumpy and tired :-))

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Wed, 16 Dec 2009, Stephen Rothwell wrote:

> Hi Tony,
> 
> On Tue, 15 Dec 2009 09:27:17 -0800 Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [091215 06:52]:
> > > On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote:
> > > 
> > > > I have applied this patch for today (please check):
> > > 
> > > Looks good to me too, fwiw:
> > > 
> > > Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > 
> > Good thing we have for-next to catch things like this.
> 
> Except if the renaming patch had gone through linux-next (even for one
> day) we would have found the problem *before* it was in Linus' tree ...

I think maybe Tony was being ironic, exactly because of this.

		Linus

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Hi Tony,

On Tue, 15 Dec 2009 09:27:17 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [091215 06:52]:
> > On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote:
> > 
> > > I have applied this patch for today (please check):
> > 
> > Looks good to me too, fwiw:
> > 
> > Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> Good thing we have for-next to catch things like this.

Except if the renaming patch had gone through linux-next (even for one
day) we would have found the problem *before* it was in Linus' tree ...

(/me is a little grumpy :-))

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: origin tree build failure

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [091215 06:52]:
> On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote:
> 
> > I have applied this patch for today (please check):
> 
> Looks good to me too, fwiw:
> 
> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Good thing we have for-next to catch things like this.

Acked-by: Tony Lindgren <tony@atomide.com>

Re: linux-next: origin tree build failure

[Mark Brown]

On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote:

> I have applied this patch for today (please check):

Looks good to me too, fwiw:

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Re: linux-next: origin tree build failure

[Peter Ujfalusi]

Hello,

On Tuesday 15 December 2009 07:41:08 ext Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/mfd/twl4030-codec.c:29:31: error: linux/i2c/twl4030.h: No such file
>  or directory
> 
> (there were more, but I assume that they all stem form this one).
> 
> Caused by commit 0b83ddebc6e884dc0221358cf68c461520fbdd8e ("MFD: twl4030:
> add twl4030_codec MFD as a new child to the core") from Linus' tree
> interacting with commit b07682b6056eb6701f8cb86aa5800e6f2ea7919b ("mfd:
> Rename twl4030* driver files to enable re-use") also from Linus' tree.
> This file seems to have been missed in the renaming.

Yes, the twl4030-codec MFD driver went in earlier than the twl4030 rename patch, 
which does not taken care of the twl4030-codec MFD driver for some reasons.

The patch looks good, I might also align the twl4030-codec MFD driver with the 
renamed twl core soon.
I have to check the feasibility of this first, since the renaming was done to 
facilitate the addition of twl6030 (OMAP4 companion chip), and I don't have yet 
access to the documentation.

Thank you,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/mfd/twl4030-codec.c:29:31: error: linux/i2c/twl4030.h: No such file or directory

FYI, x86 allyesconfig fails to build too so this doesnt only affect PowerPC.

	Ingo

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/mfd/twl4030-codec.c:29:31: error: linux/i2c/twl4030.h: No such file or directory

(there were more, but I assume that they all stem form this one).

Caused by commit 0b83ddebc6e884dc0221358cf68c461520fbdd8e ("MFD: twl4030:
add twl4030_codec MFD as a new child to the core") from Linus' tree
interacting with commit b07682b6056eb6701f8cb86aa5800e6f2ea7919b ("mfd:
Rename twl4030* driver files to enable re-use") also from Linus' tree.
This file seems to have been missed in the renaming.

I have applied this patch for today (please check):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 15 Dec 2009 16:33:10 +1100
Subject: [PATCH] mfd: fix for twl4030 renaming

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/mfd/twl4030-codec.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/twl4030-codec.c b/drivers/mfd/twl4030-codec.c
index 77b9149..700b149 100644
--- a/drivers/mfd/twl4030-codec.c
+++ b/drivers/mfd/twl4030-codec.c
@@ -26,7 +26,7 @@
 #include <linux/kernel.h>
 #include <linux/fs.h>
 #include <linux/platform_device.h>
-#include <linux/i2c/twl4030.h>
+#include <linux/i2c/twl.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/twl4030-codec.h>
 
@@ -56,7 +56,7 @@ static int twl4030_codec_set_resource(enum twl4030_codec_res id, int enable)
 	struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
 	u8 val;
 
-	twl4030_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, &val,
+	twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, &val,
 			codec->resource[id].reg);
 
 	if (enable)
@@ -64,7 +64,7 @@ static int twl4030_codec_set_resource(enum twl4030_codec_res id, int enable)
 	else
 		val &= ~codec->resource[id].mask;
 
-	twl4030_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
+	twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
 					val, codec->resource[id].reg);
 
 	return val;
@@ -75,7 +75,7 @@ static inline int twl4030_codec_get_resource(enum twl4030_codec_res id)
 	struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
 	u8 val;
 
-	twl4030_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, &val,
+	twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, &val,
 			codec->resource[id].reg);
 
 	return val;
@@ -183,7 +183,7 @@ static int __devinit twl4030_codec_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "Invalid audio_mclk\n");
 		return -EINVAL;
 	}
-	twl4030_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
+	twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
 					val, TWL4030_REG_APLL_CTL);
 
 	codec = kzalloc(sizeof(struct twl4030_codec), GFP_KERNEL);
-- 
1.6.5.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/char/nvram.c: In function 'nvram_open':
drivers/char/nvram.c:332: error: implicit declaration of function 'lock_kernel'
drivers/char/nvram.c:339: error: implicit declaration of function 'unlock_kernel'

Caused by commit 9e8ab74ddaa591575f599248080a1f0d917a56ee ("nvram: Drop
the bkl from non-generic nvram_llseek()").

I do wonder why I never saw this commit in linux-next ...

I have added this the patch you posted to lkml:

From: Frederic Weisbecker <fweisbec@gmail.com>
Date: Wed, 9 Dec 2009 18:31:53 +0100
Subject: [PATCH] nvram: Fix missing smp_lock.h in nvram

The bkl has been removed from nvram_llseek() and smp_lock.h was
removed because another patch in the same tree zapped the remaining
usage of bkl in the same file. But this patch must have been excluded
later, then we still need the smp_lock.h headers for the bkl use
in nvram_open().

This fixes the following build error:

drivers/char/nvram.c: In function _nvram_open_:
drivers/char/nvram.c:332: erreur: implicit declaration of function _lock_kernel_
drivers/char/nvram.c:339: erreur: implicit declaration of function
_unlock_kernel_
make[2]: *** [drivers/char/nvram.o] Erreur 1
make[1]: *** [drivers/char] Erreur 2
make: *** [drivers] Erreur 2

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
 drivers/char/nvram.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index 2100a8f..4008e2c 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -110,6 +110,7 @@
 #include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/uaccess.h>
+#include <linux/smp_lock.h>

 #include <asm/system.h>

-- 
1.6.2.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Hi Linus, David,

Today's linux-next build (x86_64 allmodconfig) failed like this:

fs/9p/cache.c: In function '__v9fs_fscache_release_page':
fs/9p/cache.c:346: error: 'vnode' undeclared (first use in this function)

Caused by commit 201a15428bd54f83eccec8b7c64a04b8f9431204 ("FS-Cache:
Handle pages pending storage that get evicted under OOM conditions").

Please, at least build files that have been modified ...

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Linus,

Today's linux-next build (x86_64 allmodconfig) failed like this:

ERROR: "log_start_commit" [fs/ext3/ext3.ko] undefined!

I applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Nov 2009 11:19:26 +1100
Subject: [PATCH] jbd: export log_start_commit for ext3

Today's linux-next build (x86_64 allmodconfig) failed like this:

ERROR: "log_start_commit" [fs/ext3/ext3.ko] undefined!

Caused by commit fe8bc91c4c30122b357d197117705cfd4fabaf28 ("ext3: Wait
for proper transaction commit on fsync").

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/jbd/journal.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 49d5cd6..34973f6 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -461,6 +461,7 @@ int log_start_commit(journal_t *journal, tid_t tid)
 	spin_unlock(&journal->j_state_lock);
 	return ret;
 }
+EXPORT_SYMBOL(log_start_commit);
 
 /*
  * Force and wait upon a commit if the calling process is not within
-- 
1.6.5.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/ata/ahci.c: In function 'ahci_gtf_filter_workaround':
drivers/ata/ahci.c:2927: error: 'struct ata_device' has no member named 'gtf_filter'

Caused by commit f80ae7e45a0e03da188494c6e947a5c8b0cdfb4a ("ahci: filter
FPDMA non-zero offset enable for Aspire 3810T") from Linus' tree.

gtf_filter only exists in struct ata_device when CONFIG_ATA_ACPI is set
(which it isn't on PowerPC).

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Linus,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/net/fealnx.c: In function 'fealnx_tx_timeout':
drivers/net/fealnx.c:1219: error: 'PR_CONT' undeclared (first use in this function)
drivers/net/fealnx.c:1219: error: (Each undeclared identifier is reported only once
drivers/net/fealnx.c:1219: error: for each function it appears in.)
drivers/net/fealnx.c:1219: error: expected ')' before string constant
drivers/net/fealnx.c:1224: error: expected ')' before string constant
drivers/net/fealnx.c:1225: error: expected ')' before string constant

Caused by commit ad361c9884e809340f6daca80d56a9e9c871690a ("Remove
multiple KERN_ prefixes from printk formats").  I applied the following
patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 9 Jul 2009 10:23:07 +1000
Subject: [PATCH] Fix up typo in KERN_ prefixes removal

This fixes a type in commit ad361c9884e809340f6daca80d56a9e9c871690a
"Remove multiple KERN_ prefixes from printk formats".

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/fealnx.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fealnx.c b/drivers/net/fealnx.c
index 053fb49..48385c4 100644
--- a/drivers/net/fealnx.c
+++ b/drivers/net/fealnx.c
@@ -1216,13 +1216,13 @@ static void fealnx_tx_timeout(struct net_device *dev)
 	{
 		printk(KERN_DEBUG "  Rx ring %p: ", np->rx_ring);
 		for (i = 0; i < RX_RING_SIZE; i++)
-			printk(PR_CONT " %8.8x",
+			printk(KERN_CONT " %8.8x",
 			       (unsigned int) np->rx_ring[i].status);
 		printk(KERN_CONT "\n");
 		printk(KERN_DEBUG "  Tx ring %p: ", np->tx_ring);
 		for (i = 0; i < TX_RING_SIZE; i++)
-			printk(PR_CONT " %4.4x", np->tx_ring[i].status);
-		printk(PR_CONT "\n");
+			printk(KERN_CONT " %4.4x", np->tx_ring[i].status);
+		printk(KERN_CONT "\n");
 	}
 
 	spin_lock_irqsave(&np->lock, flags);
-- 
1.6.3.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: origin tree build failure

[Paul Mundt]

On Thu, Jun 25, 2009 at 06:24:08AM +0300, Baruch Siach wrote:
> Hi Stephen,
> 
> On Thu, Jun 25, 2009 at 11:13:44AM +1000, Stephen Rothwell wrote:
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > ERROR: "clk_enable" [drivers/i2c/busses/i2c-designware.ko] undefined!
> > ERROR: "clk_disable" [drivers/i2c/busses/i2c-designware.ko] undefined!
> > ERROR: "clk_put" [drivers/i2c/busses/i2c-designware.ko] undefined!
> > ERROR: "clk_get_rate" [drivers/i2c/busses/i2c-designware.ko] undefined!
> > ERROR: "clk_get" [drivers/i2c/busses/i2c-designware.ko] undefined!
> > 
> > Caused by commit 1ab52cf910bbbee92861227e6ed77c56b1dc233c ("i2c: driver
> > for the Synopsys DesignWare I2C controller") from Linus' tree which I
> > have reverted for today.
> 
> So, what is the right configuration symbol to depend on for the clk API?
> 
CONFIG_HAVE_CLK.

> A short archives search led to the "provide a dummy implementation of the clk 
> API" patch from Uwe Kleine-K?nig 
> (http://lkml.indiana.edu/hypermail/linux/kernel/0804.2/2748.html). Is this the 
> right solution?
> 
Something like this would be better handled in include/linux/clk.h.

One of the things to watch out for is clk_get_rate(), there are
cases in the kernel where the rate is fetched with clk_get_rate() and
then subsequently used as a divisor in some other equation.
clk_get_rate() probably ought to WARN_ON(1) unconditionally, as any
driver wanting rate information is going to need proper clock
information.

Re: linux-next: origin tree build failure

[Baruch Siach]

Hi Stephen,

On Thu, Jun 25, 2009 at 11:13:44AM +1000, Stephen Rothwell wrote:
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> ERROR: "clk_enable" [drivers/i2c/busses/i2c-designware.ko] undefined!
> ERROR: "clk_disable" [drivers/i2c/busses/i2c-designware.ko] undefined!
> ERROR: "clk_put" [drivers/i2c/busses/i2c-designware.ko] undefined!
> ERROR: "clk_get_rate" [drivers/i2c/busses/i2c-designware.ko] undefined!
> ERROR: "clk_get" [drivers/i2c/busses/i2c-designware.ko] undefined!
> 
> Caused by commit 1ab52cf910bbbee92861227e6ed77c56b1dc233c ("i2c: driver
> for the Synopsys DesignWare I2C controller") from Linus' tree which I
> have reverted for today.

So, what is the right configuration symbol to depend on for the clk API?

A short archives search led to the "provide a dummy implementation of the clk 
API" patch from Uwe Kleine-KÃnig 
(http://lkml.indiana.edu/hypermail/linux/kernel/0804.2/2748.html). Is this the 
right solution?

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Hi Linus,

Today's linux-next build (x86_64 allmodconfig) failed like this:

ERROR: "clk_enable" [drivers/i2c/busses/i2c-designware.ko] undefined!
ERROR: "clk_disable" [drivers/i2c/busses/i2c-designware.ko] undefined!
ERROR: "clk_put" [drivers/i2c/busses/i2c-designware.ko] undefined!
ERROR: "clk_get_rate" [drivers/i2c/busses/i2c-designware.ko] undefined!
ERROR: "clk_get" [drivers/i2c/busses/i2c-designware.ko] undefined!

Caused by commit 1ab52cf910bbbee92861227e6ed77c56b1dc233c ("i2c: driver
for the Synopsys DesignWare I2C controller") from Linus' tree which I
have reverted for today.

This, again, never saw the light of day in linux-next ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Mark Brown]

This should fix it, I'll submit to the patch system immediately.

>From 196ab1662fc5561ca304bb4d08160f085a8f171d Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Tue, 23 Jun 2009 11:08:08 +0100
Subject: [PATCH] [ARM] S3C24XX: Declare device for IIS ports

Though the device is not actually used by the drivers on S3C24xx CPUs
some platforms register it causing build failures.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 arch/arm/plat-s3c/include/plat/devs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-s3c/include/plat/devs.h b/arch/arm/plat-s3c/include/plat/devs.h
index b5b9c4d..71a6b0e 100644
--- a/arch/arm/plat-s3c/include/plat/devs.h
+++ b/arch/arm/plat-s3c/include/plat/devs.h
@@ -34,6 +34,7 @@ extern struct platform_device s3c_device_lcd;
 extern struct platform_device s3c_device_wdt;
 extern struct platform_device s3c_device_i2c0;
 extern struct platform_device s3c_device_i2c1;
+extern struct platform_device s3c_device_iis;
 extern struct platform_device s3c_device_rtc;
 extern struct platform_device s3c_device_adc;
 extern struct platform_device s3c_device_sdi;
-- 
1.6.3.1

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Hi Russell,

Today's linux-next build (arm s3c2410_defconfig) failed like this:

arch/arm/mach-s3c2410/mach-smdk2410.c:94: error: 's3c_device_iis' undeclared here (not in a function)
arch/arm/mach-s3c2410/mach-h1940.c:189: error: 's3c_device_iis' undeclared here (not in a function)
arch/arm/mach-s3c2440/mach-rx3715.c:183: error: 's3c_device_iis' undeclared here (not in a function)
arch/arm/mach-s3c2412/mach-smdk2413.c:111: error: 's3c_device_iis' undeclared here (not in a function)
arch/arm/mach-s3c2440/mach-smdk2440.c:157: error: 's3c_device_iis' undeclared here (not in a function)
arch/arm/mach-s3c2412/mach-vstms.c:127: error: 's3c_device_iis' undeclared here (not in a function)
rch/arm/mach-s3c2440/mach-nexcoder.c:113: error: 's3c_device_iis' undeclared here (not in a function)

Probably caused by commit 52da219e9664e537a745877b0efa7cf2b1ff2996
("[ARM] S3C64XX: Provide device for IIS ports");

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Hi all,

Today's linux-next build (powerpc64, gcc 4.1.3) failed like this:

drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict

Caused by commit ae52bb2384f721562f15f719de1acb8e934733cb ("fbdev: move
logo externs to header file") but probably really a compiler bug as gcc
4.3 and 4.4 do not get this error.  I have reverted that commit for
today, but we really need some workaround as gcc 4.1.3 is not uncommon.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]

Hi Ingo,

On Fri, 12 Jun 2009 16:11:18 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the 
> first in the row of tests - so no change that was in linux-next can 
> ever cause a build failure on PowerPC, right?

Not really.  I build a powerpc ppc64_defconfig and an x86_64 allmodconfig
between merging most trees.  At the end of the day, I do the following
builds before releasing linux-next:

powerpc allnoconfig
powerpc64 allnoconfig
powerpc ppc44x_defconfig
powerpc allyesconfig
i386 defconfig
sparc64 defconfig
sparc defconfig

Which clearly doesn't cover all possible configs, but is a start and
catches a lot (the powerpc allyesconfig is only 64 bit).

Then after release, linux-next gets built for a lot of architectures and
configs (see http://kisskb.ellerman.id.au/kisskb/branch/9/).  A couple of
people also do randconfig builds which find all sorts of things.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

Hi Ingo,

On Fri, 12 Jun 2009 15:44:28 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> In terms of test coverage, at least for our trees, less than 1% of 
> the bugs we handle get reported in a linux-next context - and most 
> of the bugs that get reported (against say the scheduler tree) are 
> related to rare architectures.

I expect that most bugs get reported and fixed before code gets to
linux-next (in fact one of the prerequisites for being in linux-next is
that code has been tested as well as possible).

> In fact, i checked, there were _zero_ x86 bugs reported against 
> linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
> 
>    git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
> 
> Doing it over the full cycle shows one commit altogether - a Xen 
> build failure. In fact, i just checked the whole stabilization cycle 
> for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were 
> only 5 linux-next originated patches, most of them build failures.

Nice set of figures.  For some other context, between April 6 and June 9
(2.6.30-rc1 to 2.6.30) I sent 50 emails with subjects like "linux-next:
xxx tree build failure".  What results from those emails?  I sometimes
don't even hear back.  Almost all of the failures get fixed.

A lot of these probably also get discovered independently.  I don't
really care as long as they do get fixed.

One of those failures was a sparc build failure due to a change in the
tip-core tree (see commit d2de688891909b148efe83a6fc9520a9cd6015f0).
Another report produced commit 27b19565fe4ca5b0e9d2ae98ce4b81ca728bf445.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote:
> > Maybe. But maybe it's representative... so far in this merge 
> > window, 100% of the powerpc build and runtime breakage upstream 
> > comes from stuff that didn't get into -next before.
> 
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the 
> first in the row of tests - so no change that was in linux-next can 
> ever cause a build failure on PowerPC, right?

I'd have to check with Stephen but I think linux-next tests a whole
bunch of archs each round. Anyway, the idea is, just don't get things
upstream before the at least had a chance to go through that little bit
of integration testing .. Is it -that- hard ?

Oh and before you ask me, yes, I do the same mistakes, and I have been
caught too merging things at the last minute that ended up broken and
that could have been caught by -next... I'm just trying to advocate the
idea that we all try to improve in that area :-)

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

> Uhm, the bug you are making a big deal of would have been found and 
> fixed by Paulus a few hours after any such mail - and probably by me 
> too as i do daily cross builds to Power.
> 
> So yes, we had a bug, but any extra linux-next hoops would not have 
> prevented it: i could still have messed up by getting lured by that 
> nice piece of Power7 hardware enablement patch on the last day ;-)
> 
> So the bug was my fault for being too fast-and-loose with that 
> particular patch, creating a ~5-commits-hop build breakage bisection 
> window on Power.
> 
> Now that i'm sufficiently chastised, can we now move on please? :)

Sure we can :-) My point is, get a break before you merge upstream :-)

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > > 
> > > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > > or nack so that we can get a chance to do that final pass of ironing out
> > > > the mechanical bugs before we hit the main tree.
> > > 
> > > Let me add a little bit more background to my reasoning here and why I
> > > think having this integration testing step is so valuable...
> > > 
> > > It all boils down to bisection and having a bisectable tree.
> > 
> > I think you are way too concentrated on this particular incident, 
> > and you are generalizing it into something that is not so in 
> > practice.
> 
> Maybe. But maybe it's representative... so far in this merge 
> window, 100% of the powerpc build and runtime breakage upstream 
> comes from stuff that didn't get into -next before.

But that's axiomatic, isnt it? linux-next build-tests PowerPC as the 
first in the row of tests - so no change that was in linux-next can 
ever cause a build failure on PowerPC, right?

	Ingo

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> 
> > This is certainly doable for agreeable features - which is the bulk 
> > - and it is being done.
> > 
> > But this is a catch-22 for _controversial_ new features - which 
> > perfcounters clearly was, in case you turned off your lkml 
> > subscription ;-)
> 
> I didn't :-) My point here is that Linus can make a decision with 
> an email -before- merging so that -next gets a chance, at least 
> for a couple of days, to do the integration testing once the 
> controversy has been sorted by his highness.

Uhm, the bug you are making a big deal of would have been found and 
fixed by Paulus a few hours after any such mail - and probably by me 
too as i do daily cross builds to Power.

So yes, we had a bug, but any extra linux-next hoops would not have 
prevented it: i could still have messed up by getting lured by that 
nice piece of Power7 hardware enablement patch on the last day ;-)

So the bug was my fault for being too fast-and-loose with that 
particular patch, creating a ~5-commits-hop build breakage bisection 
window on Power.

Now that i'm sufficiently chastised, can we now move on please? :)

	Ingo

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > 
> > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > or nack so that we can get a chance to do that final pass of ironing out
> > > the mechanical bugs before we hit the main tree.
> > 
> > Let me add a little bit more background to my reasoning here and why I
> > think having this integration testing step is so valuable...
> > 
> > It all boils down to bisection and having a bisectable tree.
> 
> I think you are way too concentrated on this particular incident, 
> and you are generalizing it into something that is not so in 
> practice.

Maybe. But maybe it's representative... so far in this merge window,
100% of the powerpc build and runtime breakage upstream comes from stuff
that didn't get into -next before.

Some of the runtime breakage in powerpc-next comes from my own bugs,
indeed, and fortunately I caught it before I asked Linus to pull.

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:

> This is certainly doable for agreeable features - which is the bulk 
> - and it is being done.
> 
> But this is a catch-22 for _controversial_ new features - which 
> perfcounters clearly was, in case you turned off your lkml 
> subscription ;-)

I didn't :-) My point here is that Linus can make a decision with an
email -before- merging so that -next gets a chance, at least for a
couple of days, to do the integration testing once the controversy has
been sorted by his highness.

> And if you hit that build breakage during bisection you can do:
> 
>    git cherry-pick e14112d

Right, I can, you can, but can random tester who wants to track down
what his problem is ? I'm not sure...

> Also, you seem to brush off the notion that far more bugs slip 
> through linux-next than get caught by it.

Less than without linux-next. We aren't perfect and no process will
solve everything. But this could have been easily avoided.

> So if you think linux-next matters in terms of _regression_ testing, 
> the numbers dont seem to support that notion. This particular 
> incident does support that notion though, granted - but it's taken 
> out of context IMHO:
> 
> In terms of test coverage, at least for our trees, less than 1% of 
> the bugs we handle get reported in a linux-next context - and most 
> of the bugs that get reported (against say the scheduler tree) are 
> related to rare architectures.

But most obvious bugs will have been caught way before that, which
leaves the hard to catch ones or the configuration-specific ones. Those
will pass linux-next, I agree. But that isn't my point and that isn't
what linux-next will catch.  What is will catch is that kind of really
simple mechanical problems, such as build breakage for other archs.

If perfcounters had been 1 or 2 days in -next before being merged, we
would have avoided that problem and made everybody's bisecting life
easier.

> In fact, i checked, there were _zero_ x86 bugs reported against 
> linux-next and solved against it between v2.6.30-rc1 and v2.6.30:

No but Stephen caught a bunch of mechanical compile fails due to
integration problems.

>    git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
> 
> Doing it over the full cycle shows one commit altogether - a Xen 
> build failure. In fact, i just checked the whole stabilization cycle 
> for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were 
> only 5 linux-next originated patches, most of them build failures.
> 
> I did this by looking at all occurances of 'next', in all commit 
> logs:
> 
>    git log --grep=next -i v2.6.30-rc1..v2.6.30
> 
> and then manually checking the context of all 'next' matches and 
> counting the linux-next related commits.
> 
> So lets be generous and say that because some people dont put the 
> bug report originator into the changelog it was four times as many, 
> 20 - but that's still dwarved by the sheer amount of post-rc1 
> changes: thousands of changes and hundreds of regressions.
> 
> linux-next is mostly useful (to me at least) not for the 
> cross-builds it does, but in terms of mapping out upcoming conflicts 
> - which also drives early detection of problematic patches and 
> problematic conflicts.

Yes, it does. The problem is that it helps -you- that way, but won't
help -us- vs. that kind of mechanical problems unless -you- also play
the game and get your stuff in there for a little while before merging
it :-)

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> 
> > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > or nack so that we can get a chance to do that final pass of ironing out
> > the mechanical bugs before we hit the main tree.
> 
> Let me add a little bit more background to my reasoning here and why I
> think having this integration testing step is so valuable...
> 
> It all boils down to bisection and having a bisectable tree.

I think you are way too concentrated on this particular incident, 
and you are generalizing it into something that is not so in 
practice.

Even in this particular case, there's just 3 other commit points in 
the Git tree between commit 8a1ca8c (the breakage on PowerPC) and 
e14112d (the fix). We'll have up to 10,000 commits.

I bisect on an almost daily basis, and i'm not seeing unreasonable 
problems.

	Ingo

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> > linux-next should not be second-guessing maintainers and should 
> > not act as an "approval forum" for controversial features, 
> > increasing the (already quite substantial) pressure on 
> > maintainers to apply more crap.
> 
> I agree here. That's not the point. The idea is that for things 
> that -are- approved by their respective maintainers, to get some 
> integration testing and ironing of those mechanical bugs so that 
> by the time they hit mainstream, they don't break bisection among 
> others.

This is certainly doable for agreeable features - which is the bulk 
- and it is being done.

But this is a catch-22 for _controversial_ new features - which 
perfcounters clearly was, in case you turned off your lkml 
subscription ;-)

And if you hit that build breakage during bisection you can do:

   git cherry-pick e14112d

Also, you seem to brush off the notion that far more bugs slip 
through linux-next than get caught by it.

So if you think linux-next matters in terms of _regression_ testing, 
the numbers dont seem to support that notion. This particular 
incident does support that notion though, granted - but it's taken 
out of context IMHO:

In terms of test coverage, at least for our trees, less than 1% of 
the bugs we handle get reported in a linux-next context - and most 
of the bugs that get reported (against say the scheduler tree) are 
related to rare architectures.

In fact, i checked, there were _zero_ x86 bugs reported against 
linux-next and solved against it between v2.6.30-rc1 and v2.6.30:

   git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/

Doing it over the full cycle shows one commit altogether - a Xen 
build failure. In fact, i just checked the whole stabilization cycle 
for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were 
only 5 linux-next originated patches, most of them build failures.

I did this by looking at all occurances of 'next', in all commit 
logs:

   git log --grep=next -i v2.6.30-rc1..v2.6.30

and then manually checking the context of all 'next' matches and 
counting the linux-next related commits.

So lets be generous and say that because some people dont put the 
bug report originator into the changelog it was four times as many, 
20 - but that's still dwarved by the sheer amount of post-rc1 
changes: thousands of changes and hundreds of regressions.

linux-next is mostly useful (to me at least) not for the 
cross-builds it does, but in terms of mapping out upcoming conflicts 
- which also drives early detection of problematic patches and 
problematic conflicts.

	Ingo

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:

> To some extent, here, the issue is on Linus side and it's up to him (Hey
> Linus ! still listening ?) to maybe be more proactive at giving an ack
> or nack so that we can get a chance to do that final pass of ironing out
> the mechanical bugs before we hit the main tree.

Let me add a little bit more background to my reasoning here and why I
think having this integration testing step is so valuable...

It all boils down to bisection and having a bisectable tree.

Yes, I hate bisecting and I'm sure you are the same. It's a major PITA
and in most cases, I'm better off tracking down the actual bug and then
finding how it came into being.

However, what the ability to have a reasonably bisectable tree buys us
is all those users, testers, good wills, etc... people who do not have
the knowledge, skill, familiarity with the code etc... to track the bug
down, to be able to still find out what precise patch brought that pesky
regression that doesn't happen on anybody else machine, and thus brings
us some useful material to work with when we cannot reproduce the exact
same setup on our own machines.

Yes, I and I'm sure you can deal with a bisection breakage caused by a
minor screweup like the one we are talking about. But our testers often
can't and will just give up.

It has -nothing- to do with whether the patches are controversial or
not, it is purely about trying to make sure that things going into linus
tree had at least a few days of churning by the various involved parties
to try to get closer to the graal of a fully bisectable tree.

At least that's how I see it.

Now, we may disagree and I'm happy to discuss that more around a beer at
next KS, and to some extent, what is done is done, and if we screwed up
with -next vs. perfmon, then so be it and let's learn from our mistakes,
but I believe it makes a lot of sense to have that staging area that
helps us making sure that within a merge window with gazillion things
being merged pretty much at once, we keep this ability for our users and
testers to track down which individual patch broke something.

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> linux-next has integration testing so that interactions between 
> maintainer trees are mapped and that architectures that otherwise 
> few people use get build-tested too (well beyond their practical 
> relevance, i have to add) - but there's little critical review done 
> in linux-next. Nor should it be the forum for that, it simply 
> contains way too much stuff and has a weird history format with 
> daily rebases that makes review hard and expensive in that form.

I think you are mixing several issues. One is integration testing, one
is the problem of remote architecture of subsystems testing...

> linux-next should not be second-guessing maintainers and should not 
> act as an "approval forum" for controversial features, increasing 
> the (already quite substantial) pressure on maintainers to apply 
> more crap.

I agree here. That's not the point. The idea is that for things that
-are- approved by their respective maintainers, to get some integration
testing and ironing of those mechanical bugs so that by the time they
hit mainstream, they don't break bisection among others.

Yes, next is -not- the place to debate controversial features. That's
not, I believe, why it was initiated (I may be wrong, Stephen will
correct me if I am), but the way I see things is that stuff that is
meant to be merged gets a chance to get some of that integration testing
against all the other stuff that is also meant to be merged to limit the
amount of clash and problems once we hit Linus tree.

> And that is true even if it's a new feature that i happen to support 
> - as in this case - it sure would have been handy to have more 
> perfcounters test coverage, every little bit of extra testing helps.

That doesn't invalidate my point. We are not talking about whether
perfcounters is worth merging or not, testing more or not, but strictly,
imho, about getting a chance (a couple of days at least) to do that
integration testing and catch the simple issues like the one that
triggered my initial rant -before- they hit mainline.

To some extent, here, the issue is on Linus side and it's up to him (Hey
Linus ! still listening ?) to maybe be more proactive at giving an ack
or nack so that we can get a chance to do that final pass of ironing out
the mechanical bugs before we hit the main tree.

Cheers,
Ben.

> If linux-next wants to do that then it should be renamed to 
> something else and not called linux-next.
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> > Ah - thanks. The bug was caused by me being a bit too optimistic 
> > in applying the shiny-new Power7 support patches on the last 
> > day. (nice CPU btw.)
> 
> In that case paulus tells me it's actually Peter screwing up 
> moving something from the powerpc code to generic :-)

Yes, but i committed it and it's my task to make sure that the thing 
works as a whole so it's my fault still :)

>  .../...
> 
> > Such bugs happen, and they are easy enough to fix. What matters 
> > arent the 1-2 short-lived bugs that do happen when a new 
> > combination of trees is created, but the long-lived combination 
> > bugs and conflicts.
> 
> I'm not saying -next would fix world hunger ... but in this case 
> we have two sets of issues, perfctr and the init ordering change 
> which both got merged totally bypassing -next... We should at 
> least -try- to follow the process we've defined, don't you think ?

You are trying to define a process that does not exist in that form 
and which never existed in that form.

It was never true that new code _MUST_ go via linux-next - and i 
hope it will never be true.

linux-next has integration testing so that interactions between 
maintainer trees are mapped and that architectures that otherwise 
few people use get build-tested too (well beyond their practical 
relevance, i have to add) - but there's little critical review done 
in linux-next. Nor should it be the forum for that, it simply 
contains way too much stuff and has a weird history format with 
daily rebases that makes review hard and expensive in that form.

linux-next should not be second-guessing maintainers and should not 
act as an "approval forum" for controversial features, increasing 
the (already quite substantial) pressure on maintainers to apply 
more crap.

And that is true even if it's a new feature that i happen to support 
- as in this case - it sure would have been handy to have more 
perfcounters test coverage, every little bit of extra testing helps.

If linux-next wants to do that then it should be renamed to 
something else and not called linux-next.

	Ingo

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
> 
> So you're saying -next should include whole new subsystems even though
> its not clear they will be merged?

Maybe yes. And if there's some debate as to whether it should be merged
or not, maybe Linus should make the decision, let -next carry it for a
few days to iron out those problems, and -then- merge it.

> That'll invariably create the opposite case where a tree doesn't get
> pulled and breaks bits due to its absence.
> 
> -next does a great job of sorting the existing subsystem trees, but I
> don't think its Stephens job to decide if things will get merged.

No, it's not, but then, maybe Linus could play the game and -tell- us
whether he intend to merge or not at least a few days in advance :-)

> Therefore when things are in limbo (there was no definite ACK from Linus
> on perf counters) both inclusion and exclusion from -next can lead to
> trouble.

Well, Linus did ACK by merging :-) So he should have been able to give
that ack a few days in advance too..

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even 
> though its not clear they will be merged?
> 
> That'll invariably create the opposite case where a tree doesn't 
> get pulled and breaks bits due to its absence.
> 
> -next does a great job of sorting the existing subsystem trees, 
> but I don't think its Stephens job to decide if things will get 
> merged.
> 
> Therefore when things are in limbo (there was no definite ACK from 
> Linus on perf counters) both inclusion and exclusion from -next 
> can lead to trouble.

Precisely. linux-next is for the uncontroversial stuff from existing 
subsystems. Sometimes for features pushed by or approved by existing 
subsystem maintainers. But it is not for controversial stuff - Linus 
is the upstream maintainer, not Stephen.

We had a real mess with perfmon3 which was included into linux-next 
in a rouge way without Cc:-ing the affected maintainers and against 
the maintainers. There was a repeat incident recently as well, where 
a tree was included into linux-next without the approval (and 
without the Cc:) of affected maintainers. linux-next needs to be 
more careful about adding trees.

All in one, we did the same with perfcounters that we expected of 
perfmonv3. No double standard.

Nor is there any real issue here. The bug was my fault, it was 
trivial to fix, it affects a small subset of testers and it is 
already upstream, applied on the same day perfcounters were pulled.

	Ingo

Re: linux-next: origin tree build failure

[Peter Zijlstra]

On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> We should at least -try- to follow the
> process we've defined, don't you think ?

So you're saying -next should include whole new subsystems even though
its not clear they will be merged?

That'll invariably create the opposite case where a tree doesn't get
pulled and breaks bits due to its absence.

-next does a great job of sorting the existing subsystem trees, but I
don't think its Stephens job to decide if things will get merged.

Therefore when things are in limbo (there was no definite ACK from Linus
on perf counters) both inclusion and exclusion from -next can lead to
trouble.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

> Ah - thanks. The bug was caused by me being a bit too optimistic in 
> applying the shiny-new Power7 support patches on the last day. (nice 
> CPU btw.)

In that case paulus tells me it's actually Peter screwing up moving
something from the powerpc code to generic :-)

 .../...

> Such bugs happen, and they are easy enough to fix. What matters 
> arent the 1-2 short-lived bugs that do happen when a new combination 
> of trees is created, but the long-lived combination bugs and 
> conflicts.

I'm not saying -next would fix world hunger ... but in this case we have
two sets of issues, perfctr and the init ordering change which both got
merged totally bypassing -next... We should at least -try- to follow the
process we've defined, don't you think ?

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
> 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 12 Jun 2009 10:14:22 +1000
> > Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
> > 
> > Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> > unify and fix delayed counter wakeup") added global definitions.
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Ah - thanks. The bug was caused by me being a bit too optimistic in 
applying the shiny-new Power7 support patches on the last day. (nice 
CPU btw.)

> Linus, please apply. BTW, This is _EXACTLY_ why this should have 
> been in -next for a few days before being merged :-(

Not really: for example current upstream is build-broken on x86 due 
to an integration artifact via the kmemleak tree - despite it having 
been in linux-next for months.

Paulus was building and booting powerpc on a daily basis and i ran 
cross-builds as well.

Such bugs happen, and they are easy enough to fix. What matters 
arent the 1-2 short-lived bugs that do happen when a new combination 
of trees is created, but the long-lived combination bugs and 
conflicts.

	Ingo

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Jun 2009 10:14:22 +1000
> Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
> 
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fix delayed counter wakeup") added global definitions.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

Linus, please apply. BTW, This is _EXACTLY_ why this should have been in
-next for a few days before being merged :-(

Cheers,
Ben.

> ---
>  arch/powerpc/include/asm/hw_irq.h |    3 ---
>  arch/powerpc/kernel/irq.c         |    1 +
>  2 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
> index 20a44d0..5351237 100644
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -156,8 +156,6 @@ static inline void clear_perf_counter_pending(void)
>  		"i" (offsetof(struct paca_struct, perf_counter_pending)));
>  }
>  
> -extern void perf_counter_do_pending(void);
> -
>  #else
>  
>  static inline unsigned long test_perf_counter_pending(void)
> @@ -167,7 +165,6 @@ static inline unsigned long test_perf_counter_pending(void)
>  
>  static inline void set_perf_counter_pending(void) {}
>  static inline void clear_perf_counter_pending(void) {}
> -static inline void perf_counter_do_pending(void) {}
>  #endif /* CONFIG_PERF_COUNTERS */
>  
>  #endif	/* __KERNEL__ */
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index feff792..844d3f8 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -53,6 +53,7 @@
>  #include <linux/bootmem.h>
>  #include <linux/pci.h>
>  #include <linux/debugfs.h>
> +#include <linux/perf_counter.h>
>  
>  #include <asm/uaccess.h>
>  #include <asm/system.h>

Re: linux-next: origin tree build failure

[Paul Mackerras]

Stephen Rothwell writes:

> Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
> 
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fix delayed counter wakeup") added global definitions.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Acked-by: Paul Mackerras <paulus@samba.org>

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

mm/built-in.o: In function `kmemleak_scan':
kmemleak.c:(.text+0x3ad27): undefined reference to `_sdata'

Caused by commit 3c7b4e6b8be4c16f1e6e5c558e33b7ff0db2dfaf ("kmemleak: Add
the base support").  It needs commit
4504c6d020fc5aec7659bf7746e71b1b904571f8 ("x86: Provide _sdata in the
vmlinux.lds.S file") from the tip/x86 tree.

I cherry-picked that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

include/linux/perf_counter.h:677: error: redefinition of 'perf_counter_do_pending'
arch/powerpc/include/asm/hw_irq.h:170: note: previous definition of 'perf_counter_do_pending' was here

Caused by commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
unify and fix delayed counter wakeup") which added the former definitions
but forgot the remove the latter.

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Jun 2009 10:14:22 +1000
Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending

Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
unify and fix delayed counter wakeup") added global definitions.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/hw_irq.h |    3 ---
 arch/powerpc/kernel/irq.c         |    1 +
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index 20a44d0..5351237 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -156,8 +156,6 @@ static inline void clear_perf_counter_pending(void)
 		"i" (offsetof(struct paca_struct, perf_counter_pending)));
 }
 
-extern void perf_counter_do_pending(void);
-
 #else
 
 static inline unsigned long test_perf_counter_pending(void)
@@ -167,7 +165,6 @@ static inline unsigned long test_perf_counter_pending(void)
 
 static inline void set_perf_counter_pending(void) {}
 static inline void clear_perf_counter_pending(void) {}
-static inline void perf_counter_do_pending(void) {}
 #endif /* CONFIG_PERF_COUNTERS */
 
 #endif	/* __KERNEL__ */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index feff792..844d3f8 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -53,6 +53,7 @@
 #include <linux/bootmem.h>
 #include <linux/pci.h>
 #include <linux/debugfs.h>
+#include <linux/perf_counter.h>
 
 #include <asm/uaccess.h>
 #include <asm/system.h>
-- 
1.6.3.1

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Hi Dave,

On Tue, 14 Apr 2009 02:08:18 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 14 Apr 2009 14:43:17 +1000
> 
> > sparc: asm/atomic.h on 32bit should include asm/system.h for xchg
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> Just in case it wasn't clear, I'm applying this :)

Ah, ok, thanks :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Heiko Carstens]

On Tue, 14 Apr 2009 01:57:27 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 14 Apr 2009 14:43:17 +1000
> 
> > Dave, arch/sparc/include/asm/atomic_32.h should really include
> > asm/system.h since xchg is used in there.
> 
> That's true.
> 
> But atomic.h is not the proper place to obtain xchg() from, which is
> asm/system.h, and that's what debug_locks.h needs to include if it
> needs to use xchg().
> 
> This is why the s390 build broke in precisely the same way.

Due to header include dependencies we can't include asm/system.h from
asm/atomic.h. So David's solution seems to be the right way.
How about this:

Subject: [PATCH] Fix xchg build breakage on s390.

From: Heiko Carstens <heiko.carstens@de.ibm.com>

In file included from kernel/panic.c:11:
include/linux/debug_locks.h: In function '__debug_locks_off':
include/linux/debug_locks.h:15: error: implicit declaration of function 'xchg'

Caused by 9eeba6138cefc0435695463ddadb0d95e0a6bcd2
"lockdep: warn about lockdep disabling after kernel taint"

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---

 include/linux/debug_locks.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/include/linux/debug_locks.h
===================================================================
--- linux-2.6.orig/include/linux/debug_locks.h
+++ linux-2.6/include/linux/debug_locks.h
@@ -2,7 +2,7 @@
 #define __LINUX_DEBUG_LOCKING_H
 
 #include <linux/kernel.h>
-#include <asm/atomic.h>
+#include <asm/system.h>
 
 struct task_struct;
 

Re: linux-next: origin tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Apr 2009 14:43:17 +1000

> sparc: asm/atomic.h on 32bit should include asm/system.h for xchg
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Just in case it wasn't clear, I'm applying this :)

Re: linux-next: origin tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Apr 2009 14:43:17 +1000

> Dave, arch/sparc/include/asm/atomic_32.h should really include
> asm/system.h since xchg is used in there.

That's true.

But atomic.h is not the proper place to obtain xchg() from, which is
asm/system.h, and that's what debug_locks.h needs to include if it
needs to use xchg().

This is why the s390 build broke in precisely the same way.

Re: linux-next: origin tree build failure

[Jesper Nilsson]

On Tue, Apr 14, 2009 at 09:34:23AM +0200, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next build (cris etrax-100lx_defconfig) failed like this:
> 
> drivers/serial/crisv10.c:4428: error: unknown field 'read_proc' specified in initializer
> 
> Caused by commit 0f043a81ebe84be3576667f04fdda481609e3816 ("proc tty:
> remove struct tty_operations::read_proc").

Hi,

I have the following patch (sent Wed 8 Apr) for this failure:


CRISv10: Change serial driver proc-usage.

Commit 0f043a81ebe84be3576667f04fdda481609e3816 removes the
read_proc entry from struct tty_operations.

Rework the proc handling in the CRISv10 serial driver to use
proc_fops instead.


Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>

--
 crisv10.c |  173 +++++++++++++++++++++++++++-----------------------------------
 1 file changed, 78 insertions(+), 95 deletions(-)

diff --git a/drivers/serial/crisv10.c b/drivers/serial/crisv10.c
index e642c22..4719935 100644
--- a/drivers/serial/crisv10.c
+++ b/drivers/serial/crisv10.c
@@ -23,16 +23,18 @@ static char *serial_version = "$Revision: 1.25 $";
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/init.h>
-#include <asm/uaccess.h>
 #include <linux/kernel.h>
 #include <linux/mutex.h>
 #include <linux/bitops.h>
+#include <linux/seq_file.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
 
-#include <asm/io.h>
 #include <asm/irq.h>
 #include <asm/dma.h>
 #include <asm/system.h>
-#include <linux/delay.h>
 
 #include <arch/svinto.h>
 
@@ -456,7 +458,6 @@ static struct e100_serial rs_table[] = {
 
 #define NR_PORTS (sizeof(rs_table)/sizeof(struct e100_serial))
 
-static struct ktermios *serial_termios[NR_PORTS];
 #ifdef CONFIG_ETRAX_SERIAL_FAST_TIMER
 static struct fast_timer fast_timers[NR_PORTS];
 #endif
@@ -4220,151 +4221,132 @@ rs_open(struct tty_struct *tty, struct file * filp)
 	return 0;
 }
 
+#ifdef CONFIG_PROC_FS
 /*
  * /proc fs routines....
  */
 
-static int line_info(char *buf, struct e100_serial *info)
+static void seq_line_info(struct seq_file *m, struct e100_serial *info)
 {
-	char	stat_buf[30];
-	int	ret;
 	unsigned long tmp;
 
-	ret = sprintf(buf, "%d: uart:E100 port:%lX irq:%d",
-		      info->line, (unsigned long)info->ioport, info->irq);
+	seq_printf(m, "%d: uart:E100 port:%lX irq:%d",
+		   info->line, (unsigned long)info->ioport, info->irq);
 
 	if (!info->ioport || (info->type == PORT_UNKNOWN)) {
-		ret += sprintf(buf+ret, "\n");
-		return ret;
+		seq_printf(m, "\n");
+		return;
 	}
 
-	stat_buf[0] = 0;
-	stat_buf[1] = 0;
-	if (!E100_RTS_GET(info))
-		strcat(stat_buf, "|RTS");
-	if (!E100_CTS_GET(info))
-		strcat(stat_buf, "|CTS");
-	if (!E100_DTR_GET(info))
-		strcat(stat_buf, "|DTR");
-	if (!E100_DSR_GET(info))
-		strcat(stat_buf, "|DSR");
-	if (!E100_CD_GET(info))
-		strcat(stat_buf, "|CD");
-	if (!E100_RI_GET(info))
-		strcat(stat_buf, "|RI");
-
-	ret += sprintf(buf+ret, " baud:%d", info->baud);
-
-	ret += sprintf(buf+ret, " tx:%lu rx:%lu",
+	seq_printf(m, " baud:%d", info->baud);
+	seq_printf(m, " tx:%lu rx:%lu",
 		       (unsigned long)info->icount.tx,
 		       (unsigned long)info->icount.rx);
 	tmp = CIRC_CNT(info->xmit.head, info->xmit.tail, SERIAL_XMIT_SIZE);
-	if (tmp) {
-		ret += sprintf(buf+ret, " tx_pend:%lu/%lu",
-			       (unsigned long)tmp,
-			       (unsigned long)SERIAL_XMIT_SIZE);
-	}
+	if (tmp)
+		seq_printf(m, " tx_pend:%lu/%lu",
+			   (unsigned long)tmp,
+			   (unsigned long)SERIAL_XMIT_SIZE);
 
-	ret += sprintf(buf+ret, " rx_pend:%lu/%lu",
-		       (unsigned long)info->recv_cnt,
-		       (unsigned long)info->max_recv_cnt);
+	seq_printf(m, " rx_pend:%lu/%lu",
+		   (unsigned long)info->recv_cnt,
+		   (unsigned long)info->max_recv_cnt);
 
 #if 1
 	if (info->port.tty) {
-
 		if (info->port.tty->stopped)
-			ret += sprintf(buf+ret, " stopped:%i",
-				       (int)info->port.tty->stopped);
+			seq_printf(m, " stopped:%i",
+				   (int)info->port.tty->stopped);
 		if (info->port.tty->hw_stopped)
-			ret += sprintf(buf+ret, " hw_stopped:%i",
-				       (int)info->port.tty->hw_stopped);
+			seq_printf(m, " hw_stopped:%i",
+				   (int)info->port.tty->hw_stopped);
 	}
 
 	{
 		unsigned char rstat = info->ioport[REG_STATUS];
-		if (rstat & IO_MASK(R_SERIAL0_STATUS, xoff_detect) )
-			ret += sprintf(buf+ret, " xoff_detect:1");
+		if (rstat & IO_MASK(R_SERIAL0_STATUS, xoff_detect))
+			seq_printf(m, " xoff_detect:1");
 	}
 
 #endif
 
-
-
-
 	if (info->icount.frame)
-		ret += sprintf(buf+ret, " fe:%lu",
-			       (unsigned long)info->icount.frame);
+		seq_printf(m, " fe:%lu", (unsigned long)info->icount.frame);
 
 	if (info->icount.parity)
-		ret += sprintf(buf+ret, " pe:%lu",
-			       (unsigned long)info->icount.parity);
+		seq_printf(m, " pe:%lu", (unsigned long)info->icount.parity);
 
 	if (info->icount.brk)
-		ret += sprintf(buf+ret, " brk:%lu",
-			       (unsigned long)info->icount.brk);
+		seq_printf(m, " brk:%lu", (unsigned long)info->icount.brk);
 
 	if (info->icount.overrun)
-		ret += sprintf(buf+ret, " oe:%lu",
-			       (unsigned long)info->icount.overrun);
+		seq_printf(m, " oe:%lu", (unsigned long)info->icount.overrun);
 
 	/*
 	 * Last thing is the RS-232 status lines
 	 */
-	ret += sprintf(buf+ret, " %s\n", stat_buf+1);
-	return ret;
+	if (!E100_RTS_GET(info))
+		seq_puts(m, "|RTS");
+	if (!E100_CTS_GET(info))
+		seq_puts(m, "|CTS");
+	if (!E100_DTR_GET(info))
+		seq_puts(m, "|DTR");
+	if (!E100_DSR_GET(info))
+		seq_puts(m, "|DSR");
+	if (!E100_CD_GET(info))
+		seq_puts(m, "|CD");
+	if (!E100_RI_GET(info))
+		seq_puts(m, "|RI");
+	seq_puts(m, "\n");
 }
 
-int rs_read_proc(char *page, char **start, off_t off, int count,
-		 int *eof, void *data)
+
+static int crisv10_proc_show(struct seq_file *m, void *v)
 {
-	int i, len = 0, l;
-	off_t	begin = 0;
+	int i;
 
-	len += sprintf(page, "serinfo:1.0 driver:%s\n",
-		       serial_version);
-	for (i = 0; i < NR_PORTS && len < 4000; i++) {
+	seq_printf(m, "serinfo:1.0 driver:%s\n", serial_version);
+
+	for (i = 0; i < NR_PORTS; i++) {
 		if (!rs_table[i].enabled)
 			continue;
-		l = line_info(page + len, &rs_table[i]);
-		len += l;
-		if (len+begin > off+count)
-			goto done;
-		if (len+begin < off) {
-			begin += len;
-			len = 0;
-		}
+		seq_line_info(m, &rs_table[i]);
 	}
 #ifdef DEBUG_LOG_INCLUDED
 	for (i = 0; i < debug_log_pos; i++) {
-		len += sprintf(page + len, "%-4i %lu.%lu ", i, debug_log[i].time, timer_data_to_ns(debug_log[i].timer_data));
-		len += sprintf(page + len, debug_log[i].string, debug_log[i].value);
-		if (len+begin > off+count)
-			goto done;
-		if (len+begin < off) {
-			begin += len;
-			len = 0;
-		}
+		seq_printf(m, "%-4i %lu.%lu ",
+			 i, debug_log[i].time,
+			 timer_data_to_ns(debug_log[i].timer_data));
+		seq_printf(m, debug_log[i].string, debug_log[i].value);
 	}
-	len += sprintf(page + len, "debug_log %i/%i  %li bytes\n",
-		       i, DEBUG_LOG_SIZE, begin+len);
+	seq_printf(m, "debug_log %i/%i\n", i, DEBUG_LOG_SIZE);
 	debug_log_pos = 0;
 #endif
+	return 0;
+}
 
-	*eof = 1;
-done:
-	if (off >= len+begin)
-		return 0;
-	*start = page + (off-begin);
-	return ((count < begin+len-off) ? count : begin+len-off);
+static int crisv10_proc_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, crisv10_proc_show, NULL);
 }
 
+static const struct file_operations crisv10_proc_fops = {
+	.owner		= THIS_MODULE,
+	.open		= crisv10_proc_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+#endif
+
+
 /* Finally, routines used to initialize the serial driver. */
 
-static void
-show_serial_version(void)
+static void show_serial_version(void)
 {
 	printk(KERN_INFO
-	       "ETRAX 100LX serial-driver %s, (c) 2000-2004 Axis Communications AB\r\n",
+	       "ETRAX 100LX serial-driver %s, "
+	       "(c) 2000-2004 Axis Communications AB\r\n",
 	       &serial_version[11]); /* "$Revision: x.yy" */
 }
 
@@ -4388,13 +4370,14 @@ static const struct tty_operations rs_ops = {
 	.break_ctl = rs_break,
 	.send_xchar = rs_send_xchar,
 	.wait_until_sent = rs_wait_until_sent,
-	.read_proc = rs_read_proc,
 	.tiocmget = rs_tiocmget,
-	.tiocmset = rs_tiocmset
+	.tiocmset = rs_tiocmset,
+#ifdef CONFIG_PROC_FS
+	.proc_fops = &crisv10_proc_fops,
+#endif
 };
 
-static int __init
-rs_init(void)
+static int __init rs_init(void)
 {
 	int i;
 	struct e100_serial *info;


/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Hi all,

Today's linux-next build (cris etrax-100lx_defconfig) failed like this:

drivers/serial/crisv10.c:4428: error: unknown field 'read_proc' specified in initializer

Caused by commit 0f043a81ebe84be3576667f04fdda481609e3816 ("proc tty:
remove struct tty_operations::read_proc").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (sparc defconfig) failed like this:

In file included from kernel/panic.c:12:
include/linux/debug_locks.h: In function '__debug_locks_off':
include/linux/debug_locks.h:15: error: implicit declaration of function 'xchg'

Caused by commit 9eeba6138cefc0435695463ddadb0d95e0a6bcd2 ("lockdep: warn
about lockdep disabling after kernel taint").  xchg is defined in
asm/system.h on sparc. It looks like asm/atomic.h on 64bit sparc includes
asm/system.h, but not on 32bit.

Dave, arch/sparc/include/asm/atomic_32.h should really include
asm/system.h since xchg is used in there.

I have applied the following patch for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Apr 2009 14:27:09 +1000
Subject: [PATCH] sparc: asm/atomic.h on 32bit should include asm/system.h for xchg

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/include/asm/atomic_32.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/sparc/include/asm/atomic_32.h b/arch/sparc/include/asm/atomic_32.h
index ce46597..bb91b12 100644
--- a/arch/sparc/include/asm/atomic_32.h
+++ b/arch/sparc/include/asm/atomic_32.h
@@ -15,6 +15,8 @@
 
 #ifdef __KERNEL__
 
+#include <asm/system.h>
+
 #define ATOMIC_INIT(i)  { (i) }
 
 extern int __atomic_add_return(int, atomic_t *);
-- 
1.6.2.1

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

Hi Linus,

Today's linux-next build (powerpc allyesconfig) failed like this:

arch/powerpc/include/asm/parport.h: In function 'parport_pc_find_nonpci_ports':
arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'

Caused by commit 51dcdfec6a274afc1c6fce180d582add9ff512c0 ("parport: Use
the PCI IRQ if offered").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kernel/cpu/cpufreq/p4-clockmod.c: In function 'cpufreq_p4_cpu_init':
arch/x86/kernel/cpu/cpufreq/p4-clockmod.c:232: error: implicit declaration of function 'recalibrate_cpu_khz'

Caused by a mismerge or arch/x86/include/asm/timer.h in
6e15cf04860074ad032e88c306bea656bbdd0f22 ("Merge branch 'core/percpu'
into percpu-cpumask-x86-for-linus-2") which then propogated back into
Linus' tree.

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Mar 2009 11:10:27 +1100
Subject: [PATCH] x86: fix mismerge in arch/x86/include/asm/timer.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/include/asm/timer.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index a81195e..bd37ed4 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -12,9 +12,9 @@ unsigned long native_calibrate_tsc(void);
 
 #ifdef CONFIG_X86_32
 extern int timer_ack;
-extern int recalibrate_cpu_khz(void);
 extern irqreturn_t timer_interrupt(int irq, void *dev_id);
 #endif /* CONFIG_X86_32 */
+extern int recalibrate_cpu_khz(void);
 
 extern int no_timer_check;
 
-- 
1.6.2.1

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Hi Ingo,

On Mon, 12 Jan 2009 10:32:14 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > It slipped through because it didnt get caught in build tests because 
> > > cpufreq isnt enabled in the powerpc defconfig.
> > 
> > Which is one of the reasons we have linux-next: "integration testing".
> 
> Build bugs slipped through that net too in the past.

Of course they have.

> And we dont really want developers and maintainers to rely on an external 
> middle man facility to be able to submit patches. So the best method is to 
> make the defconfigs good enough to catch everyday build bugs. Random 
> testing and linux-next can then catch the weird special cases as well.

linux-next is merely a tool - it can't catch anything if you don't use it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > > Hi Linus,
> > > > 
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > > 
> > > > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> > > > 
> > > > Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> > > > convert struct cpufreq_policy to cpumask_var_t") which missed updating
> > > > all the powerpc (at least) cpufreq drivers.
> > > 
> > > Yeah, it only updates x86 it seems ... 
> > 
> > Yeah - and that build bug was stupid too - when touching a generic file 
> > that is called include/linux/cpufreq.h and changing a key data field one 
> > should at minimum get the idea that it's generic for a reason and should 
> > start grepping the tree ...
> > 
> > It slipped through because it didnt get caught in build tests because 
> > cpufreq isnt enabled in the powerpc defconfig.
> 
> Which defconfig?
>
> powerpc(master) $ git grep CPU_FREQ=y arch/powerpc/configs/ppc64_defconfig
> arch/powerpc/configs/ppc64_defconfig:CONFIG_CPU_FREQ=y

ah, indeed - you are right.

	Ingo

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > > Hi Linus,
> > > > 
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > > 
> > > > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> > > > 
> > > > Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> > > > convert struct cpufreq_policy to cpumask_var_t") which missed updating
> > > > all the powerpc (at least) cpufreq drivers.
> > > 
> > > Yeah, it only updates x86 it seems ... 
> > 
> > Yeah - and that build bug was stupid too - when touching a generic file 
> > that is called include/linux/cpufreq.h and changing a key data field one 
> > should at minimum get the idea that it's generic for a reason and should 
> > start grepping the tree ...
> > 
> > It slipped through because it didnt get caught in build tests because 
> > cpufreq isnt enabled in the powerpc defconfig.
> 
> Which defconfig?
>
> powerpc(master) $ git grep CPU_FREQ=y arch/powerpc/configs/ppc64_defconfig
> arch/powerpc/configs/ppc64_defconfig:CONFIG_CPU_FREQ=y

ah, indeed - you are right.

	Ingo

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > > Hi Linus,
> > > > 
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > > 
> > > > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> > > > arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> > > > 
> > > > Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> > > > convert struct cpufreq_policy to cpumask_var_t") which missed updating
> > > > all the powerpc (at least) cpufreq drivers.
> > > 
> > > Yeah, it only updates x86 it seems ... 
> > 
> > Yeah - and that build bug was stupid too - when touching a generic file 
> > that is called include/linux/cpufreq.h and changing a key data field one 
> > should at minimum get the idea that it's generic for a reason and should 
> > start grepping the tree ...
> > 
> > It slipped through because it didnt get caught in build tests because 
> > cpufreq isnt enabled in the powerpc defconfig.
> 
> Which defconfig?
>
> powerpc(master) $ git grep CPU_FREQ=y arch/powerpc/configs/ppc64_defconfig
> arch/powerpc/configs/ppc64_defconfig:CONFIG_CPU_FREQ=y

ah, indeed - you are right.

	Ingo

Re: linux-next: origin tree build failure

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > Hi Linus,
> > > 
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > 
> > > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > > arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> > > arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> > > arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> > > arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> > > arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> > > 
> > > Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> > > convert struct cpufreq_policy to cpumask_var_t") which missed updating
> > > all the powerpc (at least) cpufreq drivers.
> > 
> > Yeah, it only updates x86 it seems ... 
> 
> Yeah - and that build bug was stupid too - when touching a generic file 
> that is called include/linux/cpufreq.h and changing a key data field one 
> should at minimum get the idea that it's generic for a reason and should 
> start grepping the tree ...
> 
> It slipped through because it didnt get caught in build tests because 
> cpufreq isnt enabled in the powerpc defconfig.

Which defconfig?

powerpc(master) $ git grep CPU_FREQ=y arch/powerpc/configs/ppc64_defconfig
arch/powerpc/configs/ppc64_defconfig:CONFIG_CPU_FREQ=y

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > It slipped through because it didnt get caught in build tests because 
> > cpufreq isnt enabled in the powerpc defconfig.
> 
> Which is one of the reasons we have linux-next: "integration testing".

Build bugs slipped through that net too in the past.

And we dont really want developers and maintainers to rely on an external 
middle man facility to be able to submit patches. So the best method is to 
make the defconfigs good enough to catch everyday build bugs. Random 
testing and linux-next can then catch the weird special cases as well.

	Ingo

Re: linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Hi Ingo,

On Mon, 12 Jan 2009 10:05:52 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> Yeah - and that build bug was stupid too - when touching a generic file 
> that is called include/linux/cpufreq.h and changing a key data field one 
> should at minimum get the idea that it's generic for a reason and should 
> start grepping the tree ...
> 
> It slipped through because it didnt get caught in build tests because 
> cpufreq isnt enabled in the powerpc defconfig.

Which is one of the reasons we have linux-next: "integration testing".
This way not every developer/maintainer has to have/use cross compilers
for every (or even many) non-native (from their point of view)
architectures.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > Hi Linus,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> > arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> > arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> > arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> > arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> > 
> > Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> > convert struct cpufreq_policy to cpumask_var_t") which missed updating
> > all the powerpc (at least) cpufreq drivers.
> 
> Yeah, it only updates x86 it seems ... 

Yeah - and that build bug was stupid too - when touching a generic file 
that is called include/linux/cpufreq.h and changing a key data field one 
should at minimum get the idea that it's generic for a reason and should 
start grepping the tree ...

It slipped through because it didnt get caught in build tests because 
cpufreq isnt enabled in the powerpc defconfig.

	Ingo

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> Hi Linus,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> 
> Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> convert struct cpufreq_policy to cpumask_var_t") which missed updating
> all the powerpc (at least) cpufreq drivers.

Yeah, it only updates x86 it seems ... 

> Reverting that one commit required fixups, so I reverted merge commit
> 4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
> of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
> instead.
> 
> I am hoping that this will be fixed soon and that revert doesn't
> propagate more pain through today's linux-next.

I've just made a patch, testing it now, will send it in a few minutes

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> Hi Linus,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> 
> Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> convert struct cpufreq_policy to cpumask_var_t") which missed updating
> all the powerpc (at least) cpufreq drivers.

Yeah, it only updates x86 it seems ... 

> Reverting that one commit required fixups, so I reverted merge commit
> 4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
> of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
> instead.
> 
> I am hoping that this will be fixed soon and that revert doesn't
> propagate more pain through today's linux-next.

I've just made a patch, testing it now, will send it in a few minutes

Cheers,
Ben.

Re: linux-next: origin tree build failure

[Benjamin Herrenschmidt]

On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> Hi Linus,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
> arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
> arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
> arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
> arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
> 
> Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
> convert struct cpufreq_policy to cpumask_var_t") which missed updating
> all the powerpc (at least) cpufreq drivers.

Yeah, it only updates x86 it seems ... 

> Reverting that one commit required fixups, so I reverted merge commit
> 4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
> of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
> instead.
> 
> I am hoping that this will be fixed soon and that revert doesn't
> propagate more pain through today's linux-next.

I've just made a patch, testing it now, will send it in a few minutes

Cheers,
Ben.

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

Hi Linus,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment

Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
convert struct cpufreq_policy to cpumask_var_t") which missed updating
all the powerpc (at least) cpufreq drivers.

Reverting that one commit required fixups, so I reverted merge commit
4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
instead.

I am hoping that this will be fixed soon and that revert doesn't
propagate more pain through today's linux-next.

This branch was last committed to in the tip tree on Jan 7 (the patch
above was committed on Jan 6) but was never propagated to linux-next
before being merged into your tree yesterday.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1426 bytes --]

Hi Linus,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment

Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
convert struct cpufreq_policy to cpumask_var_t") which missed updating
all the powerpc (at least) cpufreq drivers.

Reverting that one commit required fixups, so I reverted merge commit
4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
instead.

I am hoping that this will be fixed soon and that revert doesn't
propagate more pain through today's linux-next.

This branch was last committed to in the tip tree on Jan 7 (the patch
above was committed on Jan 6) but was never propagated to linux-next
before being merged into your tree yesterday.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

Hi Linus,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment

Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
convert struct cpufreq_policy to cpumask_var_t") which missed updating
all the powerpc (at least) cpufreq drivers.

Reverting that one commit required fixups, so I reverted merge commit
4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
instead.

I am hoping that this will be fixed soon and that revert doesn't
propagate more pain through today's linux-next.

This branch was last committed to in the tip tree on Jan 7 (the patch
above was committed on Jan 6) but was never propagated to linux-next
before being merged into your tree yesterday.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Aleksey Senin]

After another investigation of this problem, I think that proposed
solution is #ifdef as good for a first stage. IPv6 support is mandatory
when we are talking about running linux in some organization. But, of
course, the way how it implemented in IB stack should be changed. So on
the second stage, I'd like drop out these "defines" and at the time of
module initialization obtain addresses of IPv6 functions and in the case
if they are present at the runtime, call them. It should be nice
solution for RMDA_CM and IPoIB modules.
On Sun, 2008-12-28 at 19:44 -0800, Roland Dreier wrote:
> > ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
>  > ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!
>  > 
>  > Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
>  > Add support for translating IPv6 addresses").  This requires a dependency
>  > on IPV6.
> 
> So how do we want to fix this?  (This question is mostly directed to the
> IB guys)  One possibility is to make all this depend on IPV6 in Kconfig,
> but I think we want the RDMA CM to be buildable/usable even if IPv6
> isn't enabled.  A better option is to just put all the IPv6 related
> stuff into
> 
> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> 
> and add a Kconfig dependency on (IPV6 || IPV6=n) as we did for IPoIB.
> 
> But then this leads to the behavior that loading the RDMA CM will cause
> the ipv6 module to be loaded if IPV6=m in the kernel config, even if the
> administrator doesn't want to enable IPv6, just as with IPoIB today.
> And people already complain about that.
> 
> Anyone see a better solution (which we could use for IPoIB even)?
> 
>  - R.

Re: linux-next: origin tree build failure

[Roland Dreier]

 > ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
 > ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!
 > 
 > Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
 > Add support for translating IPv6 addresses").  This requires a dependency
 > on IPV6.

So how do we want to fix this?  (This question is mostly directed to the
IB guys)  One possibility is to make all this depend on IPV6 in Kconfig,
but I think we want the RDMA CM to be buildable/usable even if IPv6
isn't enabled.  A better option is to just put all the IPv6 related
stuff into

#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)

and add a Kconfig dependency on (IPV6 || IPV6=n) as we did for IPoIB.

But then this leads to the behavior that loading the RDMA CM will cause
the ipv6 module to be loaded if IPV6=m in the kernel config, even if the
administrator doesn't want to enable IPv6, just as with IPoIB today.
And people already complain about that.

Anyone see a better solution (which we could use for IPoIB even)?

 - R.

Re: linux-next: origin tree build failure

[Roland Dreier]

 > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
 > 
 > ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
 > ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!
 > 
 > Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
 > Add support for translating IPv6 addresses").  This requires a dependency
 > on IPV6.

Thanks, I'll get a fix queued up.  Sorry about that.

 - R.

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Hi Roland,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!

Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
Add support for translating IPv6 addresses").  This requires a dependency
on IPV6.

I have reverted that commit for today (which fixes the build, but may not
be the correct solution).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Mon, 29 Dec 2008, Stephen Rothwell wrote:
> 
> Maybe someone should have warned Linus about the below known interaction
> between the net tree and the cifs tree ...

Gaah. I should have grepped for it, since the other place caused a 
conflict that I fixed. And I even tested that the result of my conflict 
resolution compiled, but since I don't configure cifs myself, I literally 
tested just the conflicting file.

Applied the fix, thanks,

		Linus

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Dave, Neil,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/net/ibmveth.c: In function 'ibmveth_poll':
drivers/net/ibmveth.c:1034: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
drivers/net/ibmveth.c:1034: error: too many arguments to function 'netif_rx_reschedule'

Another miss in commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove
unused netdev arg from some NAPI interfaces").

I have added the following patch for today.

(I wonder how many more there will be? :-()

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Dec 2008 10:56:00 +1100
Subject: [PATCH] net: ibmveth NAPI interface cleanup fix

Commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove unused
netdev arg from some NAPI interfaces") missed one spot.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ibmveth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 1f055a9..9bc0f17 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1031,7 +1031,7 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
 		netif_rx_complete(napi);
 
 		if (ibmveth_rxq_pending_buffer(adapter) &&
-		    netif_rx_reschedule(netdev, napi)) {
+		    netif_rx_reschedule(napi)) {
 			lpar_rc = h_vio_signal(adapter->vdev->unit_address,
 					       VIO_IRQ_DISABLE);
 			goto restart_poll;
-- 
1.6.0.5

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Dave, Neil,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 'netif_rx_reschedule'

Caused by commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove
unused netdev arg from some NAPI interfaces") which missed a call that
needed fixing up.  This commit was never in a linux-next tree.

I have added the below patch for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Dec 2008 10:46:13 +1100
Subject: [PATCH] net: ehea NAPI interface cleanup fix

Commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove unused
netdev arg from some NAPI interfaces") missed one spot.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ehea/ehea_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 035aa7d..a2f1905 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -841,7 +841,7 @@ static int ehea_poll(struct napi_struct *napi, int budget)
 		if (!cqe && !cqe_skb)
 			return rx;
 
-		if (!netif_rx_reschedule(dev, napi))
+		if (!netif_rx_reschedule(napi))
 			return rx;
 
 		cqe_skb = ehea_proc_cqes(pr, EHEA_POLL_MAX_CQES);
-- 
1.6.0.5

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Steve, Dave,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

fs/cifs/cifsfs.c: In function 'cifs_show_options':
fs/cifs/cifsfs.c:364: error: 'NIP6_FMT' undeclared (first use in this function)
fs/cifs/cifsfs.c:364: error: (Each undeclared identifier is reported only once
fs/cifs/cifsfs.c:364: error: for each function it appears in.)
fs/cifs/cifsfs.c:365: error: implicit declaration of function 'NIP6'

Maybe someone should have warned Linus about the below known interaction
between the net tree and the cifs tree ...

I have applied the patch to today's linux-next tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Date: Wed, 3 Dec 2008 13:53:12 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Steve French <smfrench@gmail.com>, <linux-cifs-client@lists.samba.org>
Cc: linux-next@vger.kernel.org, Harvey Harrison <harvey.harrison@gmail.com>,
 "David S. Miller" <davem@davemloft.net>, Jeff Layton <jlayton@redhat.com>
Subject: Re: linux-next: cifs tree build failure
Message-Id: <20081203135312.60d4518d.sfr@canb.auug.org.au>
In-Reply-To: <20081202132318.7e1581db.sfr@canb.auug.org.au>
References: <20081202132318.7e1581db.sfr@canb.auug.org.au>
X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Steve, Dave,

On Tue, 2 Dec 2008 13:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> fs/cifs/cifsfs.c: In function 'cifs_show_options':
> fs/cifs/cifsfs.c:363: error: 'NIP6_FMT' undeclared (first use in this function)
> fs/cifs/cifsfs.c:363: error: (Each undeclared identifier is reported only once
> fs/cifs/cifsfs.c:363: error: for each function it appears in.)
> fs/cifs/cifsfs.c:364: error: implicit declaration of function 'NIP6'
> 
> Caused by the interaction of commits
> b189db5d299c6824780af5590564ff608adb3dea ("net: remove NIP6(), NIP6_FMT,
> NIP6_SEQFMT and final users") from the net tree and
> 20c4eef4f817ff65337e2fb3f1f5df52eeca09eb ("cifs: display addr and
> prefixpath options in /proc/mounts") from the cifs tree.

Today I have fixed this by applying a merge fix patch (see below) and
will carry this as necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Dec 2008 13:49:23 +1100
Subject: [PATCH] cifs: update for new IP4/6 address printing

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/cifs/cifsfs.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 061a1dc..1b09330 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -362,12 +362,12 @@ cifs_show_options(struct seq_file *s, struct vfsmount *m)
 					switch (server->addr.sockAddr6.
 						sin6_family) {
 					case AF_INET6:
-						seq_printf(s, NIP6_FMT,
-							   NIP6(server->addr.sockAddr6.sin6_addr));
+						seq_printf(s, "%pI6",
+							   &server->addr.sockAddr6.sin6_addr);
 						break;
 					case AF_INET:
-						seq_printf(s, NIPQUAD_FMT,
-							   NIPQUAD(server->addr.sockAddr.sin_addr.s_addr));
+						seq_printf(s, "%pI4",
+							   &server->addr.sockAddr.sin_addr.s_addr);
 						break;
 					}
 				}
-- 
1.5.6.5

Re: linux-next: origin tree build failure

[Ralf Baechle]

On Thu, Oct 16, 2008 at 11:31:12AM +1100, Stephen Rothwell wrote:

> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
> drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
> drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
> drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
> drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
> drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
> drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'
> 
> Caused by commit 5f119f29063c9a9bf1ab40112c02710c2db84f29 ("MIPS: DS1286:
> New RTC driver") which presumably needs to depend in some architecture or
> feature.
> 
> I just reverted it for now.

It's just missing an include which Geert has already posted in a different
thread.

As far as I can say these two RTC chips are only being uses in MIPS
systems so maybe it's a good idea to allow configuring the driver if it
builds and does no harm on another platform/architecture?  I can cook up
a patch if that's what people want.

  Ralf

Re: linux-next: origin tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Oct 2008 11:35:31 +1100

> Hi Linus,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
> drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
> drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'

This part looks simply like a missing asm/io.h include.

MIPS is getting it implicitly somehow.

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

Hi Linus,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap'
drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast
drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap'

Caused by commit d1dbd82e2ff02181a7102088a9fe83e17ddbcb47 ("RTC: M48T35:
new RTC driver") which also presumably should depend on some architecture
or feature.

I have reverted it for now.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Hi Linus,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl'
drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel'
drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap'
drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast
drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap'

Caused by commit 5f119f29063c9a9bf1ab40112c02710c2db84f29 ("MIPS: DS1286:
New RTC driver") which presumably needs to depend in some architecture or
feature.

I just reverted it for now.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: origin tree build failure

[Mark Brown]

On Wed, Oct 15, 2008 at 11:33:19AM +0200, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> hm:

>  Author:     Mark Brown <broonie@opensource.wolfsonmicro.com>
>  AuthorDate: Fri Oct 10 15:58:14 2008 +0100
>  Commit:     Liam Girdwood <lrg@slimlogic.co.uk>
>  CommitDate: Mon Oct 13 21:51:56 2008 +0100

> if a patch is merged as agressively as that, it should at minimum be 
> tested a bit.

It has been tested (I've got some systems here that rely on the WM8350
fairly heavily) - what was missing was cross platform testing on
architectures that don't define NO_IRQ.  The code is rather older than
the dates indicate due to some rearrangement of the patch series, though
obviously out of tree stuff has to be taken with a grain of salt.

Anyway, I've posted a patch removing the use of NO_IRQ from the driver
(as <1224066054-24401-1-git-send-email-broonie@opensource.wolfsonmicro.com>)
which should hopefully be merged shortly.

Re: linux-next: origin tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus, Mark,
> 
> Today's linux-next build (just Linus' tree) (x86_64 allmodconfig) failed
> like this:
> 
> drivers/mfd/wm8350-core.c: In function 'wm8350_device_init':
> drivers/mfd/wm8350-core.c:1220: error: 'NO_IRQ' undeclared (first use in this function)
> 
> Caused by commit ebccec0fa4e35dff0c18663a492a65f4dc6cad7a ("mfd: Add
> WM8350 interrupt support").

hm:

 Author:     Mark Brown <broonie@opensource.wolfsonmicro.com>
 AuthorDate: Fri Oct 10 15:58:14 2008 +0100
 Commit:     Liam Girdwood <lrg@slimlogic.co.uk>
 CommitDate: Mon Oct 13 21:51:56 2008 +0100

if a patch is merged as agressively as that, it should at minimum be 
tested a bit.

	Ingo

Re: linux-next: origin tree build failure

[Alan Cox]

> drivers/mfd/wm8350-core.c: In function 'wm8350_device_init':
> drivers/mfd/wm8350-core.c:1220: error: 'NO_IRQ' undeclared (first use in this function)
> 
> Caused by commit ebccec0fa4e35dff0c18663a492a65f4dc6cad7a ("mfd: Add
> WM8350 interrupt support").

Should just be testing !irq

> 
> I applied the following (probably incorrect) patch.  Maybe this driver
> needs to be restricted to certain architectures?  (NO_IRQ appears to only
> be defined for arm, blackfin, powerpc, mn10300 and parisc)

NO_IRQ is an old IDE private define that some people kept abusing

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Wed, 15 Oct 2008, Mark Brown wrote:
>
> That would be people on the ARM list.  Unless I misremember I first
> heard about using NO_IRQ from the ARM list in connection with another
> (much less ARM-specific) driver only within the past six months.

ARM should just do

	#define NO_IRQ (0)

and be done with it. It's what powerpc did long ago. That allows old 
broken drivers to work, and doesn't require new drivers to introduce more 
NO_IRQ insanity.

If there is a "hardware irq 0", either it can be special (eg some 
system-only irq not used by any drivers) or the irq numbers can/must be 
remapped.

ARM already converted to the generic irq layer, and there are actually 
parts of that that know that irq 0 has special meaning. Like the 
autoprobing and spurious irq handling. Of course, ARM may not care, and 
the generic code is generally trying to avoid any assumptions, but it's 
still true that all generic _drivers_ do the whole "if (irq)" thing.

Yeah, yeah, we've let NO_IRQ poison some subsystems (like IDE and 
apparently parts of i2c), but that was a mistake.

		Linus

Re: linux-next: origin tree build failure

[Mark Brown]

On Tue, Oct 14, 2008 at 04:43:12PM -0700, Linus Torvalds wrote:

> I assume that broken driver is some ARM-specific thing. I certainly don't 
> want to see NO_IRQ in any general drivers. So instead of having that 
> NO_IRQ insanity spread any more, I'd much rather see the driver either 
> fixed to not use it, or just marked ARM-only.

It's not ARM-specific, though the overwhelming majority of users will be
ARM systems (it's an embedded PMIC) - I'll post a patch tomorrow
changing it to check for non-zero IRQ instead.  That makes other bits of
the driver easier, anyway.

> The proper way to test for whether an interrupt is valid or not is to do

> 	if (dev->irq) {
> 		...

> and no other. There is no spoon. That NO_IRQ was insane. And architectures 
> or drivers that still think otherwise should fix themselves.

That would be people on the ARM list.  Unless I misremember I first
heard about using NO_IRQ from the ARM list in connection with another
(much less ARM-specific) driver only within the past six months.

Re: linux-next: origin tree build failure

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 14 Oct 2008 16:43:12 -0700 (PDT)

> The proper way to test for whether an interrupt is valid or not is to do
> 
> 	if (dev->irq) {
> 		...
> 
> and no other. There is no spoon. That NO_IRQ was insane. And architectures 
> or drivers that still think otherwise should fix themselves.

Agreed.  Someone tried to add something similar to the network
driver phylib layer, and I told them similarly.

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Wed, 15 Oct 2008, Stephen Rothwell wrote:
>
> +#ifndef NO_IRQ
> +#define NO_IRQ	0
> +#endif

Btw, as to why not do this idiocy, just grep for it.

We have several drivers that try to do something this stupid. Don't take 
my word for it? Look for them. And see them do things like

 - drivers/scsi/arm/fas216.h:

	#ifndef NO_IRQ
	#define NO_IRQ 255
	#endif

 - drivers/pcmcia/pd6729.c (really interesting):

	#ifndef NO_IRQ
	#define NO_IRQ  ((unsigned int)(0))
	#endif

 - drivers/rtc/rtc-m48t59.c:

	#ifndef NO_IRQ
	#define NO_IRQ  (-1)
	#endif

so please don't add yet another version to the insanity. Just mark 
anything with NO_IRQ as BROKEN or ARM-specific, or something.

		Linus

Re: linux-next: origin tree build failure

[Linus Torvalds]

On Wed, 15 Oct 2008, Stephen Rothwell wrote:
> 
> drivers/mfd/wm8350-core.c: In function 'wm8350_device_init':
> drivers/mfd/wm8350-core.c:1220: error: 'NO_IRQ' undeclared (first use in this function)
> 
> Caused by commit ebccec0fa4e35dff0c18663a492a65f4dc6cad7a ("mfd: Add
> WM8350 interrupt support").
> 
> I applied the following (probably incorrect) patch.  Maybe this driver
> needs to be restricted to certain architectures?  (NO_IRQ appears to only
> be defined for arm, blackfin, powerpc, mn10300 and parisc)

Grr. Can we please just get rid of that IDIOTIC thing instead?

NO_IRQ was a bad idea to begin with. Let's not add more.

I assume that broken driver is some ARM-specific thing. I certainly don't 
want to see NO_IRQ in any general drivers. So instead of having that 
NO_IRQ insanity spread any more, I'd much rather see the driver either 
fixed to not use it, or just marked ARM-only.

The proper way to test for whether an interrupt is valid or not is to do

	if (dev->irq) {
		...

and no other. There is no spoon. That NO_IRQ was insane. And architectures 
or drivers that still think otherwise should fix themselves.

		Linus

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Linus, Mark,

Today's linux-next build (just Linus' tree) (x86_64 allmodconfig) failed
like this:

drivers/mfd/wm8350-core.c: In function 'wm8350_device_init':
drivers/mfd/wm8350-core.c:1220: error: 'NO_IRQ' undeclared (first use in this function)

Caused by commit ebccec0fa4e35dff0c18663a492a65f4dc6cad7a ("mfd: Add
WM8350 interrupt support").

I applied the following (probably incorrect) patch.  Maybe this driver
needs to be restricted to certain architectures?  (NO_IRQ appears to only
be defined for arm, blackfin, powerpc, mn10300 and parisc)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 15 Oct 2008 09:57:33 +1100
Subject: [PATCH] wm8350-core needs NO_IRQ

and that is not defined for most architectures.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/mfd/wm8350-core.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/wm8350-core.c b/drivers/mfd/wm8350-core.c
index 25a7a5d..6e3a509 100644
--- a/drivers/mfd/wm8350-core.c
+++ b/drivers/mfd/wm8350-core.c
@@ -1156,6 +1156,10 @@ static void wm8350_client_dev_register(struct wm8350 *wm8350,
 	}
 }
 
+#ifndef NO_IRQ
+#define NO_IRQ	0
+#endif
+
 int wm8350_device_init(struct wm8350 *wm8350, int irq,
 		       struct wm8350_platform_data *pdata)
 {
-- 
1.5.6.5

linux-next: origin tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/pci/ca0106/ca0106_main.c:263: error: syntax error before '{' token
sound/pci/ca0106/ca0106_main.c:264: error: field name not in record or union initializer
sound/pci/ca0106/ca0106_main.c:264: error: (near initialization for 'ca0106_chip_details')
sound/pci/ca0106/ca0106_main.c:264: warning: missing braces around initializer
sound/pci/ca0106/ca0106_main.c:264: warning: (near initialization for 'ca0106_chip_details[10]')
sound/pci/ca0106/ca0106_main.c:264: warning: initialization makes integer from pointer without a cast
sound/pci/ca0106/ca0106_main.c:264: error: initializer element is not computable at load time
sound/pci/ca0106/ca0106_main.c:264: error: (near initialization for 'ca0106_chip_details[10].serial')
sound/pci/ca0106/ca0106_main.c:265: error: field name not in record or union initializer
sound/pci/ca0106/ca0106_main.c:265: error: (near initialization for 'ca0106_chip_details')
sound/pci/ca0106/ca0106_main.c:266: error: field name not in record or union initializer
sound/pci/ca0106/ca0106_main.c:266: error: (near initialization for 'ca0106_chip_details')
sound/pci/ca0106/ca0106_main.c:272: error: syntax error before '{' token

This is just Linus' tree (head commit
d25e26b61d59370eee8b7f2634641eb0fa76e952 "[x86] Clean up MAXSMP Kconfig,
and limit NR_CPUS to 512").

Introduced by commit c5d44423d55e3abca7b1d544af9e4c97ec203999 ("ALSA:
CA0106 on MSI K8N Diamond PLUS Motherboard").

I added the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 26 Aug 2008 10:33:32 +1000
Subject: [PATCH] ALSA: fix for CA0106 on MSI K8N Diamond PLUS Motherboard

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/pci/ca0106/ca0106_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c
index 03a274b..6abe8a3 100644
--- a/sound/pci/ca0106/ca0106_main.c
+++ b/sound/pci/ca0106/ca0106_main.c
@@ -254,7 +254,7 @@ static struct snd_ca0106_details ca0106_chip_details[] = {
 	   .name   = "MSI K8N Diamond MB",
 	   .gpio_type = 2,
 	   .i2c_adc = 1,
-	   .spi_dac = 2 }
+	   .spi_dac = 2 },
 	 /* Shuttle XPC SD31P which has an onboard Creative Labs
 	  * Sound Blaster Live! 24-bit EAX
 	  * high-definition 7.1 audio processor".
-- 
1.5.6.3

Re: linux-next: origin tree build failure

[James Morris]

On Mon, 18 Aug 2008, David Howells wrote:

> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > As expected (reported by David Fries), today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from include/linux/tracehook.h:52,
> >                  from arch/powerpc/kernel/signal.c:13:
> > include/linux/security.h: In function 'security_ptrace_traceme':
> > include/linux/security.h:1760: error: 'parent' undeclared (first use in this function)
> > 
> > Caused by commit 5cd9c58fbe9ec92b45b27e131719af4f2bd9eb40 ("security: Fix
> > setting of PF_SUPERPRIV by __capable()").  The version of this commit
> > that has been in the linux-next tree from Aug 8 to Aug 15 is correct, so
> > I have no idea what happened.
> 
> I accidentally posted an old patch which James, maybe, substituted for the
> good one that he had.

I took the patch you sent me, although after some IRC discussion, what 
should have happened is that I should have git-cherry-pick'd the patch 
from the next-creds branch (where it had been tested in linux-next for 
some time) into for-linus rather than asking for an updated patch.

Sorry folks.


- James
-- 
James Morris
<jmorris@namei.org>

Re: linux-next: origin tree build failure

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> As expected (reported by David Fries), today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/tracehook.h:52,
>                  from arch/powerpc/kernel/signal.c:13:
> include/linux/security.h: In function 'security_ptrace_traceme':
> include/linux/security.h:1760: error: 'parent' undeclared (first use in this function)
> 
> Caused by commit 5cd9c58fbe9ec92b45b27e131719af4f2bd9eb40 ("security: Fix
> setting of PF_SUPERPRIV by __capable()").  The version of this commit
> that has been in the linux-next tree from Aug 8 to Aug 15 is correct, so
> I have no idea what happened.

I accidentally posted an old patch which James, maybe, substituted for the
good one that he had.

David

linux-next: origin tree build failure

[Stephen Rothwell]

Hi Linus,

As expected (reported by David Fries), today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/linux/tracehook.h:52,
                 from arch/powerpc/kernel/signal.c:13:
include/linux/security.h: In function 'security_ptrace_traceme':
include/linux/security.h:1760: error: 'parent' undeclared (first use in this function)

Caused by commit 5cd9c58fbe9ec92b45b27e131719af4f2bd9eb40 ("security: Fix
setting of PF_SUPERPRIV by __capable()").  The version of this commit
that has been in the linux-next tree from Aug 8 to Aug 15 is correct, so
I have no idea what happened.

More care needed ...

I applied the following patch from David Fries.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Date: Sat, 16 Aug 2008 20:17:11 -0500
From: David Fries <david@fries.net>
To: David Howells <dhowells@redhat.com>
Cc: sfr@canb.auug.org.au, jmorris@namei.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org
Subject: Fix setting of PF_SUPERPRIV by __capable()

The first two submissions this patch had parent for the argument, the third
one has child then parent and fails to compile with SECURITY disabled.
Please apply the following patch.

> +static inline int security_ptrace_traceme(struct task_struct *child)
>  {
> -	return cap_ptrace(parent, child, mode);
> +	return cap_ptrace_traceme(parent);
>  }

    security_ptrace_traceme error: 'parent' undeclared

    s/child/parent/

    Signed-off-by: David Fries <david@fries.net>

diff --git a/include/linux/security.h b/include/linux/security.h
index 2ee5ecf..80c4d00 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1755,7 +1755,7 @@ static inline int security_ptrace_may_access(struct task_struct *child,
 	return cap_ptrace_may_access(child, mode);
 }
 
-static inline int security_ptrace_traceme(struct task_struct *child)
+static inline int security_ptrace_traceme(struct task_struct *parent)
 {
 	return cap_ptrace_traceme(parent);
 }

linux-next: origin tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Hi all,

Today's linux-next (really just Linus' tree) build (powerpc
ppc64_defconfig) failed like this:

fs/nfs/nfsroot.c:130: error: tokens causes a section type conflict

"tokens" is a match_table_t which has const added to it in commit
f9247273cb69ba101877e946d2d83044409cc8c5 "UFS: add const to parser token
table".  But "tokens" is also marked __initdata.  I changed it to
__initconst.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]