[PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Rene Rebe]

Hi,


--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla	2005-03-02 
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc	2005-03-02 
16:45:22.424152560 +0100
@@ -108,7 +108,7 @@
  int raid6_have_altivec(void)
  {
  	/* This assumes either all CPUs have Altivec or none does */
-	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
  }
  #endif


Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
             http://www.exactcode.de/ | http://www.t2-project.org/
             +49 (0)30  255 897 45

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Rene Rebe wrote:
> Hi,
> 
> 
> --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
> 16:44:56.407107752 +0100
> +++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
> 16:45:22.424152560 +0100
> @@ -108,7 +108,7 @@
>  int raid6_have_altivec(void)
>  {
>      /* This assumes either all CPUs have Altivec or none does */
> -    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> +    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;


I nominate this as a candidate for linux-2.6.11 release branch.  :)

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >Hi,
> >
> >
> >--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
> >16:44:56.407107752 +0100
> >+++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
> >16:45:22.424152560 +0100
> >@@ -108,7 +108,7 @@
> > int raid6_have_altivec(void)
> > {
> >     /* This assumes either all CPUs have Altivec or none does */
> >-    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> >+    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
> 
> 
> I nominate this as a candidate for linux-2.6.11 release branch.  :)

Except the patch is malformed, and even after light editing, does not
apply to the 2.6.11 kernel :(

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Rene Rebe]

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

Hi,

Greg KH wrote:

> Except the patch is malformed, and even after light editing, does not
> apply to the 2.6.11 kernel :(

Sorry - to match linux-kernel style I pasted it from gvim into 
thunderbird to make kernel folks happy. Here you find the patch as it 
applies to 2.6.11 attached.

Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
             http://www.exactcode.de/ | http://www.t2-project.org/
             +49 (0)30  255 897 45


[-- Attachment #2: arch-ppc-raid6-altivec.patch --]
[-- Type: text/plain, Size: 500 bytes --]


Tiny compile fix for the raid6 PowerPC/Altivec code.

  - Rene Rebe <rene@exactcode.de>

--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla	2005-03-02 16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc	2005-03-02 16:45:22.424152560 +0100
@@ -108,7 +108,7 @@
 int raid6_have_altivec(void)
 {
 	/* This assumes either all CPUs have Altivec or none does */
-	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
 }
 #endif
 

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >Hi,
> >
> >
> >--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
> >16:44:56.407107752 +0100
> >+++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
> >16:45:22.424152560 +0100
> >@@ -108,7 +108,7 @@
> > int raid6_have_altivec(void)
> > {
> >     /* This assumes either all CPUs have Altivec or none does */
> >-    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> >+    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
> 
> 
> I nominate this as a candidate for linux-2.6.11 release branch.  :)

Ok, I've fixed up the patch and applied it to a local tree that I've set
up to catch these things (it will live at
bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
set up how we are going to handle all of this.)

Feel free to start pointing stuff like this at me and chris (we'll also
be setting up an alias for it.)

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Greg KH wrote:

Two procedural suggestions...


> Ok, I've fixed up the patch and applied it to a local tree that I've set
> up to catch these things (it will live at
> bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
> set up how we are going to handle all of this.)

My suggestion would be one of two alternatives:

1) At each release, Linus clones
	linux.bkbits.net/linux-2.6
		to
	linux.bkbits.net/linux-2.6.11

and gives the "release team" access to push to linux-2.6.11 repo.


2) Create linux-release.bkbits.net, and some non-Linus person clones 
linux-2.6 at release time to linux-2.6.11.


This accomplishes two [minor] goals:
a) the tree lives at bkbits.net, as has a name associated with the goal 
of the project

b) The repo has the _exact_ name of the kernel release.  None of this 
"linux-2.6.11.y" stuff.  Just "linux-2.6.11".  Anything else violates 
the Principle of Least Surprise.


> Feel free to start pointing stuff like this at me and chris (we'll also
> be setting up an alias for it.)

I was wondering if it would be possible to setup a list on vger that is 
public, but read-only to everyone but the $sucker team.

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Chris Wright]

