linux-next: manual merge of the arm tree with Linus' tree

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
from the arm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index b342f57,ea13a09..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -1932,6 -1932,8 +1932,7 @@@ static void finish_task_switch(struct r
  	local_irq_enable();
  #endif /* __ARCH_WANT_INTERRUPTS_ON_CTXSW */
  	finish_lock_switch(rq, prev);
+ 	finish_arch_post_lock_switch();
 -	trace_sched_stat_sleeptime(current, rq->clock);
  
  	fire_sched_in_preempt_notifiers(current);
  	if (mm)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Russell,
> 
> Today's linux-next merge of the arm tree got a conflict in
> kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> from the arm tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

This commit seems simple enough and has PeterZ's ack, but if 
there are more scheduler patches coming in this area then please 
send it to the scheduler tree first: we can create a pullable, 
stable topic branch for it which the ARM tree can then use.

That approach would also avoid conflicts as a side effect.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Russell,
> > 
> > Today's linux-next merge of the arm tree got a conflict in
> > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > from the arm tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.
> 
> This commit seems simple enough and has PeterZ's ack, but if 
> there are more scheduler patches coming in this area then please 
> send it to the scheduler tree first: we can create a pullable, 
> stable topic branch for it which the ARM tree can then use.
> 
> That approach would also avoid conflicts as a side effect.

Please check your mailbox:

Date: Tue, 29 Nov 2011 12:22:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>,
        Russell King <linux@arm.linux.org.uk>
Subject: [RFC PATCH 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

Date: Mon, 19 Dec 2011 14:57:48 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
        Peter Zijlstra <peterz@infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Frank Rowand <frank.rowand@am.sony.com>
Subject: [RFC PATCH v2 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

Date: Fri, 20 Jan 2012 17:42:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>,
        Frank Rowand <frank.rowand@am.sony.com>
Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi Russell,
> > > 
> > > Today's linux-next merge of the arm tree got a conflict in
> > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > from the arm tree.
> > > 
> > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > necessary.
> > 
> > This commit seems simple enough and has PeterZ's ack, but if 
> > there are more scheduler patches coming in this area then 
> > please send it to the scheduler tree first: we can create a 
> > pullable, stable topic branch for it which the ARM tree can 
> > then use.
> > 
> > That approach would also avoid conflicts as a side effect.
> 
> Please check your mailbox:

I'm aware of that old thread, I'd just prefer to hear about your 
plans patching the scheduler *before* you commit it to 
linux-next ;-)

Please make sure none of these scheduler patches go to the ARM 
tree without a proper Git space solution that involves the 
scheduler folks.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:36:30AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > > 
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > Hi Russell,
> > > > 
> > > > Today's linux-next merge of the arm tree got a conflict in
> > > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > > from the arm tree.
> > > > 
> > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > > 
> > > This commit seems simple enough and has PeterZ's ack, but if 
> > > there are more scheduler patches coming in this area then 
> > > please send it to the scheduler tree first: we can create a 
> > > pullable, stable topic branch for it which the ARM tree can 
> > > then use.
> > > 
> > > That approach would also avoid conflicts as a side effect.
> > 
> > Please check your mailbox:
> 
> I'm aware of that old thread, I'd just prefer to hear about your 
> plans patching the scheduler *before* you commit it to 
> linux-next ;-)
> 
> Please make sure none of these scheduler patches go to the ARM 
> tree without a proper Git space solution that involves the 
> scheduler folks.

Sorry, you're blaming the wrong person.  I got the commit via a pull,
not via a patch.

If that's how you want to run your bit of the kernel, then please be more
responsive when you're sent patches and say how you want to handle things.
Don't ignore patches and then blame people when conflicts happen.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Please check your mailbox:
> 
> Date: Fri, 20 Jan 2012 17:42:27 +0000
> From: Catalin Marinas <catalin.marinas@arm.com>
> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
>         Peter Zijlstra <peterz@infradead.org>,
>         Will Deacon <will.deacon@arm.com>,
>         Frank Rowand <frank.rowand@am.sony.com>
> Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
>         scheduler hook

Btw., are you losing emails? Because the reply from peterz to 
those patches, a month ago, was pretty clear:

> > Russell, what's the status of these patches? I'd like to see 
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some 
> > other patches on top.

You never replied to PeterZ's request, you just ignored this 
scheduler maintainer request and you just did it in some random 
way that was most convenient to you many weeks after the thread 
died down, ignoring everyone else's concerns - a pretty usual 
pattern from you I have to say.

Had you followed PeterZ's request this conflict in linux-next 
could have been avoided, amongst other things.

Given that the merge window is close I doubt there will be 
other, more difficult to resolve conflicts, but this incident 
again demonstrates your inability to communicate efficiently and 
amicably, forcing me to highlight it in this trivial case 
because it's a sadly reoccuring pattern.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Sorry, you're blaming the wrong person.  I got the commit via 
> a pull, not via a patch.

This is the most idiotic excuse I've ever read.

Dammit, don't pull code you don't maintain and which you have 
not checked the background of, *especially* not if the 
originating discussion very clearly asked *you* to do it in 
another way.

We were modifying that very code in this development cycle, in 
the scheduler tree - a fact highlighted by the conflict - which 
you could have seen yourself, had you even attempted to 
test-merge your tree to linux-next ...

Let me quote PeterZ again:

> > Russell, what's the status of these patches? I'd like to see 
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some 
> > other patches on top.

Russell, read and reply to your mail in a timely and reliable 
fashion, that will avoid such mixups in the future.

> If that's how you want to run your bit of the kernel, then 
> please be more responsive when you're sent patches and say how 
> you want to handle things. Don't ignore patches and then blame 
> people when conflicts happen.

Stop blaming others for your own mistakes, one of the the 
scheduler maintainers replied to the patches a month ago, in an 
absolutely constructive fashion:

  http://lkml.org/lkml/2012/2/16/232

You never replied to PeterZ that I can see.

Again, fortunately it's not a big deal right now - both the 
commit and the conflict is trivial - but your current attitute 
towards applying patches and following discussions is rather sad 
and could cause bigger problems in the future.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Please check your mailbox:
> > 
> > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> >         Peter Zijlstra <peterz@infradead.org>,
> >         Will Deacon <will.deacon@arm.com>,
> >         Frank Rowand <frank.rowand@am.sony.com>
> > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> >         scheduler hook
> 
> Btw., are you losing emails? Because the reply from peterz to 
> those patches, a month ago, was pretty clear:
> 
> > > Russell, what's the status of these patches? I'd like to see 
> > > them land in 3.4 if possible. I'm fine either way, I'll
> > >
> > > probably ask Ingo to pull your tree so that I can stack some 
> > > other patches on top.
> 
> You never replied to PeterZ's request, you just ignored this 
> scheduler maintainer request and you just did it in some random 
> way that was most convenient to you many weeks after the thread 
> died down, ignoring everyone else's concerns - a pretty usual 
> pattern from you I have to say.

Sigh.  You know, people communicate via other methods from time to time.
How the hell do you think PeterZ provided his ack for the patch?

Stop looking for people to blame.  Instead, if you failed to communicate
about how you wanted to handle the patch, blame yourself instead.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Sorry, you're blaming the wrong person.  I got the commit via 
> > a pull, not via a patch.
> 
> This is the most idiotic excuse I've ever read.

Sod this crap, I'm dropping Catalin's patches.  Deal with the fucking thing
yourself.  Catalin, sorry, put some people are just total idiots over
simple merge conflicts and blow things totally out of proportion.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Please check your mailbox:
> > > 
> > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > >         Peter Zijlstra <peterz@infradead.org>,
> > >         Will Deacon <will.deacon@arm.com>,
> > >         Frank Rowand <frank.rowand@am.sony.com>
> > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > >         scheduler hook
> > 
> > Btw., are you losing emails? Because the reply from peterz to 
> > those patches, a month ago, was pretty clear:
> > 
> > > > Russell, what's the status of these patches? I'd like to see 
> > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > >
> > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > other patches on top.
> > 
> > You never replied to PeterZ's request, you just ignored this 
> > scheduler maintainer request and you just did it in some 
> > random way that was most convenient to you many weeks after 
> > the thread died down, ignoring everyone else's concerns - a 
> > pretty usual pattern from you I have to say.
> 
> Sigh.  You know, people communicate via other methods from 
> time to time. How the hell do you think PeterZ provided his 
> ack for the patch?

He provided it via email to lkml:

  http://lkml.org/lkml/2012/2/27/210

But he asked *you* to do a proper Git space solution:

  http://lkml.org/lkml/2012/2/16/232

You *never* replied to that request that I can see, you just 
ignored it, why?

This discussion shows that you seem to have basic reading 
comprehension problems.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

From: Catalin Marinas <catalin.marinas@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
        Peter Zijlstra <peterz@infradead.org>
Subject: [GIT PULL] ARM: Remove the __ARCH_WANT_INTERRUPTS_ON_CTXSW
        definition
Delivery-date: Mon, 27 Feb 2012 16:45:17 +0000

Hi Russell,

Could you please pull the context switching patches for ARM, together
with a generic hook acked by PeterZ?

Thanks,

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > Please check your mailbox:
> > > > 
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > >         Peter Zijlstra <peterz@infradead.org>,
> > > >         Will Deacon <will.deacon@arm.com>,
> > > >         Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > >         scheduler hook
> > > 
> > > Btw., are you losing emails? Because the reply from peterz to 
> > > those patches, a month ago, was pretty clear:
> > > 
> > > > > Russell, what's the status of these patches? I'd like to see 
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > > other patches on top.
> > > 
> > > You never replied to PeterZ's request, you just ignored this 
> > > scheduler maintainer request and you just did it in some 
> > > random way that was most convenient to you many weeks after 
> > > the thread died down, ignoring everyone else's concerns - a 
> > > pretty usual pattern from you I have to say.
> > 
> > Sigh.  You know, people communicate via other methods from 
> > time to time. How the hell do you think PeterZ provided his 
> > ack for the patch?
> 
> He provided it via email to lkml:
> 
>   http://lkml.org/lkml/2012/2/27/210
> 
> But he asked *you* to do a proper Git space solution:
> 
>   http://lkml.org/lkml/2012/2/16/232
> 
> You *never* replied to that request that I can see, you just 
> ignored it, why?

I talked to peterz by other means.  He gave his ack after that message was
sent.  He was fully aware of what was happening.

> This discussion shows that you seem to have basic reading 
> comprehension problems.

And your a fucking idiot too.  Go to hell Ingo and stop being an utter
prat.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

Oh and one last thing.  I'm never going to take any patch which touches
the scheduler ever again, no matter how trivial.  If that means people
can't get their patches in, then that's not my loss - that's your loss.
Especially when they're removing a special case from the scheduler -
which I hasten to add was requested by PeterZ.

I really don't care what you have to say in reply, I'm no longer listening
to objectionable people like you who make a mountain out of a mole hill.

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > Please check your mailbox:
> > > > 
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > >         Peter Zijlstra <peterz@infradead.org>,
> > > >         Will Deacon <will.deacon@arm.com>,
> > > >         Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > >         scheduler hook
> > > 
> > > Btw., are you losing emails? Because the reply from peterz to 
> > > those patches, a month ago, was pretty clear:
> > > 
> > > > > Russell, what's the status of these patches? I'd like to see 
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > > other patches on top.
> > > 
> > > You never replied to PeterZ's request, you just ignored this 
> > > scheduler maintainer request and you just did it in some 
> > > random way that was most convenient to you many weeks after 
> > > the thread died down, ignoring everyone else's concerns - a 
> > > pretty usual pattern from you I have to say.
> > 
> > Sigh.  You know, people communicate via other methods from 
> > time to time. How the hell do you think PeterZ provided his 
> > ack for the patch?
> 
> He provided it via email to lkml:
> 
>   http://lkml.org/lkml/2012/2/27/210
> 
> But he asked *you* to do a proper Git space solution:
> 
>   http://lkml.org/lkml/2012/2/16/232
> 
> You *never* replied to that request that I can see, you just 
> ignored it, why?
> 
> This discussion shows that you seem to have basic reading 
> comprehension problems.
> 
> Thanks,
> 
> 	Ingo

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Sorry, you're blaming the wrong person.  I got the commit via 
> > > a pull, not via a patch.
> > 
> > This is the most idiotic excuse I've ever read.
> 
> Sod this crap, I'm dropping Catalin's patches. [...]

As I said it in my first mail, doing that is unnecessary - but 
if you insist on being difficult then Catalin, feel free to pull 
the patch from tip:sched/arch:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch

   HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

it's v3.3-rc7 based so it will generate no conflict with 
linux-next. It only contains this commit so you can use it 
without pulling in other pending scheduler changes.

This is the trivial and easy Git based topic branch approach 
PeterZ asked Russell a month ago to consider:

   http://lkml.org/lkml/2012/2/16/232

which request Russell sadly ignored.

In any case, Catalin's ARM work is not blocked in any fashion.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but 
> if you insist on being difficult then Catalin, feel free to pull 
> the patch from tip:sched/arch:

Nope, I'm not taking the tree anymore, you've refused to behave in a
reasonable way.  Your problem to sort out now.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> >
> > As I said it in my first mail, doing that is unnecessary - 
> > but if you insist on being difficult then Catalin, feel free 
> > to pull the patch from tip:sched/arch:
> 
> Nope, I'm not taking the tree anymore, [...]

So instead of saying "sure, lets avoid conflicts next time 
around" you are now *refusing* to take technically perfectly 
fine patches just because another maintainer asked you to use a 
different workflow for future patches? Wow ...

Regardless of the imperfect workflow I certainly find Catalin's 
work useful technically, so I'll send his preparatory commit to 
Linus in this merge window - I hope you will see sense later and 
won't block his subsequent ARM patches...

> [...] you've refused to behave in a reasonable way.  Your 
> problem to sort out now.

For the record, that's utter nonsense:

 - *You* failed to reply on the public thread to sort this out
   properly in the Git space, avoiding conflicts naturally:

      http://lkml.org/lkml/2012/2/16/232

   While generally we don't mind conflicts, I do mind 
   *avoidable* conflicts - and this was such a case.

 - *You* created a conflict by taking a tree that patched some 
   rather old version of the scheduler, shortly before the merge 
   window, when maintainer capacity is the shortest. PeterZ
   is a nice guy who will agree to just about any approach, but 
   I'm quite sure he did not tell you to do *that* ;-)

 - *You* replied to me in a rather dismissive and increasingly
   obnoxious style when I inquired about it constructively:

     http://lkml.org/lkml/2012/3/13/79

There were several easy solutions - I cannot believe that we are 
still arguing this:

 - it literally took me two minutes to create a proper Git
   solution, it's not rocket science. You could have done it, or
   I could have done it for you (as I have done it).

 - Or you could have replied to the public thread, explaining
   why that is not desirable.

 - Or you could have said "sure thing, lets do it that way next
   time around".

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

Hi Ingo,

On Tue, Mar 13, 2012 at 09:26:49AM +0000, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but 
> if you insist on being difficult then Catalin, feel free to pull 
> the patch from tip:sched/arch:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch
> 
>    HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
> 
> it's v3.3-rc7 based so it will generate no conflict with 
> linux-next. It only contains this commit so you can use it 
> without pulling in other pending scheduler changes.

Thanks for merging the scheduler hook.

So I'll send Russell another pull request after the 3.4-rc1, containing
only ARM patches. The only drawback is that the removal of
__ARCH_WANT_INTERRUPTS_ON_CTXSW will have to wait another release cycle.

-- 
Catalin

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > >
> > > As I said it in my first mail, doing that is unnecessary - 
> > > but if you insist on being difficult then Catalin, feel free 
> > > to pull the patch from tip:sched/arch:
> > 
> > Nope, I'm not taking the tree anymore, [...]
> 
> So instead of saying "sure, lets avoid conflicts next time 
> around" you are now *refusing* to take technically perfectly 
> fine patches just because another maintainer asked you to use a 
> different workflow for future patches? Wow ...

No, I'm pissed off at how you're treating me over this trivial issue,
so I'm taking the easy way out and getting out of the way.  If you want
to run your bit of the tree with idiotic rules about zero conflicts,
and "git solutions" then that's your perogative.  Just don't expect
other people to play with you.

The fact of the matter is that Peter Z. was fully aware of what was
happening.  He was aware that he'd been asked for his ack for that
patch (because I'd explicitly asked Peter for it, but not by email) -
and he provided his ack for that patch to Catalin:

http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html

Catalin sent a pull request to me, copying Peter Z on the 27th Feb:

http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html

I pulled it into my tree for testing, and pushed it out in the last
couple of days.

Moreover, these kinds of trivial conflicts are the type of things which
Linus wants to see between trees.  It allows him to get a feel for what's
going on, and makes Linus feel like he's more on top of things.  Linus
said that he would like to see these trivial conflicts (he said so to me
in an email dated 15th Jan 2011).

So please, stop your insistance on this zero conflict crap.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > As I said it in my first mail, doing that is unnecessary - 
> > > > but if you insist on being difficult then Catalin, feel free 
> > > > to pull the patch from tip:sched/arch:
> > > 
> > > Nope, I'm not taking the tree anymore, [...]
> > 
> > So instead of saying "sure, lets avoid conflicts next time 
> > around" you are now *refusing* to take technically perfectly 
> > fine patches just because another maintainer asked you to use a 
> > different workflow for future patches? Wow ...
> 
> No, I'm pissed off at how you're treating me over this trivial issue,
> so I'm taking the easy way out and getting out of the way.  If you want
> to run your bit of the tree with idiotic rules about zero conflicts,
> and "git solutions" then that's your perogative.  Just don't expect
> other people to play with you.
> 
> The fact of the matter is that Peter Z. was fully aware of what was
> happening.  He was aware that he'd been asked for his ack for that
> patch (because I'd explicitly asked Peter for it, but not by email) -
> and he provided his ack for that patch to Catalin:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> 
> Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> 
> I pulled it into my tree for testing, and pushed it out in the last
> couple of days.
> 
> Moreover, these kinds of trivial conflicts are the type of things which
> Linus wants to see between trees.  It allows him to get a feel for what's
> going on, and makes Linus feel like he's more on top of things.  Linus
> said that he would like to see these trivial conflicts (he said so to me
> in an email dated 15th Jan 2011).
> 
> So please, stop your insistance on this zero conflict crap.

While I still think this is a storm in a teacup, I think you are 
subtly misunderstanding Linus's position about conflicts and you 
are seriously misrepresenting my request and my position as 
well:

The thing is, most conflicts are fine in general. So on one hand 
you are right, we *do* allow and quite often *keep* conflicts in 
place even within our own topic branches.

Those are *real* conflicts that Linus would arguably be 
interested in: two teams working on two things in parallel that 
somehow conflict at the code level content-wise or concept-wise 
- high level maintainers rightfully are curious about those 
kinds of conflicts because while often they are just fine, it 
might also be the canary of possible workflow problems or it 
might also be the canary of the code being shaped in some 
inefficient way.

On the other hand, this particular conflict you pushed to 
linux-next is *neither*, and this is what got my attention. This 
is a plain *STUPID* conflict.

Look into the fine conflict report Russell: it conflicts with 
*Linus's* tree, because it's based off some random 
barely-beyond-rc1 development window -rc3 base. Even at the 
commit date of Feb 27 we had a more stable base tree available - 
and especially when you pulled it, several weeks down the line, 
-rc3 was not a defensible base for the integrated result.

Having a patch applied to an old scheduler tree that is barely 
out of -rc1 and then pushing it out into linux-next at -rc8, 
without even checking how it integrates with upstream, barely a 
few days before the merge window is just plain stupid.

While nothing of what you talked to PeterZ is visible in the 
public record, I'm quite sure had you asked him about what base 
kernel to use, he'd have suggested something much more stable 
...

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > > >
> > > > > As I said it in my first mail, doing that is unnecessary - 
> > > > > but if you insist on being difficult then Catalin, feel free 
> > > > > to pull the patch from tip:sched/arch:
> > > > 
> > > > Nope, I'm not taking the tree anymore, [...]
> > > 
> > > So instead of saying "sure, lets avoid conflicts next time 
> > > around" you are now *refusing* to take technically perfectly 
> > > fine patches just because another maintainer asked you to use a 
> > > different workflow for future patches? Wow ...
> > 
> > No, I'm pissed off at how you're treating me over this trivial issue,
> > so I'm taking the easy way out and getting out of the way.  If you want
> > to run your bit of the tree with idiotic rules about zero conflicts,
> > and "git solutions" then that's your perogative.  Just don't expect
> > other people to play with you.
> > 
> > The fact of the matter is that Peter Z. was fully aware of what was
> > happening.  He was aware that he'd been asked for his ack for that
> > patch (because I'd explicitly asked Peter for it, but not by email) -
> > and he provided his ack for that patch to Catalin:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> > 
> > Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> > 
> > I pulled it into my tree for testing, and pushed it out in the last
> > couple of days.
> > 
> > Moreover, these kinds of trivial conflicts are the type of things which
> > Linus wants to see between trees.  It allows him to get a feel for what's
> > going on, and makes Linus feel like he's more on top of things.  Linus
> > said that he would like to see these trivial conflicts (he said so to me
> > in an email dated 15th Jan 2011).
> > 
> > So please, stop your insistance on this zero conflict crap.
> 
> While I still think this is a storm in a teacup, I think you are 
> subtly misunderstanding Linus's position about conflicts and you 
> are seriously misrepresenting my request and my position as 
> well:
> 
> The thing is, most conflicts are fine in general. So on one hand 
> you are right, we *do* allow and quite often *keep* conflicts in 
> place even within our own topic branches.
> 
> Those are *real* conflicts that Linus would arguably be 
> interested in: two teams working on two things in parallel that 
> somehow conflict at the code level content-wise or concept-wise 
> - high level maintainers rightfully are curious about those 
> kinds of conflicts because while often they are just fine, it 
> might also be the canary of possible workflow problems or it 
> might also be the canary of the code being shaped in some 
> inefficient way.
> 
> On the other hand, this particular conflict you pushed to 
> linux-next is *neither*, and this is what got my attention. This 
> is a plain *STUPID* conflict.
> 
> Look into the fine conflict report Russell: it conflicts with 
> *Linus's* tree, because it's based off some random 
> barely-beyond-rc1 development window -rc3 base. Even at the 
> commit date of Feb 27 we had a more stable base tree available - 
> and especially when you pulled it, several weeks down the line, 
> -rc3 was not a defensible base for the integrated result.
> 
> Having a patch applied to an old scheduler tree that is barely 
> out of -rc1 and then pushing it out into linux-next at -rc8, 
> without even checking how it integrates with upstream, barely a 
> few days before the merge window is just plain stupid.
> 
> While nothing of what you talked to PeterZ is visible in the 
> public record, I'm quite sure had you asked him about what base 
> kernel to use, he'd have suggested something much more stable 
> ...

Why am _I_ responsible for which kernel version _Catalin_ used for _his_
patches when _he_ committed them?

You're insane.  Totally.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> [...]
> 
> Having a patch applied to an old scheduler tree that is barely 
> out of -rc1 and then pushing it out into linux-next at -rc8, 
> without even checking how it integrates with upstream, barely 
> a few days before the merge window is just plain stupid.

So, while I cannot know what Linus will think and do once he 
gets such a conflict (my guess is that he'd just fix it up 
silently - it's really trivial), I can tell you what the 
conflict told *me*: that the communication channels between the 
ARM tree and the scheduler tree are not in the best of shape.

And that is what worried me enough to write a reply while 
recognizing that PeterZ acked the patch - not the triviality of 
the patch or the triviality of the conflict.

And dammit, I have the right and the duty to be concerned about 
a conflict in the scheduler code if I see it for the first time, 
not just Linus. Conflicts aren't magically just for Linus to be 
interested and act upon, they can occasionally be informative at 
subsystem maintainer levels just as well - like here...

What we should not do in terms of conflict avoidance are 
*excessive* cross-subsystem merges: for example you 
indiscriminately merging the totality of all pending scheduler 
changes into the ARM tree and thus forcing Linus's hand in terms 
of not being able to reject to pull the scheduler tree.

But if I got it right, working together on a trivial, 
well-isolated callback patch to make life easier is not frowned 
upon by Linus at all ...

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> Look into the fine conflict report Russell: it conflicts with 
> *Linus's* tree, because it's based off some random 
> barely-beyond-rc1 development window -rc3 base. Even at the 
> commit date of Feb 27 we had a more stable base tree available - 
> and especially when you pulled it, several weeks down the line, 
> -rc3 was not a defensible base for the integrated result.

I'm not going to ask someone to rebase their patches after they've been
fully tested on a set of platforms.  It has been stated many times that
rebasing invalidates the testing that the patches have been subjected
to, and these have been tested by several different people on a range
of platforms.

It seems what _you_ care more about is having nice clean git trees and
proper git flow at the detriment to dealing with tested changes.

The fact of the matter is that I took a set of well tested patches into
my tree which _you_ were copied on multiple times, that Peter Z. was
aware of what was happening, and which trivially conflict with some other
change which happened along the way.  Such a trivial conflict does _NOT_
justify rebasing the patch set, thereby invalidating all the testing that
has done.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Why am _I_ responsible for which kernel version _Catalin_ used 
> for _his_ patches when _he_ committed them?

If you then pull that tree from him and push it out to 
linux-next? Then *of course* you are responsible, it was your 
decision to pull it.

I frequently reject pulls from subsystem maintainers on similar 
(and sometimes lesser) grounds - because such mistakes tend to 
compound with time.

The thing is, if you do Git pulls from someone then you must be 
absolutely anal about it, because you cannot really fix things 
up after the fact. The people you pull from must be your 
extended arms, they must be doing an equal or better job than 
you. That gives a basis of trust.

Once that is established, you can be permissive about mistakes. 

But arguing that you are not responsible for what you pull is 
absolutely grotesque and establishes a new low for this 
discussion really...

Also, as I told you in the very first mail, I am *fine* with 
this having happened, so you having zapped the commits is 
indefensible IMO. Mistakes do happen and the patch is fine 
technically and sfr and Linus could have handled the trivial 
conflict. What I suggested was to do it a bit better in the 
future. Is that too much to ask for?

> You're insane.  Totally.

I think you owe me an apology :-(

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Why am _I_ responsible for which kernel version _Catalin_ used 
> > for _his_ patches when _he_ committed them?
> 
> If you then pull that tree from him and push it out to 
> linux-next? Then *of course* you are responsible, it was your 
> decision to pull it.
> 
> I frequently reject pulls from subsystem maintainers on similar 
> (and sometimes lesser) grounds - because such mistakes tend to 
> compound with time.
> 
> The thing is, if you do Git pulls from someone then you must be 
> absolutely anal about it, because you cannot really fix things 
> up after the fact. The people you pull from must be your 
> extended arms, they must be doing an equal or better job than 
> you. That gives a basis of trust.
> 
> Once that is established, you can be permissive about mistakes. 
> 
> But arguing that you are not responsible for what you pull is 
> absolutely grotesque and establishes a new low for this 
> discussion really...
> 
> Also, as I told you in the very first mail, I am *fine* with 
> this having happened, so you having zapped the commits is 
> indefensible IMO. Mistakes do happen and the patch is fine 
> technically and sfr and Linus could have handled the trivial 
> conflict. What I suggested was to do it a bit better in the 
> future. Is that too much to ask for?
> 
> > You're insane.  Totally.
> 
> I think you owe me an apology :-(

I owe you nothing.  From where I stand, I did nothing wrong.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > Look into the fine conflict report Russell: it conflicts with 
> > *Linus's* tree, because it's based off some random 
> > barely-beyond-rc1 development window -rc3 base. Even at the 
> > commit date of Feb 27 we had a more stable base tree available - 
> > and especially when you pulled it, several weeks down the line, 
> > -rc3 was not a defensible base for the integrated result.
> 
> I'm not going to ask someone to rebase their patches after 
> they've been fully tested on a set of platforms. [...]

That's a new argument which might be a valid concern in general 
*if you make that decision when you pull the tree* - but you 
should admit that you werent even aware of the conflict and of 
the root cause behind it, let alone be in the position to 
consider whether a rebase is justified in that case ...

( Paradoxially, rebasing is exactly what *you* ended up forcing
  others to do. I have not asked you or Catalin to rebase any
  existing commit. I merely asked about future plans. )

So I think you are just making this up on the fly. Really, if I 
push back on you in a 100% *permissive* fashion, and if my 
complaint is justified, then the proper response is for you to 
push back on your contributors - while we can keep all commits 
in place.

Instead you first pushed back on *me*, then you claimed that you 
are not responsible for what you pull, then you started zapping 
patches and claiming that you will never pull them again, 
blaming it all on me.

Again, a storm in a teacup IMO.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Why am _I_ responsible for which kernel version _Catalin_ used 
> > > for _his_ patches when _he_ committed them?
> > 
> > If you then pull that tree from him and push it out to 
> > linux-next? Then *of course* you are responsible, it was your 
> > decision to pull it.
> > 
> > I frequently reject pulls from subsystem maintainers on similar 
> > (and sometimes lesser) grounds - because such mistakes tend to 
> > compound with time.
> > 
> > The thing is, if you do Git pulls from someone then you must be 
> > absolutely anal about it, because you cannot really fix things 
> > up after the fact. The people you pull from must be your 
> > extended arms, they must be doing an equal or better job than 
> > you. That gives a basis of trust.
> > 
> > Once that is established, you can be permissive about mistakes. 
> > 
> > But arguing that you are not responsible for what you pull is 
> > absolutely grotesque and establishes a new low for this 
> > discussion really...
> > 
> > Also, as I told you in the very first mail, I am *fine* with 
> > this having happened, so you having zapped the commits is 
> > indefensible IMO. Mistakes do happen and the patch is fine 
> > technically and sfr and Linus could have handled the trivial 
> > conflict. What I suggested was to do it a bit better in the 
> > future. Is that too much to ask for?
> > 
> > > You're insane.  Totally.
> > 
> > I think you owe me an apology :-(
> 
> I owe you nothing.  From where I stand, I did nothing wrong.

Well, even ignoring the arguments you hurled several ad hominems 
at me while I wrote none.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 01:44:33PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > > Look into the fine conflict report Russell: it conflicts with 
> > > *Linus's* tree, because it's based off some random 
> > > barely-beyond-rc1 development window -rc3 base. Even at the 
> > > commit date of Feb 27 we had a more stable base tree available - 
> > > and especially when you pulled it, several weeks down the line, 
> > > -rc3 was not a defensible base for the integrated result.
> > 
> > I'm not going to ask someone to rebase their patches after 
> > they've been fully tested on a set of platforms. [...]
> 
> That's a new argument which might be a valid concern in general 
> *if you make that decision when you pull the tree* - but you 
> should admit that you werent even aware of the conflict and of 
> the root cause behind it, let alone be in the position to 
> consider whether a rebase is justified in that case ...

No Ingo.  I was aware of the conflict, because when I merged it into
my test tree, I got that conflict and fixed it up myself before I
tested the frigging thing.

> So I think you are just making this up on the fly.

If you think that, we have nothing further to discuss.  But I know
I'm right, because:

commit e3507976ee7ad0a58fa68ce919a7acfcfec28e3b
Merge: 4c17fe7 8cee1aa
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Mar 8 09:51:31 2012 +0000

    Merge branch 'intr-ctxsw' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux

    Conflicts:
        kernel/sched/core.c

http://ftp.arm.linux.org.uk/git/?p=linux-next.git;a=commitdiff;h=e350797
(which is _not_ in a public branch, and is _only_ accessible via knowing
the commit id.)

Oh look, March 8th.  Oh, that's last Thursday.  Oh, maybe I did merge
it a while back after all, maybe I'm not making this crap up.  Maybe
I did know about the conflict but didn't think anything of it because
it was soo trivial.

> Instead you first pushed back on *me*, then you claimed that you 
> are not responsible for what you pull, then you started zapping 

No I did not.  What I said was that I'm not responsible for the points
at which people choose to base their patches, which is something entirely
different.  Unlike you, I have _no_ _problem_ with pulling work based on
_any_ -rc, or indeed any commit whatsoever - provided it's been tested
and it merges relatively cleanly with the branch I'm pulling it into.

> patches and claiming that you will never pull them again, 
> blaming it all on me.

I'm only blaming this thread on you, precisely because you're making a
mountain out of a mole hill.  There's no problem here.  Really.  At all.
You're just blowing it out of all proportion making it into some huge big
issue.  _That_ alone is the whole reason why I've dropped Catalins patches.
I don't want to be subjected to your rants over this.  Instead, _you_ can
deal with this patch set and deal with the other conflicts which git can
resolve automatically.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> > Instead you first pushed back on *me*, then you claimed that 
> > you are not responsible for what you pull, then you started 
> > zapping
> 
> No I did not.  What I said was that I'm not responsible for 
> the points at which people choose to base their patches, which 
> is something entirely different. [...]

What are you talking about?

Firstly, in general *every single bit* of what you pull, 
including the base, the patch titles, the commit logs, the 
signoff chain, etc. is all part of the picture and you 
absolutely should require your contributors and submaintainers 
to do a fine job with all that.

No ifs and whens about that - it all becomes your responsibility 
as well when you decide to pull from people.

Instead you are now teaching them the exact *opposite*: for 
example you have just declared that you don't feel responsible 
for the base kernel ...

Using a sane base is IMHO part of Git pull 101. Teaching 
contributors or submaintainers to not use too old base kernels 
(or too new ones, for example during the merge window) is an 
important part of the picture.

A basic rule for bases is to either use the previous stable 
kernel release, of if that's not possible then use the freshest 
-rc available at the time of the commit - which by my quick look 
should have been about -rc6, not -rc3.

Secondly, my other problem was that this all surfaced today, at 
-rc8 time, shortly before the merge window, a very busy period 
of time.

If this was committed a month ago, if you indeed saw the 
conflict earlier proves *more* workflow breakage IMO: you pushed 
it upstream despite being aware of it being the result of a 
slightly suboptimal base, without asking whether the scheduler 
folks are still fine with all that?

Thirdly, all this totally ignores the issue you still have not 
answered: why did you leave PeterZ public lkml question about 
this unanswered:

   http://lkml.org/lkml/2012/2/16/232

PeterZ's request to put this into a separate branch was totally 
reasonable IMHO - and could have avoided this long thread, 
amongst other things. Instead you've mixed it with other bits.

Really, my quick impression is that you should learn to push 
back downstream a bit, especially as I didn't even ask for a 
rebase, a revert or anything other drastic.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

Anyway - regardless of any differences and flames about workflow 
details, both you and Catalin should still feel free to use both 
the original commit (1cf00341547a) or the tip:sched/arch branch 
I provided (01f23e1630d9).

[ At the end of the merge window I'll try to make sure that at 
  least one of them got upstream ;-) ]

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

Hi Ingo,

On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> Anyway - regardless of any differences and flames about workflow 
> details, both you and Catalin should still feel free to use both 
> the original commit (1cf00341547a) or the tip:sched/arch branch 
> I provided (01f23e1630d9).

About the scheduler hook patch, would it go into mainline via the
sched/urgent or the sched/arch branch? I would like to rebase the
ARM-specific patches on top of one of these branches and send you a pull
request (with Russell's ack).

Alternatively, I can wait until some 3.4-rc (and merge the ARM patches
via Russell).

Thanks.

-- 
Catalin

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Catalin Marinas <catalin.marinas@arm.com> wrote:

> Hi Ingo,
> 
> On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> > Anyway - regardless of any differences and flames about workflow 
> > details, both you and Catalin should still feel free to use both 
> > the original commit (1cf00341547a) or the tip:sched/arch branch 
> > I provided (01f23e1630d9).
> 
> About the scheduler hook patch, would it go into mainline via 
> the sched/urgent or the sched/arch branch? I would like to 
> rebase the ARM-specific patches on top of one of these 
> branches and send you a pull request (with Russell's ack).

I've merged it into sched/urgent yesterday, which I'll send to 
Linus - so you can base it on that.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

On Fri, Mar 30, 2012 at 03:25:44PM +0100, Ingo Molnar wrote:
> 
> * Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> > Hi Ingo,
> > 
> > On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> > > Anyway - regardless of any differences and flames about workflow 
> > > details, both you and Catalin should still feel free to use both 
> > > the original commit (1cf00341547a) or the tip:sched/arch branch 
> > > I provided (01f23e1630d9).
> > 
> > About the scheduler hook patch, would it go into mainline via 
> > the sched/urgent or the sched/arch branch? I would like to 
> > rebase the ARM-specific patches on top of one of these 
> > branches and send you a pull request (with Russell's ack).
> 
> I've merged it into sched/urgent yesterday, which I'll send to 
> Linus - so you can base it on that.

Thanks.

Russell, are you happy for me to add your acked-by to the ARM patches?

-- 
Catalin

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm tree got a conflict in:

  arch/arm/kernel/traps.c

between commit:

  04e91b732476 ("ARM: early traps initialisation")

from Linus' tree and commits:

  a1c510d0adc6 ("ARM: implement support for vmap'ed stacks")
  d31e23aff011 ("ARM: mm: make vmalloc_seq handling SMP safe")

from the arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/kernel/traps.c
index 5d58aee24087,2dec6944e5dd..000000000000
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@@ -878,5 -840,72 +893,72 @@@ void __init early_trap_init(void *vecto
  	 * memory area. The address is configurable and so a table in the kernel
  	 * image can be used.
  	 */
 -#endif
  }
 +#endif
+ 
+ #ifdef CONFIG_VMAP_STACK
+ 
+ DECLARE_PER_CPU(u8 *, irq_stack_ptr);
+ 
+ asmlinkage DEFINE_PER_CPU(u8 *, overflow_stack_ptr);
+ 
+ static int __init allocate_overflow_stacks(void)
+ {
+ 	u8 *stack;
+ 	int cpu;
+ 
+ 	for_each_possible_cpu(cpu) {
+ 		stack = (u8 *)__get_free_page(GFP_KERNEL);
+ 		if (WARN_ON(!stack))
+ 			return -ENOMEM;
+ 		per_cpu(overflow_stack_ptr, cpu) = &stack[OVERFLOW_STACK_SIZE];
+ 	}
+ 	return 0;
+ }
+ early_initcall(allocate_overflow_stacks);
+ 
+ asmlinkage void handle_bad_stack(struct pt_regs *regs)
+ {
+ 	unsigned long tsk_stk = (unsigned long)current->stack;
+ #ifdef CONFIG_IRQSTACKS
+ 	unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr);
+ #endif
+ 	unsigned long ovf_stk = (unsigned long)this_cpu_read(overflow_stack_ptr);
+ 
+ 	console_verbose();
+ 	pr_emerg("Insufficient stack space to handle exception!");
+ 
+ 	pr_emerg("Task stack:     [0x%08lx..0x%08lx]\n",
+ 		 tsk_stk, tsk_stk + THREAD_SIZE);
+ #ifdef CONFIG_IRQSTACKS
+ 	pr_emerg("IRQ stack:      [0x%08lx..0x%08lx]\n",
+ 		 irq_stk - THREAD_SIZE, irq_stk);
+ #endif
+ 	pr_emerg("Overflow stack: [0x%08lx..0x%08lx]\n",
+ 		 ovf_stk - OVERFLOW_STACK_SIZE, ovf_stk);
+ 
+ 	die("kernel stack overflow", regs, 0);
+ }
+ 
+ #ifndef CONFIG_ARM_LPAE
+ /*
+  * Normally, we rely on the logic in do_translation_fault() to update stale PMD
+  * entries covering the vmalloc space in a task's page tables when it first
+  * accesses the region in question. Unfortunately, this is not sufficient when
+  * the task stack resides in the vmalloc region, as do_translation_fault() is a
+  * C function that needs a stack to run.
+  *
+  * So we need to ensure that these PMD entries are up to date *before* the MM
+  * switch. As we already have some logic in the MM switch path that takes care
+  * of this, let's trigger it by bumping the counter every time the core vmalloc
+  * code modifies a PMD entry in the vmalloc region. Use release semantics on
+  * the store so that other CPUs observing the counter's new value are
+  * guaranteed to see the updated page table entries as well.
+  */
+ void arch_sync_kernel_mappings(unsigned long start, unsigned long end)
+ {
+ 	if (start < VMALLOC_END && end > VMALLOC_START)
+ 		atomic_inc_return_release(&init_mm.context.vmalloc_seq);
+ }
+ #endif
+ #endif

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ard Biesheuvel]

On Sat, 30 May 2020 at 11:17, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Sat, May 30, 2020 at 10:51:32AM +0200, Ard Biesheuvel wrote:
> > On Sat, 30 May 2020 at 10:41, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > Ard,
> > > > >
> > > > > Please take a look.  Obviously, whatever the resolution is going to be
> > > > > needed when Linus opens the merge window.
> > > > >
> > > >
> > > > Sorry for that.
> > > >
> > > > I have pushed the signed tag below to resolve it. Those changes were
> > > > already in v5.7-rc2, so I wouldn't expect this to cause more trouble.
> > > > If you prefer, you could merge v5.7-rc2 into your tree directly
> > > > instead.
> > >
> > > In light of Stephen's report of a different conflict on the 29th, I
> > > haven't pulled this.  I don't know if that's a side effect of this
> > > change having been picked up by -next or not.
> > >
> >
> > Fair enough. Both conflicts are unambiguous and self explanatory so I
> > don't think it should be a problem, right?
>
> I don't know - I don't have a resolution for the first one, Stephen
> didn't provide a 3-way diff with his report, and I was expecting a
> 3-way diff from you for it rather than another pull request.
>

That was not clear to me.

> I now also don't know whether the conflict on the 28th still exists
> or not.
>

Yes it does. That conflict is with v5.7-rc2, which exists because your
tree is based on v5.7-rc1, and so a fix that arrived in the mean time
is touching some of the lines that are being removed in v5.8.

That is why I mentioned that you could preempt this by merging
v5.7-rc2 into your tree as well.

> I'm completely confused, and I'm considering dropping the original
> EFI pull request on the grounds that the merge window opens tomorrow,
> and there isn't going to be another -next before that happens, so we
> don't know what's going to happen whatever action we take.
>

The other conflict is with the EFI changes queued up for v5.8 in the
-tip tree. The pr_efi_err() function was renamed to efi_err(), which
was used in a lot of places. This is slightly annoying, but rather
straightforward to resolve.

In any case, I am happy to go along with whatever you feel is best.

Re: linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

On Sat, 30 May 2020 10:17:47 +0100 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>
> I don't know - I don't have a resolution for the first one, Stephen
> didn't provide a 3-way diff with his report, and I was expecting a
> 3-way diff from you for it rather than another pull request.

There is no 3-way diff, because "I just used the latter" i.e. I used
the arm tree version of the conflicted section of the file.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King - ARM Linux admin]

On Sat, May 30, 2020 at 10:51:32AM +0200, Ard Biesheuvel wrote:
> On Sat, 30 May 2020 at 10:41, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > Ard,
> > > >
> > > > Please take a look.  Obviously, whatever the resolution is going to be
> > > > needed when Linus opens the merge window.
> > > >
> > >
> > > Sorry for that.
> > >
> > > I have pushed the signed tag below to resolve it. Those changes were
> > > already in v5.7-rc2, so I wouldn't expect this to cause more trouble.
> > > If you prefer, you could merge v5.7-rc2 into your tree directly
> > > instead.
> >
> > In light of Stephen's report of a different conflict on the 29th, I
> > haven't pulled this.  I don't know if that's a side effect of this
> > change having been picked up by -next or not.
> >
> 
> Fair enough. Both conflicts are unambiguous and self explanatory so I
> don't think it should be a problem, right?

I don't know - I don't have a resolution for the first one, Stephen
didn't provide a 3-way diff with his report, and I was expecting a
3-way diff from you for it rather than another pull request.

I now also don't know whether the conflict on the 28th still exists
or not.

I'm completely confused, and I'm considering dropping the original
EFI pull request on the grounds that the merge window opens tomorrow,
and there isn't going to be another -next before that happens, so we
don't know what's going to happen whatever action we take.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ard Biesheuvel]

On Sat, 30 May 2020 at 10:41, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> > On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > Ard,
> > >
> > > Please take a look.  Obviously, whatever the resolution is going to be
> > > needed when Linus opens the merge window.
> > >
> >
> > Sorry for that.
> >
> > I have pushed the signed tag below to resolve it. Those changes were
> > already in v5.7-rc2, so I wouldn't expect this to cause more trouble.
> > If you prefer, you could merge v5.7-rc2 into your tree directly
> > instead.
>
> In light of Stephen's report of a different conflict on the 29th, I
> haven't pulled this.  I don't know if that's a side effect of this
> change having been picked up by -next or not.
>

Fair enough. Both conflicts are unambiguous and self explanatory so I
don't think it should be a problem, right?

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King - ARM Linux admin]

On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > Ard,
> >
> > Please take a look.  Obviously, whatever the resolution is going to be
> > needed when Linus opens the merge window.
> >
> 
> Sorry for that.
> 
> I have pushed the signed tag below to resolve it. Those changes were
> already in v5.7-rc2, so I wouldn't expect this to cause more trouble.
> If you prefer, you could merge v5.7-rc2 into your tree directly
> instead.

In light of Stephen's report of a different conflict on the 29th, I
haven't pulled this.  I don't know if that's a side effect of this
change having been picked up by -next or not.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ard Biesheuvel]

On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Ard,
>
> Please take a look.  Obviously, whatever the resolution is going to be
> needed when Linus opens the merge window.
>

Sorry for that.

I have pushed the signed tag below to resolve it. Those changes were
already in v5.7-rc2, so I wouldn't expect this to cause more trouble.
If you prefer, you could merge v5.7-rc2 into your tree directly
instead.



The following changes since commit d0f9ca9be11f25ef4151195eab7ea36d136084f6:

  ARM: decompressor: run decompressor in place if loaded via UEFI
(2020-05-19 18:23:22 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git
efi-arm-resolve-conflict-v5.8-for-rmk

for you to fetch changes up to 5aa87eb1b4e3f1b50ee4a42e8cd933d3d39927b3:

  Merge commit 'a94691680bac' into efi-arm-no-relocate to resolve
conflict (2020-05-28 08:50:46 +0200)

----------------------------------------------------------------
Resolve a merge conflict between v5.7-rc2 and rmk/for-next

----------------------------------------------------------------

Ard Biesheuvel (2):
      efi/arm: Deal with ADR going out of range in efi_enter_kernel()
      Merge commit 'a94691680bac' into efi-arm-no-relocate to resolve conflict

Arvind Sankar (2):
      efi/x86: Move efi stub globals from .bss to .data
      efi/x86: Always relocate the kernel for EFI handover entry

Colin Ian King (1):
      efi/libstub/x86: Remove redundant assignment to pointer hdr

Takashi Iwai (1):
      efi/cper: Use scnprintf() for avoiding potential buffer overflow


 drivers/firmware/efi/cper.c             |  2 +-
 drivers/firmware/efi/libstub/efistub.h  |  2 +-
 drivers/firmware/efi/libstub/x86-stub.c | 18 +++++++++++-------
 3 files changed, 13 insertions(+), 9 deletions(-)

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King - ARM Linux admin]

Ard,

Please take a look.  Obviously, whatever the resolution is going to be
needed when Linus opens the merge window.

Thanks.

On Thu, May 28, 2020 at 09:09:41AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm tree got a conflict in:
> 
>   arch/arm/boot/compressed/head.S
> 
> between commit:
> 
>   a94691680bac ("efi/arm: Deal with ADR going out of range in efi_enter_kernel()")
> 
> from Linus' tree and commit:
> 
>   d0f9ca9be11f ("ARM: decompressor: run decompressor in place if loaded via UEFI")
> 
> from the arm tree.
> 
> I fixed it up (I just used the latter) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm tree got a conflict in:

  arch/arm/boot/compressed/head.S

between commit:

  a94691680bac ("efi/arm: Deal with ADR going out of range in efi_enter_kernel()")

from Linus' tree and commit:

  d0f9ca9be11f ("ARM: decompressor: run decompressor in place if loaded via UEFI")

from the arm tree.

I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Wed, Jun 01, 2016 at 10:07:46AM +1000, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That wasn't intentional - I guess the "component" branch got included
in for-next when I rebuilt that branch.

The conflict has been around for a while (it's a conflict between code
merged during the merge window, and my changes) and it will get cleaned
up when I rebase my development onto -rc1.

Thanks anyway.

-- 
Russell King
ARM architecture Linux Kernel maintainer

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in:

  drivers/gpu/drm/rockchip/rockchip_drm_drv.c

between commit:

  2d90d477430d ("drm/rockchip: support non-iommu buffer path")

from Linus' tree and commit:

  ac09e446377a ("drm: convert DT component matching to component_match_add_release()")

from the arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a409d1f703cb,8168810053b3..000000000000
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@@ -507,18 -502,9 +512,20 @@@ static int rockchip_drm_platform_probe(
  			continue;
  		}
  
 +		iommu = of_parse_phandle(port->parent, "iommus", 0);
 +		if (!iommu || !of_device_is_available(iommu->parent)) {
 +			dev_dbg(dev, "no iommu attached for %s, using non-iommu buffers\n",
 +				port->parent->full_name);
 +			/*
 +			 * if there is a crtc not support iommu, force set all
 +			 * crtc use non-iommu buffer.
 +			 */
 +			is_support_iommu = false;
 +		}
 +
- 		component_match_add(dev, &match, compare_of, port->parent);
+ 		of_node_get(port->parent);
+ 		component_match_add_release(dev, &match, release_of,
+ 					    compare_of, port->parent);
  		of_node_put(port);
  	}
  

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got conflicts in
arch/arm/mach-integrator/core.c and arch/arm/mach-integrator/pci.c
between commit 9f97da78bf01 ("Disintegrate asm/system.h for ARM") from
Linus' tree and commit 695436e3738e ("ARM: 7349/1: integrator: convert to
sparse irqs") from the arm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-integrator/core.c
index 1a65d77,304dfb2..0000000
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@@ -25,8 -25,10 +25,9 @@@
  
  #include <mach/hardware.h>
  #include <mach/platform.h>
- #include <asm/irq.h>
  #include <mach/cm.h>
+ #include <mach/irqs.h>
+ 
 -#include <asm/system.h>
  #include <asm/leds.h>
  #include <asm/mach-types.h>
  #include <asm/mach/time.h>
diff --cc arch/arm/mach-integrator/pci.c
index 36068f4,e15aa43..0000000
--- a/arch/arm/mach-integrator/pci.c
+++ b/arch/arm/mach-integrator/pci.c
@@@ -26,7 -26,7 +26,6 @@@
  #include <linux/interrupt.h>
  #include <linux/init.h>
  
- #include <asm/irq.h>
 -#include <asm/system.h>
  #include <asm/mach/pci.h>
  #include <asm/mach-types.h>
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/kernel/process.c between commit 909af768e888 ("coredump: remove
VM_ALWAYSDUMP flag") from the  tree and commit e19d478e808e ("ARM:
7294/1: vectors: use gate_vma for vectors user mapping") from the arm
tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/kernel/process.c
index d3eca45,1531480..0000000
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@@ -529,17 -531,36 +529,35 @@@ unsigned long arch_randomize_brk(struc
  #ifdef CONFIG_MMU
  /*
   * The vectors page is always readable from user space for the
-  * atomic helpers and the signal restart code.  Let's declare a mapping
-  * for it so it is visible through ptrace and /proc/<pid>/mem.
+  * atomic helpers and the signal restart code. Insert it into the
+  * gate_vma so that it is visible through ptrace and /proc/<pid>/mem.
   */
+ static struct vm_area_struct gate_vma;
  
- int vectors_user_mapping(void)
+ static int __init gate_vma_init(void)
  {
- 	struct mm_struct *mm = current->mm;
- 	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
- 				       VM_READ | VM_EXEC |
- 				       VM_MAYREAD | VM_MAYEXEC | VM_RESERVED,
- 				       NULL);
+ 	gate_vma.vm_start	= 0xffff0000;
+ 	gate_vma.vm_end		= 0xffff0000 + PAGE_SIZE;
+ 	gate_vma.vm_page_prot	= PAGE_READONLY_EXEC;
+ 	gate_vma.vm_flags	= VM_READ | VM_EXEC |
 -				  VM_MAYREAD | VM_MAYEXEC |
 -				  VM_ALWAYSDUMP;
++				  VM_MAYREAD | VM_MAYEXEC;
+ 	return 0;
+ }
+ arch_initcall(gate_vma_init);
+ 
+ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
+ {
+ 	return &gate_vma;
+ }
+ 
+ int in_gate_area(struct mm_struct *mm, unsigned long addr)
+ {
+ 	return (addr >= gate_vma.vm_start) && (addr < gate_vma.vm_end);
+ }
+ 
+ int in_gate_area_no_mm(unsigned long addr)
+ {
+ 	return in_gate_area(NULL, addr);
  }
  
  const char *arch_vma_name(struct vm_area_struct *vma)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-at91/at91cap9.c arch/arm/mach-at91/at91sam9g45.c between
commit 14f991a730f4 ("ARM: at91: Fix at91sam9g45 and at91cap9 reset")
from Linus' tree and commit c9dfafbaca0b ("ARM: mach-at91: move special
idle code out of line") from the arm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-at91/at91cap9.c
index a42edc2,1d29a6c..0000000
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
@@@ -313,6 -315,17 +314,12 @@@ static struct at91_gpio_bank at91cap9_g
  	}
  };
  
+ static void at91cap9_idle(void)
+ {
+ 	at91_sys_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+ 	cpu_do_idle();
+ }
+ 
 -static void at91cap9_restart(char mode, const char *cmd)
 -{
 -	at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
 -}
 -
  /* --------------------------------------------------------------------
   *  AT91CAP9 processor initialization
   * -------------------------------------------------------------------- */
@@@ -332,7 -344,8 +339,8 @@@ static void __init at91cap9_ioremap_reg
  
  static void __init at91cap9_initialize(void)
  {
+ 	arm_pm_idle = at91cap9_idle;
 -	arm_pm_restart = at91cap9_restart;
 +	arm_pm_restart = at91sam9g45_restart;
  	at91_extern_irq = (1 << AT91CAP9_ID_IRQ0) | (1 << AT91CAP9_ID_IRQ1);
  
  	/* Register GPIO subsystem */
diff --cc arch/arm/mach-at91/at91sam9g45.c
index 1cb6a96,0e80b39..0000000
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@@ -317,6 -318,17 +317,12 @@@ static struct at91_gpio_bank at91sam9g4
  	}
  };
  
+ static void at91sam9g45_idle(void)
+ {
+ 	at91_sys_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+ 	cpu_do_idle();
+ }
+ 
 -static void at91sam9g45_restart(char mode, const char *cmd)
 -{
 -	at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
 -}
 -
  /* --------------------------------------------------------------------
   *  AT91SAM9G45 processor initialization
   * -------------------------------------------------------------------- */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-exynos/common.c between commit 7affca3537d7 ("Merge branch
'driver-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") from
Linus' tree and commit 53aa9b6a12dd ("ARM: mach-exynos: use standard
arch_idle()") from the arm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-exynos/common.c
index b6ac6ee,8484019..0000000
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@@ -468,10 -459,7 +460,7 @@@ int __init exynos_init(void
  {
  	printk(KERN_INFO "EXYNOS: Initializing architecture\n");
  
- 	/* set idle function */
- 	pm_idle = exynos_idle;
- 
 -	return sysdev_register(&exynos4_sysdev);
 +	return device_register(&exynos4_dev);
  }
  
  static struct s3c24xx_uart_clksrc exynos4_serial_clocks[] = {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-s5pc100/common.c between commit 7affca3537d7 ("Merge branch
'driver-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") from
Linus' tree and commit 109ac862f737 ("ARM: mach-s5pc100: use standard
arch_idle()") from the arm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-s5pc100/common.c
index c909573,4659fb9..0000000
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@@ -210,11 -201,7 +202,7 @@@ core_initcall(s5pc100_core_init)
  int __init s5pc100_init(void)
  {
  	printk(KERN_INFO "S5PC100: Initializing architecture\n");
- 
- 	/* set idle function */
- 	pm_idle = s5pc100_idle;
- 
 -	return sysdev_register(&s5pc100_sysdev);
 +	return device_register(&s5pc100_dev);
  }
  
  /* uart registration process */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-s5pv210/common.c between commit 7affca3537d7 ("Merge branch
'driver-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") from
Linus' tree and commit 58329cb3171f ("ARM: mach-s5pv210: use standard
arch_idle()") from the arm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-s5pv210/common.c
index 0ec3933,2622b8a..0000000
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@@ -247,11 -238,7 +239,7 @@@ core_initcall(s5pv210_core_init)
  int __init s5pv210_init(void)
  {
  	printk(KERN_INFO "S5PV210: Initializing architecture\n");
- 
- 	/* set idle function */
- 	pm_idle = s5pv210_idle;
- 
 -	return sysdev_register(&s5pv210_sysdev);
 +	return device_register(&s5pv210_dev);
  }
  
  static struct s3c24xx_uart_clksrc s5pv210_serial_clocks[] = {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-shmobile/board-kota2.c between commit 1b6cec8a6910 ("ARM:
mach-shmobile: Kota2 PINT fix") from Linus' tree and commit a83d8e27d2f6
("ARM: shmobile: convert smp platforms to gic_handle_irq()") from the arm
tree.

Just context changes.  I fixed it up (see below) and can carry the change
as necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-shmobile/board-kota2.c
index f44150b,1b4439d..0000000
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@@ -549,9 -447,8 +549,9 @@@ struct sys_timer kota2_timer = 
  
  MACHINE_START(KOTA2, "kota2")
  	.map_io		= kota2_map_io,
 -	.init_irq	= kota2_init_irq,
 +	.nr_irqs	= NR_IRQS_LEGACY,
 +	.init_irq	= sh73a0_init_irq,
- 	.handle_irq	= shmobile_handle_irq_gic,
+ 	.handle_irq	= gic_handle_irq,
  	.init_machine	= kota2_init,
  	.timer		= &kota2_timer,
  MACHINE_END

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Linus Walleij]

On Wed, Sep 21, 2011 at 2:33 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the arm tree got a conflict in
> arch/arm/mach-integrator/integrator_ap.c between commit b71d8429ec36
> ("mach-integrator: fix VGA base regression") from Linus' tree and commit
> b79573586838 ("ARM: 7087/2: mach-integrator: get timer frequency from
> clock") from the arm tree.
>
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

The fix is correct, thanks Stephen.

Yours,
Linus Walleij

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-integrator/integrator_ap.c between commit b71d8429ec36
("mach-integrator: fix VGA base regression") from Linus' tree and commit
b79573586838 ("ARM: 7087/2: mach-integrator: get timer frequency from
clock") from the arm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-integrator/integrator_ap.c
index 8cdc730,c698811..0000000
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@@ -32,7 -32,7 +32,8 @@@
  #include <linux/interrupt.h>
  #include <linux/io.h>
  #include <linux/mtd/physmap.h>
+ #include <linux/clk.h>
 +#include <video/vga.h>
  
  #include <mach/hardware.h>
  #include <mach/platform.h>

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/configs/lusl7200_defconfig between commit
07a8c03f3e06129e847acd068b8b89c13357ee64 ("ARM: reduce defconfigs") from
Linus' tree and commit c9c6fe5033191d82e1d819105485c795062107fd ("ARM:
Remove support for LinkUp Systems L7200 SDP") from the arm tree.

The latter removes the file, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Eric Miao]

On Thu, Mar 4, 2010 at 7:49 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Russell,
>
> Today's linux-next merge of the arm tree got a conflict in
> sound/soc/pxa/pxa-ssp.c between commit
> 026384d614b827f368834860c9b623ce08439b7e ("ASoC: fix PXA SSP port
> resume") from Linus' tree and commit
> f9efc9df94fd126f7d585339e64edec0c03e904b ("ASoC: Remove legacy SSP API
> usage from pxa-ssp.c") from the arm tree.
>
> I fixed it up (see below - it should be checked) and can carry the fix as
> necessary.

Hi Stephen,

I've yet made another fix and have a test build, please use this
one if possible:

diff --cc sound/soc/pxa/pxa-ssp.c
index e69397f,cf00df9..9e95e51
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@@ -133,28 -152,39 +152,40 @@@ static void pxa_ssp_shutdown(struct snd
  static int pxa_ssp_suspend(struct snd_soc_dai *cpu_dai)
  {
  	struct ssp_priv *priv = cpu_dai->private_data;
+ 	struct ssp_device *ssp = priv->ssp;

  	if (!cpu_dai->active)
- 		clk_enable(priv->dev.ssp->clk);
 -		return 0;
++		clk_enable(ssp->clk);

- 	ssp_save_state(&priv->dev, &priv->state);
- 	clk_disable(priv->dev.ssp->clk);
+ 	priv->cr0 = __raw_readl(ssp->mmio_base + SSCR0);
+ 	priv->cr1 = __raw_readl(ssp->mmio_base + SSCR1);
+ 	priv->to  = __raw_readl(ssp->mmio_base + SSTO);
+ 	priv->psp = __raw_readl(ssp->mmio_base + SSPSP);

+ 	ssp_disable(ssp);
+ 	clk_disable(ssp->clk);
  	return 0;
  }

  static int pxa_ssp_resume(struct snd_soc_dai *cpu_dai)
  {
  	struct ssp_priv *priv = cpu_dai->private_data;
+ 	struct ssp_device *ssp = priv->ssp;
+ 	uint32_t sssr = SSSR_ROR | SSSR_TUR | SSSR_BCE;
+
 -	if (!cpu_dai->active)
 -		return 0;
 -
+ 	clk_enable(ssp->clk);

- 	clk_enable(priv->dev.ssp->clk);
- 	ssp_restore_state(&priv->dev, &priv->state);
+ 	__raw_writel(sssr, ssp->mmio_base + SSSR);
 -
+ 	__raw_writel(priv->cr0 & ~SSCR0_SSE, ssp->mmio_base + SSCR0);
+ 	__raw_writel(priv->cr1, ssp->mmio_base + SSCR1);
+ 	__raw_writel(priv->to,  ssp->mmio_base + SSTO);
+ 	__raw_writel(priv->psp, ssp->mmio_base + SSPSP);
 -	__raw_writel(priv->cr0 | SSCR0_SSE, ssp->mmio_base + SSCR0);
 +
 +	if (cpu_dai->active)
- 		ssp_enable(&priv->dev);
++		ssp_enable(ssp);
 +	else
- 		clk_disable(priv->dev.ssp->clk);
++		clk_disable(ssp->clk);
 +
  	return 0;
  }

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
sound/soc/pxa/pxa-ssp.c between commit
026384d614b827f368834860c9b623ce08439b7e ("ASoC: fix PXA SSP port
resume") from Linus' tree and commit
f9efc9df94fd126f7d585339e64edec0c03e904b ("ASoC: Remove legacy SSP API
usage from pxa-ssp.c") from the arm tree.

I fixed it up (see below - it should be checked) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc sound/soc/pxa/pxa-ssp.c
index e69397f,cf00df9..0000000
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@@ -133,28 -152,39 +152,41 @@@ static void pxa_ssp_shutdown(struct snd
  static int pxa_ssp_suspend(struct snd_soc_dai *cpu_dai)
  {
  	struct ssp_priv *priv = cpu_dai->private_data;
+ 	struct ssp_device *ssp = priv->ssp;
  
  	if (!cpu_dai->active)
 -		return 0;
 +		clk_enable(priv->dev.ssp->clk);
  
- 	ssp_save_state(&priv->dev, &priv->state);
- 	clk_disable(priv->dev.ssp->clk);
+ 	priv->cr0 = __raw_readl(ssp->mmio_base + SSCR0);
+ 	priv->cr1 = __raw_readl(ssp->mmio_base + SSCR1);
+ 	priv->to  = __raw_readl(ssp->mmio_base + SSTO);
+ 	priv->psp = __raw_readl(ssp->mmio_base + SSPSP);
+ 
+ 	ssp_disable(ssp);
+ 	clk_disable(ssp->clk);
 +
  	return 0;
  }
  
  static int pxa_ssp_resume(struct snd_soc_dai *cpu_dai)
  {
  	struct ssp_priv *priv = cpu_dai->private_data;
+ 	struct ssp_device *ssp = priv->ssp;
+ 	uint32_t sssr = SSSR_ROR | SSSR_TUR | SSSR_BCE;
  
- 	clk_enable(priv->dev.ssp->clk);
- 	ssp_restore_state(&priv->dev, &priv->state);
 -	if (!cpu_dai->active)
 -		return 0;
 -
+ 	clk_enable(ssp->clk);
  
- 	if (cpu_dai->active)
- 		ssp_enable(&priv->dev);
- 	else
- 		clk_disable(priv->dev.ssp->clk);
 -	__raw_writel(sssr, ssp->mmio_base + SSSR);
++	if (cpu_dai->active) {
++		__raw_writel(sssr, ssp->mmio_base + SSSR);
++
++		__raw_writel(priv->cr0 & ~SSCR0_SSE, ssp->mmio_base + SSCR0);
++		__raw_writel(priv->cr1, ssp->mmio_base + SSCR1);
++		__raw_writel(priv->to,  ssp->mmio_base + SSTO);
++		__raw_writel(priv->psp, ssp->mmio_base + SSPSP);
++		__raw_writel(priv->cr0 | SSCR0_SSE, ssp->mmio_base + SSCR0);
++	} else
++		clk_disable(ssp->clk);
  
 -	__raw_writel(priv->cr0 & ~SSCR0_SSE, ssp->mmio_base + SSCR0);
 -	__raw_writel(priv->cr1, ssp->mmio_base + SSCR1);
 -	__raw_writel(priv->to,  ssp->mmio_base + SSTO);
 -	__raw_writel(priv->psp, ssp->mmio_base + SSPSP);
 -	__raw_writel(priv->cr0 | SSCR0_SSE, ssp->mmio_base + SSCR0);
  	return 0;
  }
  

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

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

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
arch/arm/mach-mx25/clock.c between commit
ac0f6f927db539e03e1f3f61bcd4ed57d5cde7a9 ("Merge branch 'for-linus' of
master.kernel.org:/home/rmk/linux-2.6-arm") from Linus' tree (this looks
like the same merge ed1e01c8cf4772aabe013716353a7a0f879dbf5e ("Merge
branch 'master' into versatile") that is in the arm tree) and commit
04a03e5fe3d337242e5c0a9c93d2fd24cff545ef ("mx25: add platform support for
imxfb") from the arm tree.

I fixed it up (using the arm tree version) an can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: linux-next: manual merge of the arm tree with Linus' tree

[H Hartley Sweeten]

On Thursday, July 30, 2009 5:34 PM, Stephen Rothwell wrote:
> Hi Russell,
> 
> Today's linux-next merge of the arm tree got a conflict in MAINTAINERS
> between commit 8b58be884a9fd650abb7f7adf3f885fb9cecd79d ("MAINTAINERS:
> coalesce name and email address lines") from Linus' tree and commit
> d19d36672ee379f26b79df985a9a2e5afb3f1df1 ("[ARM] 5599/1: MAINTAINERS:
> update for EP93XX ARM") from the arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Russell,

Stephen's fix below is fine with me.  If needed I will resubmit this patch.

Regards,
Hartley

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc MAINTAINERS
> index 79471ba,1be6a0c..0000000
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -535,12 -604,18 +535,15 @@@ W:	http://maxim.org.za/at91_26.htm
>   S:	Maintained
>   
>   ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
> - M:	Lennert Buytenhek <kernel@wantstofly.org>
>  -P:	Hartley Sweeten
>  -M:	hsweeten@visionengravers.com
>  -P:	Ryan Mallon
>  -M:	ryan@bluewatersys.com
> ++M:	Hartley Sweeten <hsweeten@visionengravers.com>
> ++M:	Ryan Mallon <ryan@bluewatersys.com>
>   L:	linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
>   S:	Maintained
> + F:	arch/arm/mach-ep93xx/
> + F:	arch/arm/mach-ep93xx/include/mach/
>   
>   ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
>  -P:	Lennert Buytenhek
>  -M:	kernel@wantstofly.org
>  +M:	Lennert Buytenhek <kernel@wantstofly.org>
>   L:	linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
>   S:	Maintained
  

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in MAINTAINERS
between commit 8b58be884a9fd650abb7f7adf3f885fb9cecd79d ("MAINTAINERS:
coalesce name and email address lines") from Linus' tree and commit
d19d36672ee379f26b79df985a9a2e5afb3f1df1 ("[ARM] 5599/1: MAINTAINERS:
update for EP93XX ARM") from the arm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc MAINTAINERS
index 79471ba,1be6a0c..0000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -535,12 -604,18 +535,15 @@@ W:	http://maxim.org.za/at91_26.htm
  S:	Maintained
  
  ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
- M:	Lennert Buytenhek <kernel@wantstofly.org>
 -P:	Hartley Sweeten
 -M:	hsweeten@visionengravers.com
 -P:	Ryan Mallon
 -M:	ryan@bluewatersys.com
++M:	Hartley Sweeten <hsweeten@visionengravers.com>
++M:	Ryan Mallon <ryan@bluewatersys.com>
  L:	linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
  S:	Maintained
+ F:	arch/arm/mach-ep93xx/
+ F:	arch/arm/mach-ep93xx/include/mach/
  
  ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
 -P:	Lennert Buytenhek
 -M:	kernel@wantstofly.org
 +M:	Lennert Buytenhek <kernel@wantstofly.org>
  L:	linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
  S:	Maintained