Updates to powerpc.git

Updates to powerpc.git

[Benjamin Herrenschmidt]

I've pushed some updates to my version of powerpc.git.

The tree itself is at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git

It contains 3 branches:

  - merge  : this is for merging with the current stable and doesn't
             currently contain anything interesting

  - master : this is our current "powerpc.git" tree, it may contain
             various experimental stuff that may or may not go upstream
             or may contain dependent patches that we rely on but that
             are to be merged via some other tree.

  - next   : this is the candidate stuff for linux-next and the next
             merge window

(Andrew, you -may- want to pull that instead of paulus one until
he's back from vacation).

Until today, master and next pointed to the same commit, which was
the same as paulus master and powerpc-next branches. Tonight, I've
pushed some patches to master that I intend to have in next, but
I'd like to let them sit in master for a couple of days to make sure
nothing is badly broken mostly and make sure I didn't screw up in
my various patch monkeying operations.

Here are the newly applied patches:

Benjamin Herrenschmidt (1):
      powerpc: Use new printk extension %pS to print symbols on oops

Dave Kleikamp (5):
      mm: Allow architectures to define additional protection bits
      powerpc/mm: Define flags for Strong Access Ordering
      powerpc/mm: Add SAO Feature bit to the cputable
      powerpc/mm: Add Strong Access Ordering support
      powerpc/mm: Don't clear _PAGE_COHERENT when _PAGE_SAO is set

Geoff Levand (1):
      powerpc/ps3: Quiet system bus match output

Grant Erickson (1):
      ibm_newemac: Parameterize EMAC Multicast Match Handling

Jeremy Kerr (4):
      powerpc/spufs: avoid magic numbers for mapping sizes
      powerpc/spufs: allow spufs files to specify sizes
      powerpc/spufs: add sizes for context files
      powerpc/spufs: only add ".ctx" file with "debug" mount option

Luke Browning (2):
      powerpc/spufs: provide context debug file
      powerpc/spufs: don't extend time time slice if context is not in spu_run

Mark Nelson (4):
      powerpc/dma: Add struct iommu_table argument to iommu_map_sg()
      powerpc/dma: implement new dma_*map*_attrs() interfaces
      powerpc/cell: cell_dma_dev_setup_iommu() return the iommu table
      powerpc: move device_to_mask() to dma-mapping.h

Maxim Shchetynin (1):
      powerpc/spufs: add atomic busy_spus counter to struct cbe_spu_info

Michael Neuling (2):
      powerpc: fix swapcontext backwards compat. with VSX ucontext changes
      powerpc: remove unused variable in emulate_fp_pair

Mike Mason (1):
      powerpc/eeh: PERR/SERR bit settings during EEH device recovery

Paul Gortmaker (1):
      powerpc/ibmebus: more meaningful variable name

Srinivasa Ds (1):
      powerpc: Implement task_pt_regs() accessor

Re: Updates to powerpc.git

[Kumar Gala]

On Jul 9, 2008, at 2:34 AM, Benjamin Herrenschmidt wrote:

> I've pushed some updates to my version of powerpc.git.
>
> The tree itself is at:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>
> It contains 3 branches:
>
>  - merge  : this is for merging with the current stable and doesn't
>             currently contain anything interesting
>
>  - master : this is our current "powerpc.git" tree, it may contain
>             various experimental stuff that may or may not go upstream
>             or may contain dependent patches that we rely on but that
>             are to be merged via some other tree.
>
>  - next   : this is the candidate stuff for linux-next and the next
>             merge window
>
> (Andrew, you -may- want to pull that instead of paulus one until
> he's back from vacation).
>
> Until today, master and next pointed to the same commit, which was
> the same as paulus master and powerpc-next branches. Tonight, I've
> pushed some patches to master that I intend to have in next, but
> I'd like to let them sit in master for a couple of days to make sure
> nothing is badly broken mostly and make sure I didn't screw up in
> my various patch monkeying operations.

What is your intent with the 'master' branch?  I hope you do NOT plan  
on ever rebasing it.  I assume if a patch gets into master and we drop  
it you'll do a git-revert of it?

- k

Re: Updates to powerpc.git

[Josh Boyer]

On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> I've pushed some updates to my version of powerpc.git.
>=20
> The tree itself is at:
>=20
> =EF=BB=BF  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>=20
> It contains 3 branches:
>=20
>   - merge  : this is for merging with the current stable and doesn't
>              currently contain anything interesting
>=20
>   - master : this is our current "powerpc.git" tree, it may contain
>              various experimental stuff that may or may not go upstream
>              or may contain dependent patches that we rely on but that
>              are to be merged via some other tree.
>=20
>   - next   : this is the candidate stuff for linux-next and the next
>              merge window
>=20
> (Andrew, you -may- want to pull that instead of paulus one until
> he's back from vacation).
>=20
> Until today, master and next pointed to the same commit, which was
> the same as paulus master and powerpc-next branches. Tonight, I've
> pushed some patches to master that I intend to have in next, but
> I'd like to let them sit in master for a couple of days to make sure
> nothing is badly broken mostly and make sure I didn't screw up in
> my various patch monkeying operations.

One thing to point out is that if you decide to only select a few of
those patches, you'll need to cherry-pick them into your next branch
(or rebase). That means that when you pull from Linus into your master
branch during/after the merge window, you'll get all kinds of funny
merge commits.

If you want to use your master branch as a place for experimental
stuff, that's fine by me.  But you'll want to keep next separate from
it so it's as "clean" as possible for those trying to track what is
definitely going into the next release.

If it were up to me (which it's not), I would have master just track
Linus, next track what's going into the next release, and "bleeding" or
"experimental" track stuff that isn't fully vetted yet.  I might start
doing that with my tree in the very near future.

Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same.  It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree.  I humbly beg you to keep that going.

josh

Re: Updates to powerpc.git

[Kumar Gala]

On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:

> On Wed, 09 Jul 2008 17:34:41 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> I've pushed some updates to my version of powerpc.git.
>>
>> The tree itself is at:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>>
>> It contains 3 branches:
>>
>>  - merge  : this is for merging with the current stable and doesn't
>>             currently contain anything interesting
>>
>>  - master : this is our current "powerpc.git" tree, it may contain
>>             various experimental stuff that may or may not go  
>> upstream
>>             or may contain dependent patches that we rely on but that
>>             are to be merged via some other tree.
>>
>>  - next   : this is the candidate stuff for linux-next and the next
>>             merge window
>>
>> (Andrew, you -may- want to pull that instead of paulus one until
>> he's back from vacation).
>>
>> Until today, master and next pointed to the same commit, which was
>> the same as paulus master and powerpc-next branches. Tonight, I've
>> pushed some patches to master that I intend to have in next, but
>> I'd like to let them sit in master for a couple of days to make sure
>> nothing is badly broken mostly and make sure I didn't screw up in
>> my various patch monkeying operations.
>
> One thing to point out is that if you decide to only select a few of
> those patches, you'll need to cherry-pick them into your next branch
> (or rebase). That means that when you pull from Linus into your master
> branch during/after the merge window, you'll get all kinds of funny
> merge commits.
>
> If you want to use your master branch as a place for experimental
> stuff, that's fine by me.  But you'll want to keep next separate from
> it so it's as "clean" as possible for those trying to track what is
> definitely going into the next release.
>
> If it were up to me (which it's not), I would have master just track
> Linus, next track what's going into the next release, and "bleeding"  
> or
> "experimental" track stuff that isn't fully vetted yet.  I might start
> doing that with my tree in the very near future.

I do something similar, but my master is a merge of linus and my next  
branch, which is roughly what I think paul did.

> Also, Paul is pretty good about not rebasing his branches when at all
> possible, and I suspect that's why his master and next were often the
> same.  It makes life lots easier for the sub-maintainers and anyone
> trying to track against the tree.  I humbly beg you to keep that  
> going.

I agree and I'm sure linus will tell you how evil it is to rebase as a  
maintainer.

- k

Re: Updates to powerpc.git

[Grant Likely]

On Wed, Jul 09, 2008 at 08:40:21AM -0500, Kumar Gala wrote:
>
> On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
>
>> On Wed, 09 Jul 2008 17:34:41 +1000
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>> Also, Paul is pretty good about not rebasing his branches when at all
>> possible, and I suspect that's why his master and next were often the
>> same.  It makes life lots easier for the sub-maintainers and anyone
>> trying to track against the tree.  I humbly beg you to keep that  
>> going.
>
> I agree and I'm sure linus will tell you how evil it is to rebase as a  
> maintainer.

Add my voice to the chorus.  Rebasing a branch that I commit on top of
really messes up the workflow.

g.

Re: Updates to powerpc.git

[Stephen Rothwell]

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

Kumar,

On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> What is your intent with the 'master' branch?  I hope you do NOT plan  
> on ever rebasing it.  I assume if a patch gets into master and we drop  
> it you'll do a git-revert of it?

"Ever" is such a strong word.  Even Paul on occasion rebased his master
branch.  I see no reason why Ben could not run his master (or maybe
better named "test") branch as a place that patches come and go and his
"next" branch as something that never (or very rarely) gets rebased with
commits progressing from master (test) to next when he is satisfied with
them. People should then base further work in the "next" branch.

-- 
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: Updates to powerpc.git

[Grant Likely]

On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
> Kumar,
> 
> On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > What is your intent with the 'master' branch?  I hope you do NOT plan  
> > on ever rebasing it.  I assume if a patch gets into master and we drop  
> > it you'll do a git-revert of it?
> 
> "Ever" is such a strong word.  Even Paul on occasion rebased his master
> branch.  I see no reason why Ben could not run his master (or maybe
> better named "test") branch as a place that patches come and go and his
> "next" branch as something that never (or very rarely) gets rebased with
> commits progressing from master (test) to next when he is satisfied with
> them. People should then base further work in the "next" branch.

I was under the impression that there was some consensus that -next
branches should be used for unstable experiments.  Am I mistaken?

g.

Re: Updates to powerpc.git

[Josh Boyer]

On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
> On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
> > Kumar,
> > 
> > On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> > >
> > > What is your intent with the 'master' branch?  I hope you do NOT plan  
> > > on ever rebasing it.  I assume if a patch gets into master and we drop  
> > > it you'll do a git-revert of it?
> > 
> > "Ever" is such a strong word.  Even Paul on occasion rebased his master
> > branch.  I see no reason why Ben could not run his master (or maybe
> > better named "test") branch as a place that patches come and go and his
> > "next" branch as something that never (or very rarely) gets rebased with
> > commits progressing from master (test) to next when he is satisfied with
> > them. People should then base further work in the "next" branch.
> 
> I was under the impression that there was some consensus that -next
> branches should be used for unstable experiments.  Am I mistaken?

Yes,  you are.  It's slightly confusing.  -next branches are for things
decidedly going into the "next" release of the kernel.  If they are
unstable, they aren't really proven to be ready then.

josh

Re: Updates to powerpc.git

[Kumar Gala]

On Jul 9, 2008, at 11:31 AM, Josh Boyer wrote:

> On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
>> On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
>>> Kumar,
>>>
>>> On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org 
>>> > wrote:
>>>>
>>>> What is your intent with the 'master' branch?  I hope you do NOT  
>>>> plan
>>>> on ever rebasing it.  I assume if a patch gets into master and we  
>>>> drop
>>>> it you'll do a git-revert of it?
>>>
>>> "Ever" is such a strong word.  Even Paul on occasion rebased his  
>>> master
>>> branch.  I see no reason why Ben could not run his master (or maybe
>>> better named "test") branch as a place that patches come and go  
>>> and his
>>> "next" branch as something that never (or very rarely) gets  
>>> rebased with
>>> commits progressing from master (test) to next when he is  
>>> satisfied with
>>> them. People should then base further work in the "next" branch.
>>
>> I was under the impression that there was some consensus that -next
>> branches should be used for unstable experiments.  Am I mistaken?
>
> Yes,  you are.  It's slightly confusing.  -next branches are for  
> things
> decidedly going into the "next" release of the kernel.  If they are
> unstable, they aren't really proven to be ready then.

Did, GregKH start up a tree for code not quite ready ( -staging).

I think master and -next should not be rebased (if it can be  
avoided).  and -staging can be.

- k

Re: Updates to powerpc.git

[Josh Boyer]

On Wed, 9 Jul 2008 11:47:45 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Jul 9, 2008, at 11:31 AM, Josh Boyer wrote:
> 
> > On Wed, 2008-07-09 at 10:20 -0600, Grant Likely wrote:
> >> On Thu, Jul 10, 2008 at 02:08:32AM +1000, Stephen Rothwell wrote:
> >>> Kumar,
> >>>
> >>> On Wed, 9 Jul 2008 07:58:38 -0500 Kumar Gala <galak@kernel.crashing.org 
> >>> > wrote:
> >>>>
> >>>> What is your intent with the 'master' branch?  I hope you do NOT  
> >>>> plan
> >>>> on ever rebasing it.  I assume if a patch gets into master and we  
> >>>> drop
> >>>> it you'll do a git-revert of it?
> >>>
> >>> "Ever" is such a strong word.  Even Paul on occasion rebased his  
> >>> master
> >>> branch.  I see no reason why Ben could not run his master (or maybe
> >>> better named "test") branch as a place that patches come and go  
> >>> and his
> >>> "next" branch as something that never (or very rarely) gets  
> >>> rebased with
> >>> commits progressing from master (test) to next when he is  
> >>> satisfied with
> >>> them. People should then base further work in the "next" branch.
> >>
> >> I was under the impression that there was some consensus that -next
> >> branches should be used for unstable experiments.  Am I mistaken?
> >
> > Yes,  you are.  It's slightly confusing.  -next branches are for  
> > things
> > decidedly going into the "next" release of the kernel.  If they are
> > unstable, they aren't really proven to be ready then.
> 
> Did, GregKH start up a tree for code not quite ready ( -staging).

Yes.  The proliferation of "trees" is getting to be a bit ridiculous.
We have Linus, -next, -mm, -staging, plus all the subsystem variants of
those.

The answer to "What tree do I develop against" _should_ be -next, but
sometimes that isn't the case and finding the answer isn't getting
easier.

josh

Re: Updates to powerpc.git

[Stephen Rothwell]

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

Hi Grant,

On Wed, 9 Jul 2008 10:20:08 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> I was under the impression that there was some consensus that -next
> branches should be used for unstable experiments.  Am I mistaken?

Completely.  Anything that will end up in linux-next must be posted,
reviewed, unit tested and intended for the next merge window.  i.e. you
must have basically finished with it (except for inter-subsystem merge
problems and bugs, or course).

-- 
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: Updates to powerpc.git

[Stephen Rothwell]

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

Hi Kumar,

On Wed, 9 Jul 2008 11:47:45 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> Did, GregKH start up a tree for code not quite ready ( -staging).

Greg's staging tree is for whole drivers etc not in the kernel yet that
need work to get there.

-- 
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: Updates to powerpc.git

[Grant Likely]

On Thu, Jul 10, 2008 at 03:23:46AM +1000, Stephen Rothwell wrote:
> Hi Grant,
> 
> On Wed, 9 Jul 2008 10:20:08 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > I was under the impression that there was some consensus that -next
> > branches should be used for unstable experiments.  Am I mistaken?
> 
> Completely.  Anything that will end up in linux-next must be posted,
> reviewed, unit tested and intended for the next merge window.  i.e. you
> must have basically finished with it (except for inter-subsystem merge
> problems and bugs, or course).

Okay, thanks for the correction.

Cheers,
g.

Re: Updates to powerpc.git

[Benjamin Herrenschmidt]

> What is your intent with the 'master' branch?  I hope you do NOT plan  
> on ever rebasing it.  I assume if a patch gets into master and we drop  
> it you'll do a git-revert of it?

I'll try as much as possible. But I'll keep the option open. "next" is
the one that should never be rebased I'd say.

Ben.

Re: Updates to powerpc.git

[Benjamin Herrenschmidt]

On Wed, 2008-07-09 at 09:18 -0400, Josh Boyer wrote:
> 
> If you want to use your master branch as a place for experimental
> stuff, that's fine by me.  But you'll want to keep next separate from
> it so it's as "clean" as possible for those trying to track what is
> definitely going into the next release.

Yes. The idea is that "next" stays clean.

> If it were up to me (which it's not), I would have master just track
> Linus, next track what's going into the next release, and "bleeding"
> or "experimental" track stuff that isn't fully vetted yet.  I might
> start doing that with my tree in the very near future.

Why keeping a branch to track linus in my public tree ? I have plenty of
these locally :-)

> Also, Paul is pretty good about not rebasing his branches when at all
> possible, and I suspect that's why his master and next were often the
> same.  It makes life lots easier for the sub-maintainers and anyone
> trying to track against the tree.  I humbly beg you to keep that
> going.

Yes. I intend to stay on that line, but as I'm new to the job, mistake
are more likely to happen.

Cheers,
Ben.

Re: Updates to powerpc.git

[Grant Likely]

On Sat, Jul 12, 2008 at 01:30:58PM +1000, Benjamin Herrenschmidt wrote:
> 
> > What is your intent with the 'master' branch?  I hope you do NOT plan  
> > on ever rebasing it.  I assume if a patch gets into master and we drop  
> > it you'll do a git-revert of it?
> 
> I'll try as much as possible. But I'll keep the option open. "next" is
> the one that should never be rebased I'd say.

I'm cool with that.  As long as I've got something stable to commit on
top of.  :-)

g.

Re: Updates to powerpc.git

[Benjamin Herrenschmidt]

On Wed, 2008-07-09 at 17:34 +1000, Benjamin Herrenschmidt wrote:
> 
> It contains 3 branches:
> 
>   - merge  : this is for merging with the current stable and doesn't
>              currently contain anything interesting
> 
>   - master : this is our current "powerpc.git" tree, it may contain
>              various experimental stuff that may or may not go upstream
>              or may contain dependent patches that we rely on but that
>              are to be merged via some other tree.
> 
>   - next   : this is the candidate stuff for linux-next and the next
>              merge window

-next and -merge are now both to the same level, which is the same
as I pushed last week plus a merge with 2.6.26 to resolve a conflict.

I'll start putting new stuff in tomorrow if all goes well.

Cheers,
Ben.

Re: Updates to powerpc.git

[Stephen Rothwell]

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

Hi Ben,

On Mon, 14 Jul 2008 15:32:36 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> -next and -merge are now both to the same level, which is the same

I think you meant -master (not -merge).

-- 
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: Updates to powerpc.git

[Benjamin Herrenschmidt]

On Mon, 2008-07-14 at 15:49 +1000, Stephen Rothwell wrote:
> Hi Ben,
> 
> On Mon, 14 Jul 2008 15:32:36 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > -next and -merge are now both to the same level, which is the same
> 
> I think you meant -master (not -merge).

Yup, typo, sorry.

-merge will be updated to that level if -next is happy.

Cheers,
Ben.