* Jeff Garzik (jgarzik@pobox.com) wrote:
> Greg KH wrote:
> 
> Two procedural suggestions...
> 
> >Ok, I've fixed up the patch and applied it to a local tree that I've set
> >up to catch these things (it will live at
> >bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
> >set up how we are going to handle all of this.)
> 
> My suggestion would be one of two alternatives:
> 
> 1) At each release, Linus clones
> 	linux.bkbits.net/linux-2.6
> 		to
> 	linux.bkbits.net/linux-2.6.11
> 
> and gives the "release team" access to push to linux-2.6.11 repo.

My recollection of the bkbits interface is that it's keys are good for a
"project" dir.  So I don't know if it would work like you suggested.

> 2) Create linux-release.bkbits.net, and some non-Linus person clones 
> linux-2.6 at release time to linux-2.6.11.

This is closer to what I suggested to Greg (although I like your name
better).

> This accomplishes two [minor] goals:
> a) the tree lives at bkbits.net, as has a name associated with the goal 
> of the project
> 
> b) The repo has the _exact_ name of the kernel release.  None of this 
> "linux-2.6.11.y" stuff.  Just "linux-2.6.11".  Anything else violates 
> the Principle of Least Surprise.
> 
> 
> >Feel free to start pointing stuff like this at me and chris (we'll also
> >be setting up an alias for it.)
> 
> I was wondering if it would be possible to setup a list on vger that is 
> public, but read-only to everyone but the $sucker team.

Don't see why not, we were thinking of making it just an alias at
kernel.org.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
> * Jeff Garzik (jgarzik@pobox.com) wrote:
> > Greg KH wrote:
> > 
> > Two procedural suggestions...
> > 
> > >Ok, I've fixed up the patch and applied it to a local tree that I've set
> > >up to catch these things (it will live at
> > >bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
> > >set up how we are going to handle all of this.)
> > 
> > My suggestion would be one of two alternatives:
> > 
> > 1) At each release, Linus clones
> > 	linux.bkbits.net/linux-2.6
> > 		to
> > 	linux.bkbits.net/linux-2.6.11
> > 
> > and gives the "release team" access to push to linux-2.6.11 repo.
> 
> My recollection of the bkbits interface is that it's keys are good for a
> "project" dir.  So I don't know if it would work like you suggested.
> 
> > 2) Create linux-release.bkbits.net, and some non-Linus person clones 
> > linux-2.6 at release time to linux-2.6.11.
> 
> This is closer to what I suggested to Greg (although I like your name
> better).

I like this too, less work for Linus to do this.

Ok, linux-release.bkbits.net is now created.

> > >Feel free to start pointing stuff like this at me and chris (we'll also
> > >be setting up an alias for it.)
> > 
> > I was wondering if it would be possible to setup a list on vger that is 
> > public, but read-only to everyone but the $sucker team.

So, the $sucker team can't read it, but the rest of the world could?  :)

> Don't see why not, we were thinking of making it just an alias at
> kernel.org.

An alias would probably be easier, unless you think everything sent
there should be archived?

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Greg KH wrote:
> On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
>>Don't see why not, we were thinking of making it just an alias at
>>kernel.org.
> 
> 
> An alias would probably be easier, unless you think everything sent
> there should be archived?


I do.  But I don't have a strong opinion on the subject.

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Paul Mackerras]

Jeff Garzik writes:
> Rene Rebe wrote:
> > Hi,
> > 
> > 
> > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
> > 16:44:56.407107752 +0100
> > +++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
> > 16:45:22.424152560 +0100
> > @@ -108,7 +108,7 @@
> >  int raid6_have_altivec(void)
> >  {
> >      /* This assumes either all CPUs have Altivec or none does */
> > -    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> > +    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
> 
> 
> I nominate this as a candidate for linux-2.6.11 release branch.  :)

No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
between ppc and ppc64. :)

Paul.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> Jeff Garzik writes:
> > Rene Rebe wrote:
> > > Hi,
> > > 
> > > 
> > > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
> > > 16:44:56.407107752 +0100
> > > +++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
> > > 16:45:22.424152560 +0100
> > > @@ -108,7 +108,7 @@
> > >  int raid6_have_altivec(void)
> > >  {
> > >      /* This assumes either all CPUs have Altivec or none does */
> > > -    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> > > +    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
> > 
> > 
> > I nominate this as a candidate for linux-2.6.11 release branch.  :)
> 
> No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
> versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
> between ppc and ppc64. :)

Fine, dueling arches, who wins?  :)

So, what do I do, just ignore the patch?  Or do you have a fix?

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Olof Johansson]

On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > I nominate this as a candidate for linux-2.6.11 release branch.  :)
> 
> No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
> versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
> between ppc and ppc64. :)

The proper fix is to get the cpu_has_feature patch merged up from -mm,
but that's 99% cleanup and 1% bugfix. So here's a more appropriate fix
for the 2.6.11 patch stream. This goes on top of the one that just got
merged there.


-Olof


---


Here's a patch that will work for both PPC and PPC64. The proper way to
fix this in mainline is to merge -mm's cpu_has_feature patch, but for
the stable 2.6.11-series, this much less intrusive (i.e. just the pure
bugfix, not the cleanup part).

Signed-off-by: Olof Johansson <olof@austin.ibm.com>


Index: linux-2.5/drivers/md/raid6altivec.uc
===================================================================
--- linux-2.5.orig/drivers/md/raid6altivec.uc	2005-03-03 16:46:47.000000000 -0600
+++ linux-2.5/drivers/md/raid6altivec.uc	2005-03-03 16:48:03.000000000 -0600
@@ -108,7 +108,11 @@ int raid6_have_altivec(void);
 int raid6_have_altivec(void)
 {
 	/* This assumes either all CPUs have Altivec or none does */
+#ifdef CONFIG_PPC64
+	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#else
 	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#endif
 }
 #endif
 

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Dave Jones]

On Thu, Mar 03, 2005 at 02:45:15PM -0800, Greg KH wrote:
 > On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
 > > Jeff Garzik writes:
 > > > Rene Rebe wrote:
 > > > > Hi,
 > > > > 
 > > > > 
 > > > > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla    2005-03-02 
 > > > > 16:44:56.407107752 +0100
 > > > > +++ linux-2.6.11/drivers/md/raid6altivec.uc    2005-03-02 
 > > > > 16:45:22.424152560 +0100
 > > > > @@ -108,7 +108,7 @@
 > > > >  int raid6_have_altivec(void)
 > > > >  {
 > > > >      /* This assumes either all CPUs have Altivec or none does */
 > > > > -    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
 > > > > +    return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
 > > > 
 > > > 
 > > > I nominate this as a candidate for linux-2.6.11 release branch.  :)
 > > 
 > > No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
 > > versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
 > > between ppc and ppc64. :)
 > 
 > Fine, dueling arches, who wins?  :)
 > 
 > So, what do I do, just ignore the patch?  Or do you have a fix?

until its fixed properly, how about this ?

+#ifdef CONFIG_PPC64
     return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#else
+    return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#endif


Brings about an interesting conundrum with teh 2.6.x.y branch.
If fixing something properly is invasive, would we want to allow
band-aids to get things working ? This would make things more difficult
wrt Linus being able to pull the previous .y branch into his current
tree, but bitkeepers conflict resolution is really unsurpassed for
such situations in my experience.

		Dave

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Thu, Mar 03, 2005 at 04:55:42PM -0600, Olof Johansson wrote:
> On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > > I nominate this as a candidate for linux-2.6.11 release branch.  :)
> > 
> > No.  Unfortunately if you fix ppc64 here you will break ppc, and vice
> > versa.  Yes, we are going to reconcile the cur_cpu_spec definitions
> > between ppc and ppc64. :)
> 
> The proper fix is to get the cpu_has_feature patch merged up from -mm,
> but that's 99% cleanup and 1% bugfix. So here's a more appropriate fix
> for the 2.6.11 patch stream. This goes on top of the one that just got
> merged there.

Applied, thanks.

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

olof@austin.ibm.com (Olof Johansson) wrote:
>
> Here's a patch that will work for both PPC and PPC64. The proper way to
>  fix this in mainline is to merge -mm's cpu_has_feature patch, but for
>  the stable 2.6.11-series, this much less intrusive (i.e. just the pure
>  bugfix, not the cleanup part).
> 
>  Signed-off-by: Olof Johansson <olof@austin.ibm.com>
> 
> 
>  Index: linux-2.5/drivers/md/raid6altivec.uc
>  ===================================================================
>  --- linux-2.5.orig/drivers/md/raid6altivec.uc	2005-03-03 16:46:47.000000000 -0600
>  +++ linux-2.5/drivers/md/raid6altivec.uc	2005-03-03 16:48:03.000000000 -0600
>  @@ -108,7 +108,11 @@ int raid6_have_altivec(void);
>   int raid6_have_altivec(void)
>   {
>   	/* This assumes either all CPUs have Altivec or none does */
>  +#ifdef CONFIG_PPC64
>  +	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
>  +#else
>   	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
>  +#endif
>   }
>   #endif

This patch doesn't seem right - current 2.6.11 has:

        return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;

So anyway, I fixed it up as:

--- 25/drivers/md/raid6altivec.uc~ppc-raid6-altivec-build-fix	2005-03-03 17:56:21.000000000 -0800
+++ 25-akpm/drivers/md/raid6altivec.uc	2005-03-03 17:57:50.000000000 -0800
@@ -108,7 +108,11 @@ int raid6_have_altivec(void);
 int raid6_have_altivec(void)
 {
 	/* This assumes either all CPUs have Altivec or none does */
+#ifdef CONFIG_PPC64
 	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#else
+	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#endif
 }
 #endif
 
_


I'll assume that the above is suitable as a temp thing and I'll fix up
ppc-ppc64-abstract-cpu_feature-checks.patch

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Olof Johansson]

Hi,

On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> This patch doesn't seem right - current 2.6.11 has:
> 
>         return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;

The patch was against what Greg had already pushed into the
linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
You're right, your revised patch would apply against mainline.

However: This patch shouldn't go to mainline, since
ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
the problem. I'd like the abstraction/cleanup patch to be merged upstream
instead of the #ifdef hack once the tree opens up.


Thanks,

-Olof

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Chris Wright]

* Olof Johansson (olof@austin.ibm.com) wrote:
> Hi,
> 
> On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> > This patch doesn't seem right - current 2.6.11 has:
> > 
> >         return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> 
> The patch was against what Greg had already pushed into the
> linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
> You're right, your revised patch would apply against mainline.
> 
> However: This patch shouldn't go to mainline, since
> ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
> the problem. I'd like the abstraction/cleanup patch to be merged upstream
> instead of the #ifdef hack once the tree opens up.

Olof's patch is in the linux-release tree, so this brings up a point
regarding merging.  If the quick fix is to be replaced by a better fix
later (as in this case) there's some room for merge conflict.  Does this
pose a problem for either -mm or Linus' tree?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Chris Wright wrote:
> * Olof Johansson (olof@austin.ibm.com) wrote:
> 
>>Hi,
>>
>>On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
>>
>>>This patch doesn't seem right - current 2.6.11 has:
>>>
>>>        return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
>>
>>The patch was against what Greg had already pushed into the
>>linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
>>You're right, your revised patch would apply against mainline.
>>
>>However: This patch shouldn't go to mainline, since
>>ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
>>the problem. I'd like the abstraction/cleanup patch to be merged upstream
>>instead of the #ifdef hack once the tree opens up.
> 
> 
> Olof's patch is in the linux-release tree, so this brings up a point
> regarding merging.  If the quick fix is to be replaced by a better fix
> later (as in this case) there's some room for merge conflict.  Does this
> pose a problem for either -mm or Linus' tree?

Just need to make sure <whomever> aware of this, when you push to Linus.

In most cases, of dire fixes, they should just go into linux-release, 
and then get pulled into linux-2.6.

For a few cases, like this one, the quick fix will hit linux-release and 
linux-2.6 before the better fix, so no big deal.

In a few rare cases, you will need to create a "for-upstream" tree that 
handles the conflict before it get pushed to Linus.

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Chris Wright <chrisw@osdl.org> wrote:
>
> * Olof Johansson (olof@austin.ibm.com) wrote:
> > Hi,
> > 
> > On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> > > This patch doesn't seem right - current 2.6.11 has:
> > > 
> > >         return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> > 
> > The patch was against what Greg had already pushed into the
> > linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
> > You're right, your revised patch would apply against mainline.
> > 
> > However: This patch shouldn't go to mainline, since
> > ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
> > the problem. I'd like the abstraction/cleanup patch to be merged upstream
> > instead of the #ifdef hack once the tree opens up.
> 
> Olof's patch is in the linux-release tree, so this brings up a point
> regarding merging.  If the quick fix is to be replaced by a better fix
> later (as in this case) there's some room for merge conflict.  Does this
> pose a problem for either -mm or Linus' tree?

