* [PATCH -next] libfc: needs CRC32
From: Randy Dunlap @ 2009-01-12 18:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, scsi, James Bottomley, Andrew Morton
In-Reply-To: <20090112154539.4857f533.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
libfc uses crc32 functions, so cause it to be built
via select:
drivers/built-in.o: In function `fc_frame_crc_check':
(.text+0x75dae): undefined reference to `crc32_le'
drivers/built-in.o: In function `fc_fcp_recv':
fc_fcp.c:(.text+0x7b919): undefined reference to `crc32_le'
fc_fcp.c:(.text+0x7b9d5): undefined reference to `crc32_le'
fc_fcp.c:(.text+0x7ba54): undefined reference to `crc32_le'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/scsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20090112.orig/drivers/scsi/Kconfig
+++ linux-next-20090112/drivers/scsi/Kconfig
@@ -608,6 +608,7 @@ config SCSI_FLASHPOINT
config LIBFC
tristate "LibFC module"
select SCSI_FC_ATTRS
+ select CRC32
---help---
Fibre Channel library module
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for January 12 (cifs vs. staging)
From: Randy Dunlap @ 2009-01-12 18:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, sfrench, Greg KH
In-Reply-To: <20090112154539.4857f533.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Some people took me at my word and so we have the 2.6.30 code starting to
> trickle in already.
When CIFS is built-in (=y) and staging/rt28[67]0 =y, there are multiple
definitions of:
build-r8250.out:(.text+0x1d8ad0): multiple definition of `MD5Init'
build-r8250.out:(.text+0x1dbb30): multiple definition of `MD5Update'
build-r8250.out:(.text+0x1db9b0): multiple definition of `MD5Final'
all of which need to have more unique identifiers for their global
symbols (e.g., rt28_md5_init, cifs_md5_init, foo, blah, bar).
--
~Randy
^ permalink raw reply
* Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Olof Johansson @ 2009-01-12 17:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Stephen Rothwell, linux-next, Rusty Russell,
Mike Travis, Ingo Molnar, Andrew Morton, David S. Miller, LKML,
Paul Mackerras, linuxppc-dev, arndb
In-Reply-To: <1231719721.22571.9.camel@pasglop>
On Mon, Jan 12, 2009 at 11:22:01AM +1100, Benjamin Herrenschmidt wrote:
> This updates the cpufreq drivers in arch/powerpc so they build again
> after the core cpufreq changes that broke them in commit
> in835481d9bcd65720b473db6b38746a74a3964218.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
> drivers still work ?
Tested fine on pasemi.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Olof Johansson @ 2009-01-12 17:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Stephen Rothwell, linux-next, Rusty Russell,
Mike Travis, Ingo Molnar, Andrew Morton, David S. Miller, LKML,
Paul Mackerras, linuxppc-dev, arndb
In-Reply-To: <1231719721.22571.9.camel@pasglop>
On Mon, Jan 12, 2009 at 11:22:01AM +1100, Benjamin Herrenschmidt wrote:
> This updates the cpufreq drivers in arch/powerpc so they build again
> after the core cpufreq changes that broke them in commit
> in835481d9bcd65720b473db6b38746a74a3964218.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
> drivers still work ?
Tested fine on pasemi.
-Olof
^ permalink raw reply
* Re: linux-next: drm tree build failure
From: Richard Purdie @ 2009-01-12 17:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Dave Airlie, linux-next
In-Reply-To: <20090112141249.f9d72f6c.sfr@canb.auug.org.au>
On Mon, 2009-01-12 at 14:12 +1100, Stephen Rothwell wrote:
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/i915_dma.c: In function 'i915_initialize':
> drivers/gpu/drm/i915/i915_dma.c:183: error: 'drm_i915_init_t' has no member named 'sarea_priv'
>
> Immediate cause is commit 21edb2690395e7a5281d0d5b5b8a9362491c9879
> ("drm/i915: setup sarea properly in master_priv").
>
> I have dropped the drm tree for today.
I've also mentioned to this to Dave and there is a fixed version of that
patch in his inbox.
Cheers,
Richard
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-01-12 10:44 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Rusty Russell, LKML,
Mike Travis, linuxppc-dev, linux-next, Paul Mackerras,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <1231753791.8959.7.camel@localhost>
* 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
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-01-12 10:44 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Rusty Russell, LKML, Mike Travis, linuxppc-dev,
linux-next, Paul Mackerras, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <1231753791.8959.7.camel@localhost>
* 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
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-01-12 10:44 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Rusty Russell, LKML,
Mike Travis, linuxppc-dev, linux-next, Paul Mackerras,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <1231753791.8959.7.camel@localhost>
* 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
^ permalink raw reply
* Re: linux-next: mfd tree build failure
From: Balaji Rao @ 2009-01-12 10:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Samuel Ortiz, linux-next
In-Reply-To: <20090112140318.e25cd2bf.sfr@canb.auug.org.au>
On Mon, Jan 12, 2009 at 02:03:18PM +1100, Stephen Rothwell wrote:
> Hi Samuel,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> ERROR: "__set_irq_handler" [drivers/mfd/pcf50633-core.ko] undefined!
> ERROR: "handle_level_irq" [drivers/mfd/pcf50633-core.ko] undefined!
>
> Immediate cause is clearly commit
> f52046b14b1e1a8a02ae48d0c69d39c5e204644f ("mfd: PCF50633 core driver")
> which introduces this code. The above functions don't appear to be
> exported to modules.
>
> I have dropped the mfd tree for today.
Oh, sorry about this. I can actually do without this. Here's the patch.
Sameo, can you please apply it ?
pcf50633: Remove references to non-exported functions
Remove references to set_irq_type and handle_level_irq which are not
exported to modules.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index 24508e2..ea9488e 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -626,7 +626,6 @@ static int __devinit pcf50633_probe(struct i2c_client *client,
}
if (client->irq) {
- set_irq_handler(client->irq, handle_level_irq);
ret = request_irq(client->irq, pcf50633_irq,
IRQF_TRIGGER_LOW, "pcf50633", pcf);
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Michael Ellerman @ 2009-01-12 9:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Rusty Russell, LKML,
Mike Travis, linuxppc-dev, linux-next, Paul Mackerras,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <20090112090552.GD26750@elte.hu>
[-- 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 --]
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-01-12 9:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, Linus Torvalds, linux-next, Rusty Russell,
Mike Travis, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20090112202427.3b918490.sfr@canb.auug.org.au>
* 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
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-01-12 9:24 UTC (permalink / raw)
To: Ingo Molnar
Cc: Benjamin Herrenschmidt, Linus Torvalds, linux-next, Rusty Russell,
Mike Travis, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20090112090552.GD26750@elte.hu>
[-- 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 --]
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-01-12 9:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Linus Torvalds, linux-next, Rusty Russell,
Mike Travis, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1231719015.22571.4.camel@pasglop>
* 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
^ permalink raw reply
* Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Ingo Molnar @ 2009-01-12 8:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Stephen Rothwell, linux-next, Rusty Russell,
Mike Travis, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev, Olof Johansson, arndb
In-Reply-To: <1231719721.22571.9.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This updates the cpufreq drivers in arch/powerpc so they build again
> after the core cpufreq changes that broke them in commit
> in835481d9bcd65720b473db6b38746a74a3964218.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
> drivers still work ?
>
> Linus, you can probably merge this now to fix the build problems.
Thanks Ben!
The powerpc defconfig built fine - you might wan to turn on cpufreq in the
powerpc defconfig so that cross-build tests can catch problems like this.
Ingo
^ permalink raw reply
* linux-next: Tree for January 12
From: Stephen Rothwell @ 2009-01-12 4:45 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6994 bytes --]
Hi all,
Some people took me at my word and so we have the 2.6.30 code starting to
trickle in already.
Changes since 20090109:
Undropped tree:
ocfs2
Dropped trees (temporarily):
rr (difficult conflict)
mfd (build problem)
drm (build problem)
cpu_alloc (build problem)
audit (difficult conflicts)
Linus' tree gained a build failure which caused me to revert a merge.
The driver-core tree inherited a conflicts from the scsi tree.
The scsi tree lost its conflicts.
The ocfs2 tree lost its build failure.
The mtd tree lost its conflicts.
The blk-removal tree lost its conflict.
The firmware tree lost its conflicts.
The kmemcheck tree inherited a conflicts from the nommu tree.
The mfd tree gained a build failure so I dropped it.
The drm tree gained a build failure so I dropped it.
The nommu tree lost its conflict.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 129 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Created commit a3e6439: Revert "Merge branch 'cpus4096-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip"
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in kernel/auditsc.c
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/scsi/scsi_ioctl.c
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in kernel/rcuclassic.c
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
CONFLICT (content): Merge conflict in kernel/time/tick-common.c
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/kernel/sysfs.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git reset --hard
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in kernel/fork.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
$ git reset --hard HEAD^
Merging hdlc/hdlc-next
Merging drm/drm-next
$ git reset --hard HEAD^
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging squashfs/master
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: drm tree build failure
From: Stephen Rothwell @ 2009-01-12 3:12 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, Richard Purdie
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_initialize':
drivers/gpu/drm/i915/i915_dma.c:183: error: 'drm_i915_init_t' has no member named 'sarea_priv'
Immediate cause is commit 21edb2690395e7a5281d0d5b5b8a9362491c9879
("drm/i915: setup sarea properly in master_priv").
I have dropped the drm tree 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 --]
^ permalink raw reply
* linux-next: mfd tree build failure
From: Stephen Rothwell @ 2009-01-12 3:03 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linux-next, Balaji Rao
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hi Samuel,
Today's linux-next build (x86_64 allmodconfig) failed like this:
ERROR: "__set_irq_handler" [drivers/mfd/pcf50633-core.ko] undefined!
ERROR: "handle_level_irq" [drivers/mfd/pcf50633-core.ko] undefined!
Immediate cause is clearly commit
f52046b14b1e1a8a02ae48d0c69d39c5e204644f ("mfd: PCF50633 core driver")
which introduces this code. The above functions don't appear to be
exported to modules.
I have dropped the mfd tree 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 --]
^ permalink raw reply
* [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Benjamin Herrenschmidt @ 2009-01-12 0:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, Rusty Russell, Mike Travis,
Ingo Molnar, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev, Olof Johansson, arndb
In-Reply-To: <1231719015.22571.4.camel@pasglop>
This updates the cpufreq drivers in arch/powerpc so they build again
after the core cpufreq changes that broke them in commit
in835481d9bcd65720b473db6b38746a74a3964218.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
drivers still work ?
Linus, you can probably merge this now to fix the build problems.
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index ec7c8f4..e6506cd 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -118,7 +118,7 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cur = cbe_freqs[cur_pmode].frequency;
#ifdef CONFIG_SMP
- policy->cpus = per_cpu(cpu_sibling_map, policy->cpu);
+ cpumask_copy(policy->cpus, &per_cpu(cpu_sibling_map, policy->cpu));
#endif
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index a3c6c01..968c1c0 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -110,7 +110,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
}
/* initialize spu_gov_info for all affected cpus */
- for_each_cpu_mask(i, policy->cpus) {
+ for_each_cpu(i, policy->cpus) {
affected_info = &per_cpu(spu_gov_info, i);
affected_info->policy = policy;
}
@@ -127,7 +127,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
spu_gov_cancel_work(info);
/* clean spu_gov_info for all affected cpus */
- for_each_cpu_mask (i, policy->cpus) {
+ for_each_cpu (i, policy->cpus) {
info = &per_cpu(spu_gov_info, i);
info->policy = NULL;
}
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 86db47c..be2527a 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -213,7 +213,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("current astate is at %d\n",cur_astate);
policy->cur = pas_freqs[cur_astate].frequency;
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
ppc_proc_freq = policy->cur * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 4dfb4bc..beb3833 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -362,7 +362,7 @@ static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
* it actually must be one policy together with all others. */
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
cpufreq_frequency_table_get_attr(g5_cpu_freqs, policy->cpu);
return cpufreq_frequency_table_cpuinfo(policy,
^ permalink raw reply related
* [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Benjamin Herrenschmidt @ 2009-01-12 0:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, David S. Miller, arndb, Rusty Russell, LKML,
Mike Travis, linuxppc-dev, linux-next, Paul Mackerras,
Olof Johansson, Ingo Molnar, Andrew Morton
In-Reply-To: <1231719015.22571.4.camel@pasglop>
This updates the cpufreq drivers in arch/powerpc so they build again
after the core cpufreq changes that broke them in commit
in835481d9bcd65720b473db6b38746a74a3964218.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
drivers still work ?
Linus, you can probably merge this now to fix the build problems.
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index ec7c8f4..e6506cd 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -118,7 +118,7 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cur = cbe_freqs[cur_pmode].frequency;
#ifdef CONFIG_SMP
- policy->cpus = per_cpu(cpu_sibling_map, policy->cpu);
+ cpumask_copy(policy->cpus, &per_cpu(cpu_sibling_map, policy->cpu));
#endif
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index a3c6c01..968c1c0 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -110,7 +110,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
}
/* initialize spu_gov_info for all affected cpus */
- for_each_cpu_mask(i, policy->cpus) {
+ for_each_cpu(i, policy->cpus) {
affected_info = &per_cpu(spu_gov_info, i);
affected_info->policy = policy;
}
@@ -127,7 +127,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
spu_gov_cancel_work(info);
/* clean spu_gov_info for all affected cpus */
- for_each_cpu_mask (i, policy->cpus) {
+ for_each_cpu (i, policy->cpus) {
info = &per_cpu(spu_gov_info, i);
info->policy = NULL;
}
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 86db47c..be2527a 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -213,7 +213,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("current astate is at %d\n",cur_astate);
policy->cur = pas_freqs[cur_astate].frequency;
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
ppc_proc_freq = policy->cur * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 4dfb4bc..beb3833 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -362,7 +362,7 @@ static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
* it actually must be one policy together with all others. */
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
cpufreq_frequency_table_get_attr(g5_cpu_freqs, policy->cpu);
return cpufreq_frequency_table_cpuinfo(policy,
^ permalink raw reply related
* [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
From: Benjamin Herrenschmidt @ 2009-01-12 0:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, Rusty Russell, Mike Travis,
Ingo Molnar, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev, Olof Johansson, arndb
In-Reply-To: <1231719015.22571.4.camel@pasglop>
This updates the cpufreq drivers in arch/powerpc so they build again
after the core cpufreq changes that broke them in commit
in835481d9bcd65720b473db6b38746a74a3964218.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
drivers still work ?
Linus, you can probably merge this now to fix the build problems.
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index ec7c8f4..e6506cd 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -118,7 +118,7 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cur = cbe_freqs[cur_pmode].frequency;
#ifdef CONFIG_SMP
- policy->cpus = per_cpu(cpu_sibling_map, policy->cpu);
+ cpumask_copy(policy->cpus, &per_cpu(cpu_sibling_map, policy->cpu));
#endif
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index a3c6c01..968c1c0 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -110,7 +110,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
}
/* initialize spu_gov_info for all affected cpus */
- for_each_cpu_mask(i, policy->cpus) {
+ for_each_cpu(i, policy->cpus) {
affected_info = &per_cpu(spu_gov_info, i);
affected_info->policy = policy;
}
@@ -127,7 +127,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
spu_gov_cancel_work(info);
/* clean spu_gov_info for all affected cpus */
- for_each_cpu_mask (i, policy->cpus) {
+ for_each_cpu (i, policy->cpus) {
info = &per_cpu(spu_gov_info, i);
info->policy = NULL;
}
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 86db47c..be2527a 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -213,7 +213,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("current astate is at %d\n",cur_astate);
policy->cur = pas_freqs[cur_astate].frequency;
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
ppc_proc_freq = policy->cur * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 4dfb4bc..beb3833 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -362,7 +362,7 @@ static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
* it actually must be one policy together with all others. */
- policy->cpus = cpu_online_map;
+ cpumask_copy(policy->cpus, &cpu_online_map);
cpufreq_frequency_table_get_attr(g5_cpu_freqs, policy->cpu);
return cpufreq_frequency_table_cpuinfo(policy,
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-01-12 0:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, linux-next, Rusty Russell, Mike Travis,
Ingo Molnar, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20090112104837.69feedec.sfr@canb.auug.org.au>
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.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-01-12 0:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, linux-next, Rusty Russell, Mike Travis,
Ingo Molnar, Andrew Morton, David S. Miller, LKML, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20090112104837.69feedec.sfr@canb.auug.org.au>
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.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-01-12 0:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David S. Miller, Rusty Russell, LKML, Mike Travis, linuxppc-dev,
linux-next, Paul Mackerras, Ingo Molnar, Linus Torvalds,
Andrew Morton
In-Reply-To: <20090112104837.69feedec.sfr@canb.auug.org.au>
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.
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-01-11 23:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-next, Rusty Russell, Mike Travis, Ingo Molnar,
Andrew Morton, David S. Miller, LKML, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- 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 --]
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-01-11 23:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-next, Rusty Russell, Mike Travis, Ingo Molnar,
Andrew Morton, David S. Miller, LKML, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- 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 --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox