RMK closing tree to patches *this* weekend

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

As of the end of this coming weekend, I'll stop taking patches for the
next merge window.  I want to tidy up the lose ends which need sorting
out and give it a decent outing in linux-next for about a week before
the merge window opens.

So if there's any patches I've missed, please follow up to this email.

RMK closing tree to patches *this* weekend

[Ben Dooks]

On Fri, May 14, 2010 at 12:02:01AM +0100, Russell King - ARM Linux wrote:
> As of the end of this coming weekend, I'll stop taking patches for the
> next merge window.  I want to tidy up the lose ends which need sorting
> out and give it a decent outing in linux-next for about a week before
> the merge window opens.
> 
> So if there's any patches I've missed, please follow up to this email.

If no-one objects, I'll send pull requests for the s3c24xx-gpio and the
s3c2416-core to the list, i'd just send the 2416, but it may have some
dependency on the gpio updates for 24xx.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Fri, May 14, 2010 at 01:35:12AM +0100, Ben Dooks wrote:
> On Fri, May 14, 2010 at 12:02:01AM +0100, Russell King - ARM Linux wrote:
> > As of the end of this coming weekend, I'll stop taking patches for the
> > next merge window.  I want to tidy up the lose ends which need sorting
> > out and give it a decent outing in linux-next for about a week before
> > the merge window opens.
> > 
> > So if there's any patches I've missed, please follow up to this email.
> 
> If no-one objects, I'll send pull requests for the s3c24xx-gpio and the
> s3c2416-core to the list, i'd just send the 2416, but it may have some
> dependency on the gpio updates for 24xx.

git pulls are going to be independent (I hope) for a little while longer.

RMK closing tree to patches *this* weekend

[Jassi Brar]

On Fri, May 14, 2010 at 8:02 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> As of the end of this coming weekend, I'll stop taking patches for the
> next merge window. ?I want to tidy up the lose ends which need sorting
> out and give it a decent outing in linux-next for about a week before
> the merge window opens.
>
> So if there's any patches I've missed, please follow up to this email.
Hi Russell,

Would it be possible for you to merge the PL330 core driver in your tree?
If so, I would make sure the platform specific stuff get up via Ben Dooks'
tree in time.

Getting PL330 DMAC support is really important for latest Samsung SoCs
i.e, S5PV210, S5P6442, S5P6440 and S5PC100
that have Audio and SPI not working mostly due to lack of DMA support.

Thanks.

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Fri, May 14, 2010 at 09:58:01AM +0900, Jassi Brar wrote:
> On Fri, May 14, 2010 at 8:02 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > As of the end of this coming weekend, I'll stop taking patches for the
> > next merge window. ?I want to tidy up the lose ends which need sorting
> > out and give it a decent outing in linux-next for about a week before
> > the merge window opens.
> >
> > So if there's any patches I've missed, please follow up to this email.
> Hi Russell,
> 
> Would it be possible for you to merge the PL330 core driver in your tree?
> If so, I would make sure the platform specific stuff get up via Ben Dooks'
> tree in time.

I looked at doing that, but it conflicts in arch/arm/common/Kconfig:

patching file arch/arm/common/Kconfig
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/common/Kconfig.rej

I think this is another place where having things sorted alphabetically
would help, rather than appending things to the end.  That said, because
of the changes in the versatile branch, its going to cause merge conflicts
(which are easier to deal with than a patch which won't apply.)

Could you move the PL330 option to between ICST307 and SA1111 please?

RMK closing tree to patches *this* weekend

[Jassi Brar]

On Fri, May 14, 2010 at 6:24 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, May 14, 2010 at 09:58:01AM +0900, Jassi Brar wrote:
>> On Fri, May 14, 2010 at 8:02 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > As of the end of this coming weekend, I'll stop taking patches for the
>> > next merge window. ?I want to tidy up the lose ends which need sorting
>> > out and give it a decent outing in linux-next for about a week before
>> > the merge window opens.
>> >
>> > So if there's any patches I've missed, please follow up to this email.
>> Hi Russell,
>>
>> Would it be possible for you to merge the PL330 core driver in your tree?
>> If so, I would make sure the platform specific stuff get up via Ben Dooks'
>> tree in time.
>
> I looked at doing that, but it conflicts in arch/arm/common/Kconfig:
>
> patching file arch/arm/common/Kconfig
> Hunk #1 FAILED at 40.
> 1 out of 1 hunk FAILED -- saving rejects to file arch/arm/common/Kconfig.rej
>
> I think this is another place where having things sorted alphabetically
> would help, rather than appending things to the end. ?That said, because
> of the changes in the versatile branch, its going to cause merge conflicts
> (which are easier to deal with than a patch which won't apply.)
>
> Could you move the PL330 option to between ICST307 and SA1111 please?
I just moved Kconfig and Makefile entries for that and submitted again
as [6132/1]
thanks

RMK closing tree to patches *this* weekend

[Ming Lei]

2010/5/14 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> As of the end of this coming weekend, I'll stop taking patches for the
> next merge window. ?I want to tidy up the lose ends which need sorting
> out and give it a decent outing in linux-next for about a week before
> the merge window opens.
>
> So if there's any patches I've missed, please follow up to this email.

If possible, please take the patch:

           [PATCH] ARM: fix 'unannotated irqs-on' lockdep warning

which not only fixes the warning and make lockdep available,
but also is more efficient than before if lockdep is enabled:

          - remove one calling for asm_trace_hardirqs_on before returning
to user-space
          - convert asm_trace_hardirqs_on to trace_hardirqs_on in the
path of returning to kernel space from exception and only call it if
harirqs will be enabled before returning.


Thanks,
-- 
Lei Ming

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Fri, May 14, 2010 at 12:02:01AM +0100, Russell King - ARM Linux wrote:
> As of the end of this coming weekend, I'll stop taking patches for the
> next merge window.  I want to tidy up the lose ends which need sorting
> out and give it a decent outing in linux-next for about a week before
> the merge window opens.
> 
> So if there's any patches I've missed, please follow up to this email.

I know there was someone who was complaining a week or so ago that I
hadn't applied their patch, which was only sent to the mailing list.
Unfortunately, it being only on the mailing list and not in the patch
system means I can't find it, nor the complaint about it not being
applied.

Whoever it was, sorry.

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Fri, May 14, 2010 at 12:02:01AM +0100, Russell King - ARM Linux wrote:
> As of the end of this coming weekend, I'll stop taking patches for the
> next merge window.  I want to tidy up the lose ends which need sorting
> out and give it a decent outing in linux-next for about a week before
> the merge window opens.

So 2.6.34 has happened, so much for having a week for things to settle
down.

Right, my tree is now frozen for new patches; I won't be taking any
more patches into the devel side from the patch system, and I won't
be pulling any further trees into my tree either.

I'm waiting for two additional patches which go on top of everything
that's been merged so far (which have dependencies on previously merged
stuff), and then I'll push out the final version.

RMK closing tree to patches *this* weekend

[Nicolas Pitre]

On Mon, 17 May 2010, Russell King - ARM Linux wrote:

> Right, my tree is now frozen for new patches; I won't be taking any
> more patches into the devel side from the patch system, and I won't
> be pulling any further trees into my tree either.

For the record, I sent you an initial pull request on May 3rd, and a 
ping on May 14th.  I still don't see it in your tree.  I don't mind not 
seeing it in your tree for your initial batch to Linus as long as I know 
you'll accept it sometimes for this merge window.


Nicolas

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Mon, May 17, 2010 at 09:04:53AM -0400, Nicolas Pitre wrote:
> On Mon, 17 May 2010, Russell King - ARM Linux wrote:
> 
> > Right, my tree is now frozen for new patches; I won't be taking any
> > more patches into the devel side from the patch system, and I won't
> > be pulling any further trees into my tree either.
> 
> For the record, I sent you an initial pull request on May 3rd, and a 
> ping on May 14th.

It got pulled on the 14th.

> I still don't see it in your tree.

As is my standard procedure, it's pulled into devel-stable and if you
look there, you'll see it.  devel-stable has been dropped from the main
devel branch while I wait for Hartley to produce his patch (which is
dependent on everything else in the devel branch.)

Once that's in, I'll be re-merging devel-stable back into devel, and
then applying a patch from John Schultz removing all the now redundant
'select GENERIC_TIME' statements.

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Mon, May 17, 2010 at 09:04:53AM -0400, Nicolas Pitre wrote:
> I don't mind not seeing it in your tree for your initial batch to
> Linus as long as I know you'll accept it sometimes for this merge window.

The other thing to point out is that the merge windows are now much
more unpredictable.

The last merge window was 12 days long, rather than the usual 14.  With
Linus' statement about the two week window being too predictable, I would
not be surprised if this merge window was about 7 days instead.

What this means overall is that it becomes much harder to sanely plan
stuff either for the lead up to the merge window, or during the merge
window itself.

Therefore, this "initial batch" is most likely to become "only batch"
since it's no longer possible to be reasonably ensure that there will
be a merge window open in the second week.

RMK closing tree to patches *this* weekend

[Will Deacon]

Hi Russell,

> Therefore, this "initial batch" is most likely to become "only batch"
> since it's no longer possible to be reasonably ensure that there will
> be a merge window open in the second week.

If this is likely to be the case, will the OProfile patches be merged
during this batch? The reason I ask is because they have been applied to
the `devel-pmu' branch, but I can't find this in your repository. I also
can't see the patches in any of your other branches.

Knowing when the Kernel patches will be going in helps me to co-ordinate
submission of the accompanying userspace patches.

Thanks,

Will

RMK closing tree to patches *this* weekend

[Russell King - ARM Linux]

On Mon, May 17, 2010 at 04:44:20PM +0100, Will Deacon wrote:
> Hi Russell,
> 
> > Therefore, this "initial batch" is most likely to become "only batch"
> > since it's no longer possible to be reasonably ensure that there will
> > be a merge window open in the second week.
> 
> If this is likely to be the case, will the OProfile patches be merged
> during this batch? The reason I ask is because they have been applied to
> the `devel-pmu' branch, but I can't find this in your repository. I also
> can't see the patches in any of your other branches.
> 
> Knowing when the Kernel patches will be going in helps me to co-ordinate
> submission of the accompanying userspace patches.

As I've already pointed out:

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

As I've said repeatedly over the last few weeks, there's three patch
"series" which depend on lots of other stuff in the tree, and merging
it out of order will result in build breakage or stuff being missed.
These are:

1. Hartley's removal of 'select GENERIC_GPIO'
2. Your PMU patches
3. John Stultz removal of 'select GENERIC_TIME'

I'm waiting for (1) at the moment, then I'll re-merge (2) and devel-stable,
and then I can ask John to redo his patch - which will depend on
everything in my tree - it will touch stuff which only exists in both
the existing 'devel' and 'devel-stable' branches.

This is why I really wanted to close my tree a week before the merge
window - to give a reasonable time to get these patches sorted out and
properly tested.  We don't have that choice now - instead, what we have
is a panic to get this all sorted.  So we'll all do the testing of the
result after it's in Linus tree.

Now, should Hartley for whatever reason not be able to sort his patch out
by tomorrow morning (my time), I shall be taking the view that the patch
is not important, and we can play this lottery again for the following
merge window...