It depends who gets to Linus's tree first.  If linux-release merges first,
I just revert the temp fix while adding the real fix.  But the temp fix
should never have gone into Linus's tree in the first place.

If I merge before linux-release, I guess Linus has some conflict resolving
to do when he pulls from linux-release.  That's OK for an obvious
two-liner, but would get out of control for more substantial things.

Neither solution is acceptable, really.  I suspect the idea of pulling
linux-release into mainline won't work very well, and that making it a
backport tree would be more practical.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Andrew Morton wrote:
> Chris Wright <chrisw@osdl.org> wrote:
> 
>>* Olof Johansson (olof@austin.ibm.com) wrote:
>>
>>>Hi,
>>>
>>>On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
>>>
>>>>This patch doesn't seem right - current 2.6.11 has:
>>>>
>>>>        return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
>>>
>>>The patch was against what Greg had already pushed into the
>>>linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline.
>>>You're right, your revised patch would apply against mainline.
>>>
>>>However: This patch shouldn't go to mainline, since
>>>ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of
>>>the problem. I'd like the abstraction/cleanup patch to be merged upstream
>>>instead of the #ifdef hack once the tree opens up.
>>
>>Olof's patch is in the linux-release tree, so this brings up a point
>>regarding merging.  If the quick fix is to be replaced by a better fix
>>later (as in this case) there's some room for merge conflict.  Does this
>>pose a problem for either -mm or Linus' tree?
> 
> 
> It depends who gets to Linus's tree first.  If linux-release merges first,
> I just revert the temp fix while adding the real fix.  But the temp fix
> should never have gone into Linus's tree in the first place.
> 
> If I merge before linux-release, I guess Linus has some conflict resolving
> to do when he pulls from linux-release.  That's OK for an obvious
> two-liner, but would get out of control for more substantial things.
> 
> Neither solution is acceptable, really.  I suspect the idea of pulling
> linux-release into mainline won't work very well, and that making it a
> backport tree would be more practical.

Maybe you're right, but I tend to think that "quick, get that fix out 
immediately" fixes will appear before more substantial fixes.  That is 
certainly the way things have worked up until now.

For the cases that we care about, putting that into linux-release and 
then pulling would seem more appropriate.

Remember, the linux-release tree for each release will slow down, and 
eventually die off, as we progress towards the next release (where the 
linux-2.6.x.y-1 tree will indeed die).

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> > Olof's patch is in the linux-release tree, so this brings up a point
>  > regarding merging.  If the quick fix is to be replaced by a better fix
>  > later (as in this case) there's some room for merge conflict.  Does this
>  > pose a problem for either -mm or Linus' tree?
> 
>  Just need to make sure <whomever> aware of this, when you push to Linus.
> 
>  In most cases, of dire fixes, they should just go into linux-release, 
>  and then get pulled into linux-2.6.
> 
>  For a few cases, like this one, the quick fix will hit linux-release and 
>  linux-2.6 before the better fix, so no big deal.
> 
>  In a few rare cases, you will need to create a "for-upstream" tree that 
>  handles the conflict before it get pushed to Linus.

As I say, it sounds dumb, but I'm sure you can make it work ;)

The main person it affects is yours truly:

bix:/usr/src/25> grep fix series | wc -l 
    162

And fixes which are 2.6.x.y material need to go mm->linux_release->linus. 
I drop them when they turn up in Linus's tree.

That works as long as I don't have non-linux_release patches which depend
upon earlier fixes.  If that happens I have to wait until linux-release
merges up.

Again, it's manageable, but complex.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> > Neither solution is acceptable, really.  I suspect the idea of pulling
>  > linux-release into mainline won't work very well, and that making it a
>  > backport tree would be more practical.
> 
>  Maybe you're right, but I tend to think that "quick, get that fix out 
>  immediately" fixes will appear before more substantial fixes.  That is 
>  certainly the way things have worked up until now.
> 
>  For the cases that we care about, putting that into linux-release and 
>  then pulling would seem more appropriate.
> 
>  Remember, the linux-release tree for each release will slow down, and 
>  eventually die off, as we progress towards the next release (where the 
>  linux-2.6.x.y-1 tree will indeed die).

