linux-next: origin tree build failure

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

[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.

[PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes

[Benjamin Herrenschmidt]

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,

Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes

[Ingo Molnar]

* 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

Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes

[Benjamin Herrenschmidt]

On Mon, 2009-01-12 at 09:34 +0100, Ingo Molnar wrote:
> * 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.

Hrm... which config are you using ? ppc64_defconfig has them all on.

Cheers,
Ben.

Re: [PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes

[Olof Johansson]

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

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

[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]

* 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: 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

[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]

* 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