From: Olof Johansson <hidden> Date: 2005-11-09 07:23:22
Hi,
This should be ready to go in now; we'll have to do with basic
enablement for now -- touchpad driver can come later.
Thanks,
Olof
---
Enablement patch for the new PowerBooks (late 2005 edition).
This enables the ATA controller, Gigabit ethernet and basic AGP setup.
Bluetooth works out-of-the box after running hid2hci.
Still remaining is to get the touchpad to work, the simple change of
just adding the new USB ids isn't enough.
Signed-off-by: Olof Johansson <redacted>
Index: linux-2.6/arch/ppc/platforms/pmac_feature.c
===================================================================
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-11-09 09:02:32
Enablement patch for the new PowerBooks (late 2005 edition).
This enables the ATA controller, Gigabit ethernet and basic AGP setup.
Bluetooth works out-of-the box after running hid2hci.
Still remaining is to get the touchpad to work, the simple change of
just adding the new USB ids isn't enough.
Signed-off-by: Olof Johansson <redacted>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
From: Andrew Morton <hidden> Date: 2005-11-10 05:38:53
Benjamin Herrenschmidt [off-list ref] wrote:
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-11-10 05:42:30
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
Well, I'm personally no fan of the git route as it causes us to have
less review on the list imho (too easy also for me to just bounce a
patch to paulus to shove in his git tree :) though that's what I've been
doing for the last few days at least. But if you prefer that way, yes,
it's certainly possible.
Ben.
From: Andrew Morton <hidden> Date: 2005-11-10 06:00:39
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
Well, I'm personally no fan of the git route as it causes us to have
less review on the list imho
Well yes, that's a generic problem with subsystem trees. I suppose one
could enforce processes which prevent it from happening.
(too easy also for me to just bounce a
patch to paulus to shove in his git tree :) though that's what I've been
doing for the last few days at least. But if you prefer that way, yes,
it's certainly possible.
OK, well please think about it. It's not a ton of work at this end at
present, but a) you lazy bums don't ack most of the things I cc you on, so
it's rather open-loop and I don't know whether I'm merging wrong patches
and b) there's now increasing potential for patches in -mm to clash with
patches in Paul's git tree.
The latter can be solved easily enough: I add Paul's git tree to the -mm
lineup. Gimme.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-11-10 06:08:42
Well yes, that's a generic problem with subsystem trees. I suppose one
could enforce processes which prevent it from happening.
I think the right process is to go through the linuxppc[64]-dev list(s)
first, maybe CC lkml when it's not strictly arch gore, and then hop from
there to -git. We also have a nice patch tracking system scanning those
lists, I suppose I need to fix my own habits of bypassing all of that
stuff :)
OK, well please think about it. It's not a ton of work at this end at
present, but a) you lazy bums don't ack most of the things I cc you on, so
it's rather open-loop and I don't know whether I'm merging wrong patches
and b) there's now increasing potential for patches in -mm to clash with
patches in Paul's git tree.
The latter can be solved easily enough: I add Paul's git tree to the -mm
lineup.
I think going through the -git tree always makes sense and I've doing
doing that for my own production, I'll route patches that I'm acking
that way too from now on.
I'm keeping the liberty of bombing you & linus directly when I think
it's an important bug fix late in the rc cycle though :)
Ben.
From: Paul Mackerras <hidden> Date: 2005-11-10 06:08:42
Andrew Morton writes:
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
My powerpc-merge.git tree is sort-of de-facto that at the moment.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
Yes. Good idea, in fact. I'll create a powerpc.git tree once the
current merge window closes.
Do I need to grep the -mm releases for ppc patches or will you mail
them to me?
Regards,
Paul.
From: Andrew Morton <hidden> Date: 2005-11-10 06:30:02
Paul Mackerras [off-list ref] wrote:
quoted
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
Yes. Good idea, in fact. I'll create a powerpc.git tree once the
current merge window closes.
OK.
Do I need to grep the -mm releases for ppc patches or will you mail
them to me?
If I see a ppc patch I will:
- merge it into -mm, add you guys to the cc on the mm-commits email.
- stage the patch after git-powerpc.patch in the -mm lineup.
- if I see the patch appear in git-powerpc.patch, I just drop it. I sync
with the git trees maybe twice per day.
- time passes
- if it still hasn't been merged into git-powerpc, I start spamming you
with the patch.
So no, you don't need to grep -mm and I won't bypass the git-powerpc tree
and the patch won't get lost. All you need to do is to either merge or
nack the patch at some stage.
Easy as pie ;)
From: Olof Johansson <hidden> Date: 2005-11-10 16:44:39
On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).
If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.
Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)
Thanks,
-Olof
From: Kumar Gala <hidden> Date: 2005-11-10 18:02:26
On Nov 10, 2005, at 10:44 AM, Olof Johansson wrote:
On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
quoted
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.
quoted
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).
If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.
Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)
I agree with Olof's comments. Additionally, I think one reason we had been sending things to Andrew for PPC32 embedded was that the sub-arch maintainers (Matt, Marcelo, Tom, Dan, Sylvain, myself, etc..) needed a responsive path to get things to Linus which Andrew was providing. If Paul's going to be able to handle accepting and dealing with all the embedded patches I'm fine with having a PPC git tree. I'm even willing to setup some GIT tree's for sub-arch's I deal with for Paul to pull from if he wants.
Just my two cents.
- kumar