Yup.  But anyway, there's no point in overdesigning all this.  Let's suck
it and see.  If it doesn't work we can populate linux-release by some other
means.  The downstream users of linux-release won't see any change as a
result of that.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Chris Wright]

* Jeff Garzik (jgarzik@pobox.com) wrote:
> Andrew Morton wrote:
> >Chris Wright <chrisw@osdl.org> wrote:
> >>Olof's patch is in the linux-release tree, so this brings up a point
> >>regarding merging.  If the quick fix is to be replaced by a better fix
> >>later (as in this case) there's some room for merge conflict.  Does this
> >>pose a problem for either -mm or Linus' tree?
> >
> >It depends who gets to Linus's tree first.  If linux-release merges first,
> >I just revert the temp fix while adding the real fix.  But the temp fix
> >should never have gone into Linus's tree in the first place.

Consider it first patch in fixup series ;-)

> >If I merge before linux-release, I guess Linus has some conflict resolving
> >to do when he pulls from linux-release.  That's OK for an obvious
> >two-liner, but would get out of control for more substantial things.
> >
> >Neither solution is acceptable, really.  I suspect the idea of pulling
> >linux-release into mainline won't work very well, and that making it a
> >backport tree would be more practical.
> 
> Maybe you're right, but I tend to think that "quick, get that fix out 
> immediately" fixes will appear before more substantial fixes.  That is 
> certainly the way things have worked up until now.
> 
> For the cases that we care about, putting that into linux-release and 
> then pulling would seem more appropriate.

Yes, and this case was on the border of a newly existing system.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Chris Wright <chrisw@osdl.org> wrote:
>
>  * Jeff Garzik (jgarzik@pobox.com) wrote:
>  > Andrew Morton wrote:
>  > >Chris Wright <chrisw@osdl.org> wrote:
>  > >>Olof's patch is in the linux-release tree, so this brings up a point
>  > >>regarding merging.  If the quick fix is to be replaced by a better fix
>  > >>later (as in this case) there's some room for merge conflict.  Does this
>  > >>pose a problem for either -mm or Linus' tree?
>  > >
>  > >It depends who gets to Linus's tree first.  If linux-release merges first,
>  > >I just revert the temp fix while adding the real fix.  But the temp fix
>  > >should never have gone into Linus's tree in the first place.
> 
>  Consider it first patch in fixup series ;-)

Here's the second, and this is much more critical.

And it's untested.

And it's a temp-fix - it'll be addressed by other means in 2.6.12.

What do we do?



From: Dmitry Torokhov <dtor_core@ameritech.net>

Some ACPI-related changes were recently made to i8042 discovery for ia64. 
Unfortunately this broke a significant number of Dell laptops due to their
having incorrect BIOS tables.

So, for now, arrange for the new code to be ia64-only.

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/drivers/input/serio/i8042-x86ia64io.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff -puN drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround drivers/input/serio/i8042-x86ia64io.h
--- 25/drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround	2005-03-03 13:34:49.000000000 -0800
+++ 25-akpm/drivers/input/serio/i8042-x86ia64io.h	2005-03-03 13:34:49.000000000 -0800
@@ -88,7 +88,7 @@ static struct dmi_system_id __initdata i
 };
 #endif
 
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 #include <linux/acpi.h>
 #include <acpi/acpi_bus.h>
 
@@ -281,7 +281,7 @@ static inline int i8042_platform_init(vo
 	i8042_kbd_irq = I8042_MAP_IRQ(1);
 	i8042_aux_irq = I8042_MAP_IRQ(12);
 
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 	if (i8042_acpi_init())
 		return -1;
 #endif
@@ -300,7 +300,7 @@ static inline int i8042_platform_init(vo
 
 static inline void i8042_platform_exit(void)
 {
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 	i8042_acpi_exit();
 #endif
 }
_

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Andrew Morton wrote:
> That works as long as I don't have non-linux_release patches which depend
> upon earlier fixes.  If that happens I have to wait until linux-release
> merges up.

Hopefully linux-release pulls, and linux-release releases, will happen 
fairly quickly.  Otherwise its value diminishes.

Release early, release often </chant>

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Chris Wright]

* Andrew Morton (akpm@osdl.org) wrote:
> Chris Wright <chrisw@osdl.org> wrote:
> >
> >  * Jeff Garzik (jgarzik@pobox.com) wrote:
> >  > Andrew Morton wrote:
> >  > >Chris Wright <chrisw@osdl.org> wrote:
> >  > >>Olof's patch is in the linux-release tree, so this brings up a point
> >  > >>regarding merging.  If the quick fix is to be replaced by a better fix
> >  > >>later (as in this case) there's some room for merge conflict.  Does this
> >  > >>pose a problem for either -mm or Linus' tree?
> >  > >
> >  > >It depends who gets to Linus's tree first.  If linux-release merges first,
> >  > >I just revert the temp fix while adding the real fix.  But the temp fix
> >  > >should never have gone into Linus's tree in the first place.
> > 
> >  Consider it first patch in fixup series ;-)

Actually I meant fix 1/2 == quick, fix 2/2 == more complete.

> Here's the second, and this is much more critical.
> 
> And it's untested.

I'd rather it be tested.../me keeps wishing
If it's untested, are we even sure it fixes the problem?  Or are you
worried about the umpteen other non-Dell laptops that could have
problems with the patch?

> And it's a temp-fix - it'll be addressed by other means in 2.6.12.
> 
> What do we do?

IMO, we have to rely on Dmitry's judgement.  Is it critical (i.e. broke
laptops how)?  Can it be worked around with the i8042.noacpi boot param?
If so, I don't think it fits the bill as critical.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Chris Wright <chrisw@osdl.org> wrote:
>
> > And it's a temp-fix - it'll be addressed by other means in 2.6.12.
>  > 
>  > What do we do?
> 
>  IMO, we have to rely on Dmitry's judgement.  Is it critical (i.e. broke
>  laptops how)?  Can it be worked around with the i8042.noacpi boot param?
>  If so, I don't think it fits the bill as critical.

Well.  It was critical for 2.6.11, but it didn't make it :(

So people whose keyboards don't work need to either update to 2.6.11.1 or
add i8042.noacpi=1.  <rekicks self>

But it's just a for-instance.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Chris Wright]

* Andrew Morton (akpm@osdl.org) wrote:
> Chris Wright <chrisw@osdl.org> wrote:
> >
> > > And it's a temp-fix - it'll be addressed by other means in 2.6.12.
> >  > 
> >  > What do we do?
> > 
> >  IMO, we have to rely on Dmitry's judgement.  Is it critical (i.e. broke
> >  laptops how)?  Can it be worked around with the i8042.noacpi boot param?
> >  If so, I don't think it fits the bill as critical.
> 
> Well.  It was critical for 2.6.11, but it didn't make it :(

Ah, I see.

> So people whose keyboards don't work need to either update to 2.6.11.1 or
> add i8042.noacpi=1.  <rekicks self>
> 
> But it's just a for-instance.

And a good one to exercise the rules measuring how critical the patch
is.  In this case, I don't think it is if workaround is good enough, but 
could be convinced if Dmitry thinks otherwise.

Anyway, time to pack, sleep a few and catch a plane back west
later,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Chris Wright wrote:
> IMO, we have to rely on Dmitry's judgement.  Is it critical (i.e. broke
> laptops how)?  Can it be worked around with the i8042.noacpi boot param?
> If so, I don't think it fits the bill as critical.

If it was critical for 2.6.11, I would think it's critical for 2.6.11.1.

One would hope its at least tested on one affected laptop.

The boot param is rather lame, IMO, since it affects a -bunch- of 
laptops.  But whatever...

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> The boot param is rather lame, IMO, since it affects a -bunch- of 
>  laptops.  But whatever...

My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1
(sic.  It got renamed) so I can type stuff too.  (rerekicks self). I expect
this machine would require i8042.noacpi=1 if it was running 2.6.11.

Lots of machines are affected.  It's a bit of a howler.

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Jeff Garzik]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>The boot param is rather lame, IMO, since it affects a -bunch- of 
>> laptops.  But whatever...
> 
> 
> My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1
> (sic.  It got renamed) so I can type stuff too.  (rerekicks self). I expect
> this machine would require i8042.noacpi=1 if it was running 2.6.11.
> 
> Lots of machines are affected.  It's a bit of a howler.

Definitely a linux-release candidate then.

On a side note, it would be nice to give you access to push things into 
the linux-release tree yourself.

	Jeff

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Francois Romieu]

Jeff Garzik <jgarzik@pobox.com> :
> Greg KH wrote:
[...]
> >An alias would probably be easier, unless you think everything sent
> >there should be archived?
> 
> I do.  But I don't have a strong opinion on the subject.

A bk-commit mailing-list would be nice.

--
Ueimor

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Thu, Mar 03, 2005 at 10:23:35PM -0800, Andrew Morton wrote:
> From: Dmitry Torokhov <dtor_core@ameritech.net>
> 
> Some ACPI-related changes were recently made to i8042 discovery for ia64. 
> Unfortunately this broke a significant number of Dell laptops due to their
> having incorrect BIOS tables.
> 
> So, for now, arrange for the new code to be ia64-only.
> 
> Signed-off-by: Andrew Morton <akpm@osdl.org>

Ok, based on consensus, I've applied this one too.

Yes, we will get a bk-stable-commits tree up and running, still working
out the infrastructure...

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Linus Torvalds]

On Fri, 4 Mar 2005, Greg KH wrote:
> 
> Ok, based on consensus, I've applied this one too.

Btw, I don't think your process works. You never really gave people the
time to object. So for that reason you applied the first trivial raid6
thing, and it turned out to be wrong.

I think the patches need to have a rule like "they live outside the sucker 
tree for at least two days". And during that time, anybody can vote them 
down (which would move them to "unapplied" status, at which point somebody 
else might decide that for _their_ tree it's still the right thing to do).

And if at the end of two days, they still haven't gotten enough "yes"  
votes, they'd go into "limbo" status, with one extra grace-period (ie a
reminder on whatever list about a patch that is dying). And if it can't 
get enough "yeah, sure" votes even after that, it goes into the same 
"unapplied" list.

In other words, I think this really does want some automation. It
shouldn't be fully automated (at the very least, somebody needs to
actually check that things patch and fix up the changeset comments etc),
but the _rules_ should be automated. Otherwise they'll always be broken
because of "_this_ time it's obvious", which is against the point.

		Linus

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Greg KH]

On Fri, Mar 04, 2005 at 10:38:10AM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 4 Mar 2005, Greg KH wrote:
> > 
> > Ok, based on consensus, I've applied this one too.
> 
> Btw, I don't think your process works. You never really gave people the
> time to object. So for that reason you applied the first trivial raid6
> thing, and it turned out to be wrong.

I agree.

> I think the patches need to have a rule like "they live outside the sucker 
> tree for at least two days". And during that time, anybody can vote them 
> down (which would move them to "unapplied" status, at which point somebody 
> else might decide that for _their_ tree it's still the right thing to do).
> 
> And if at the end of two days, they still haven't gotten enough "yes"  
> votes, they'd go into "limbo" status, with one extra grace-period (ie a
> reminder on whatever list about a patch that is dying). And if it can't 
> get enough "yeah, sure" votes even after that, it goes into the same 
> "unapplied" list.
> 
> In other words, I think this really does want some automation. It
> shouldn't be fully automated (at the very least, somebody needs to
> actually check that things patch and fix up the changeset comments etc),
> but the _rules_ should be automated. Otherwise they'll always be broken
> because of "_this_ time it's obvious", which is against the point.

Ok, Chris and I are going to sit down and work this all out on Tuesday.
I'll hold off on applying or releasing anything else until we fully
describe the process, and set up the infrastructure.

I'll slow down now :)

thanks,

greg k-h

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Alan Cox]

On Gwe, 2005-03-04 at 16:27, Greg KH wrote:
> Ok, based on consensus, I've applied this one too.
> 
> Yes, we will get a bk-stable-commits tree up and running, still working
> out the infrastructure...

Cool. Once you've done so make sure there are also no bk snapshots and
I'll push you some of the tiny but critical fixes (security, non working
ULI tulip etc) from 11-ac1 when I upload it.

Alan

Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

[Alan Cox]

On Sul, 2005-03-06 at 23:06, Alan Cox wrote:
> Cool. Once you've done so make sure there are also no bk snapshots and

That should have read "non bk" snapshots before Larry goes boom 8)