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

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

[Stephen Rothwell]

Hi David,

Today's linux-next merge of the msm tree got conflicts in
arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
initializers and assembly using PHYS_OFFSET") from the arm tree and
commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
ifdefs") from the msm 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-msm/board-msm7x27.c
index 08fcd40,16d7580..0000000
--- a/arch/arm/mach-msm/board-msm7x27.c
+++ b/arch/arm/mach-msm/board-msm7x27.c
@@@ -130,9 -130,7 +130,7 @@@ static void __init msm7x2x_map_io(void
  }
  
  MACHINE_START(MSM7X27_SURF, "QCT MSM7x27 SURF")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params	= PHYS_OFFSET + 0x100,
 +	.boot_params	= PLAT_PHYS_OFFSET + 0x100,
  	.map_io		= msm7x2x_map_io,
  	.init_irq	= msm7x2x_init_irq,
  	.init_machine	= msm7x2x_init,
@@@ -140,9 -138,7 +138,7 @@@
  MACHINE_END
  
  MACHINE_START(MSM7X27_FFA, "QCT MSM7x27 FFA")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params	= PHYS_OFFSET + 0x100,
 +	.boot_params	= PLAT_PHYS_OFFSET + 0x100,
  	.map_io		= msm7x2x_map_io,
  	.init_irq	= msm7x2x_init_irq,
  	.init_machine	= msm7x2x_init,
@@@ -150,9 -146,7 +146,7 @@@
  MACHINE_END
  
  MACHINE_START(MSM7X25_SURF, "QCT MSM7x25 SURF")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params	= PHYS_OFFSET + 0x100,
 +	.boot_params	= PLAT_PHYS_OFFSET + 0x100,
  	.map_io		= msm7x2x_map_io,
  	.init_irq	= msm7x2x_init_irq,
  	.init_machine	= msm7x2x_init,
@@@ -160,9 -154,7 +154,7 @@@
  MACHINE_END
  
  MACHINE_START(MSM7X25_FFA, "QCT MSM7x25 FFA")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params	= PHYS_OFFSET + 0x100,
 +	.boot_params	= PLAT_PHYS_OFFSET + 0x100,
  	.map_io		= msm7x2x_map_io,
  	.init_irq	= msm7x2x_init_irq,
  	.init_machine	= msm7x2x_init,
diff --cc arch/arm/mach-msm/board-msm7x30.c
index 25db8fd,dc9fac1..0000000
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@@ -83,9 -105,7 +105,7 @@@ static void __init msm7x30_map_io(void
  }
  
  MACHINE_START(MSM7X30_SURF, "QCT MSM7X30 SURF")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params = PHYS_OFFSET + 0x100,
 +	.boot_params = PLAT_PHYS_OFFSET + 0x100,
  	.map_io = msm7x30_map_io,
  	.init_irq = msm7x30_init_irq,
  	.init_machine = msm7x30_init,
@@@ -93,9 -113,7 +113,7 @@@
  MACHINE_END
  
  MACHINE_START(MSM7X30_FFA, "QCT MSM7X30 FFA")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params = PHYS_OFFSET + 0x100,
 +	.boot_params = PLAT_PHYS_OFFSET + 0x100,
  	.map_io = msm7x30_map_io,
  	.init_irq = msm7x30_init_irq,
  	.init_machine = msm7x30_init,
@@@ -103,9 -121,7 +121,7 @@@
  MACHINE_END
  
  MACHINE_START(MSM7X30_FLUID, "QCT MSM7X30 FLUID")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params = PHYS_OFFSET + 0x100,
 +	.boot_params = PLAT_PHYS_OFFSET + 0x100,
  	.map_io = msm7x30_map_io,
  	.init_irq = msm7x30_init_irq,
  	.init_machine = msm7x30_init,
diff --cc arch/arm/mach-msm/board-qsd8x50.c
index 15c2bbd,b464d48..0000000
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@@ -116,9 -195,7 +195,7 @@@ static void __init qsd8x50_init(void
  }
  
  MACHINE_START(QSD8X50_SURF, "QCT QSD8X50 SURF")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params = PHYS_OFFSET + 0x100,
 +	.boot_params = PLAT_PHYS_OFFSET + 0x100,
  	.map_io = qsd8x50_map_io,
  	.init_irq = qsd8x50_init_irq,
  	.init_machine = qsd8x50_init,
@@@ -126,9 -203,7 +203,7 @@@
  MACHINE_END
  
  MACHINE_START(QSD8X50A_ST1_5, "QCT QSD8X50A ST1.5")
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params = PHYS_OFFSET + 0x100,
 +	.boot_params = PLAT_PHYS_OFFSET + 0x100,
  	.map_io = qsd8x50_map_io,
  	.init_irq = qsd8x50_init_irq,
  	.init_machine = qsd8x50_init,
diff --cc arch/arm/mach-msm/board-sapphire.c
index 83604f5,6781ca8..0000000
--- a/arch/arm/mach-msm/board-sapphire.c
+++ b/arch/arm/mach-msm/board-sapphire.c
@@@ -105,9 -105,7 +105,7 @@@ static void __init sapphire_map_io(void
  
  MACHINE_START(SAPPHIRE, "sapphire")
  /* Maintainer: Brian Swetland <swetland@google.com> */
- #ifdef CONFIG_MSM_DEBUG_UART
- #endif
 -	.boot_params    = PHYS_OFFSET + 0x100,
 +	.boot_params    = PLAT_PHYS_OFFSET + 0x100,
  	.fixup          = sapphire_fixup,
  	.map_io         = sapphire_map_io,
  	.init_irq       = sapphire_init_irq,

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

[David Brown]

On Sun, Jan 30 2011, Stephen Rothwell wrote:

> Hi David,
>
> Today's linux-next merge of the msm tree got conflicts in
> arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> initializers and assembly using PHYS_OFFSET") from the arm tree and
> commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> ifdefs") from the msm tree.
>
> I fixed it up (see below) and can carry the fix as necessary.

What is the best way to resolve this?  I can't really merge against
Russell's tree, since he may need to rebase his tree before the merge
window?  Or is it best to just have you carry the conflict resolution in
linux-next, and I make the resolution during the next merge window?

Thanks,
David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[Greg KH]

On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> On Sun, Jan 30 2011, Stephen Rothwell wrote:
> 
> > Hi David,
> >
> > Today's linux-next merge of the msm tree got conflicts in
> > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > ifdefs") from the msm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> What is the best way to resolve this?  I can't really merge against
> Russell's tree, since he may need to rebase his tree before the merge
> window?

Public trees should never be rebased, so that shouldn't happen.

thanks,

greg k-h

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

[Russell King]

On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > 
> > > Hi David,
> > >
> > > Today's linux-next merge of the msm tree got conflicts in
> > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > ifdefs") from the msm tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > What is the best way to resolve this?  I can't really merge against
> > Russell's tree, since he may need to rebase his tree before the merge
> > window?
> 
> Public trees should never be rebased, so that shouldn't happen.

No.  I refuse to operate in a rigid environment.

My tree is made available on the basis that the 'devel' branch is
constantly remerged (sometimes many times a day) from the individual
topic branches; 'devel' is a convenient branch for sfr to pull into
linux-next, and for others to see what's in the tree.

I am not permitted by people in the community to keep my development
work unpublished.

All the requirements from various different people are incompatible,
so I've chosen a way which satisfies the majority on the ARM community,
which is the community my tree serves.  It does not serve mainline
community interests.

So I do not operate a "commit the patch and its fixed" policy except
for branches which people need to be fixed; they need to discuss their
requirements with me to achieve that.

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

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

[Greg KH]

On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> > On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > > 
> > > > Hi David,
> > > >
> > > > Today's linux-next merge of the msm tree got conflicts in
> > > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > > ifdefs") from the msm tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > What is the best way to resolve this?  I can't really merge against
> > > Russell's tree, since he may need to rebase his tree before the merge
> > > window?
> > 
> > Public trees should never be rebased, so that shouldn't happen.
> 
> No.  I refuse to operate in a rigid environment.
> 
> My tree is made available on the basis that the 'devel' branch is
> constantly remerged (sometimes many times a day) from the individual
> topic branches; 'devel' is a convenient branch for sfr to pull into
> linux-next, and for others to see what's in the tree.

merging is fine, right?

Not rebasing, you really don't want to do that.  Linus has been all over
that topic in the past, I doubt he wants to bring it up again in detail.

> I am not permitted by people in the community to keep my development
> work unpublished.
> 
> All the requirements from various different people are incompatible,
> so I've chosen a way which satisfies the majority on the ARM community,
> which is the community my tree serves.  It does not serve mainline
> community interests.

So the goal of the ARM community isn't for the mainline community?  That
sounds like a big problem.

> So I do not operate a "commit the patch and its fixed" policy except
> for branches which people need to be fixed; they need to discuss their
> requirements with me to achieve that.

I'm not telling you how to run your branches, other than the simple fact
of: "if it's public, it shouldn't be rebased".  See Linus's comments for
why this is.

thanks,

greg k-h

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

[Russell King]

On Wed, Feb 02, 2011 at 12:32:52PM -0800, Greg KH wrote:
> On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> > On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> > > On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > > > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > > > 
> > > > > Hi David,
> > > > >
> > > > > Today's linux-next merge of the msm tree got conflicts in
> > > > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > > > ifdefs") from the msm tree.
> > > > >
> > > > > I fixed it up (see below) and can carry the fix as necessary.
> > > > 
> > > > What is the best way to resolve this?  I can't really merge against
> > > > Russell's tree, since he may need to rebase his tree before the merge
> > > > window?
> > > 
> > > Public trees should never be rebased, so that shouldn't happen.
> > 
> > No.  I refuse to operate in a rigid environment.
> > 
> > My tree is made available on the basis that the 'devel' branch is
> > constantly remerged (sometimes many times a day) from the individual
> > topic branches; 'devel' is a convenient branch for sfr to pull into
> > linux-next, and for others to see what's in the tree.
> 
> merging is fine, right?
> 
> Not rebasing, you really don't want to do that.  Linus has been all over
> that topic in the past, I doubt he wants to bring it up again in detail.
>
> > I am not permitted by people in the community to keep my development
> > work unpublished.
> > 
> > All the requirements from various different people are incompatible,
> > so I've chosen a way which satisfies the majority on the ARM community,
> > which is the community my tree serves.  It does not serve mainline
> > community interests.
> 
> So the goal of the ARM community isn't for the mainline community?  That
> sounds like a big problem.
> 
> > So I do not operate a "commit the patch and its fixed" policy except
> > for branches which people need to be fixed; they need to discuss their
> > requirements with me to achieve that.
> 
> I'm not telling you how to run your branches, other than the simple fact
> of: "if it's public, it shouldn't be rebased".  See Linus's comments for
> why this is.

I'm not going to get involved in an argument over this.  If people
insist on telling me not to publish then I'll do exactly that - I'll
make my tree hidden from public view.

My personal preference was not to publish, but my hand was forced.

I've added Nicolas so he can fight for having my tree visible in an
unstable form.

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

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

[Nicolas Pitre]

On Wed, 2 Feb 2011, Russell King wrote:

> On Wed, Feb 02, 2011 at 12:32:52PM -0800, Greg KH wrote:
> > On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> > > On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> > > > On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > > > > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > > > > 
> > > > > > Hi David,
> > > > > >
> > > > > > Today's linux-next merge of the msm tree got conflicts in
> > > > > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > > > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > > > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > > > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > > > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > > > > ifdefs") from the msm tree.
> > > > > >
> > > > > > I fixed it up (see below) and can carry the fix as necessary.
> > > > > 
> > > > > What is the best way to resolve this?  I can't really merge against
> > > > > Russell's tree, since he may need to rebase his tree before the merge
> > > > > window?
> > > > 
> > > > Public trees should never be rebased, so that shouldn't happen.
> > > 
> > > No.  I refuse to operate in a rigid environment.
> > > 
> > > My tree is made available on the basis that the 'devel' branch is
> > > constantly remerged (sometimes many times a day) from the individual
> > > topic branches; 'devel' is a convenient branch for sfr to pull into
> > > linux-next, and for others to see what's in the tree.
> > 
> > merging is fine, right?
> > 
> > Not rebasing, you really don't want to do that.  Linus has been all over
> > that topic in the past, I doubt he wants to bring it up again in detail.

Linus has said that you are not supposed to rebase other people's tree.  
The obvious reason is that once you rebase someone else's work, you void 
all the testing that person might have done since the environment is not 
the same as the one in which it was tested initially.  This came about 
because davem (just to name a prominent figure) did use to rebase other 
people's tree he pulled into his tree in order to make a nice linearized 
history for some reasons.

Linus also said that, if you do publish a tree for others to base their 
work on, you must not rebase your tree for obvious reasons.

But never did Linus say that rebasing was outright forbidden.  There are 
cases where it is appropriate (e.g. linux-next) and other cases where it 
is not.  For people without enough git fu to make the difference then it 
is best not to rebase.  but in some workflows it is just the right 
thing to do.

> > > I am not permitted by people in the community to keep my development
> > > work unpublished.
> > > 
> > > All the requirements from various different people are incompatible,
> > > so I've chosen a way which satisfies the majority on the ARM community,
> > > which is the community my tree serves.  It does not serve mainline
> > > community interests.
> > 
> > So the goal of the ARM community isn't for the mainline community?  That
> > sounds like a big problem.

Please stop spreading B/S.

> > > So I do not operate a "commit the patch and its fixed" policy except
> > > for branches which people need to be fixed; they need to discuss their
> > > requirements with me to achieve that.
> > 
> > I'm not telling you how to run your branches, other than the simple fact
> > of: "if it's public, it shouldn't be rebased".  See Linus's comments for
> > why this is.

Then for all purposes please just consider RMK's tree as non existent.  
That should solve your problem.

Those who've worked well with RMK and his semi-rebasing workflow for the 
last 5 years should continue to do so as they see fit.

If you do need a stable branch for some features you need to base your 
work on, then just ask RMK for one.  He always managed it in the past.

The actual problem here is that some people, notably the msm folks, are 
bypassing the maintainer hierarchy and going straight to Linus for their 
pull requests instead of asking RMK to pull.  We once debated this at 
some point and it was agreed that completely independent SOC specific 
code with no dependencies on the common ARM code _could_ go straight to 
Linus directly if they crave for it.  But in this case:

1) the conflict is obviously simple

2) the conflict resolution is just as obvious

3) and Stephen is able and willing to carry this conflict resolution for 
   the foreseeable future until this all gets merged in mainline.

So... WTF is the actual problem here?


Nicolas

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

[David Brown]

On Wed, Feb 02 2011, Nicolas Pitre wrote:

> The actual problem here is that some people, notably the msm folks, are 
> bypassing the maintainer hierarchy and going straight to Linus for their 
> pull requests instead of asking RMK to pull.  We once debated this at 
> some point and it was agreed that completely independent SOC specific 
> code with no dependencies on the common ARM code _could_ go straight to 
> Linus directly if they crave for it.  But in this case:
>
> 1) the conflict is obviously simple
>
> 2) the conflict resolution is just as obvious
>
> 3) and Stephen is able and willing to carry this conflict resolution for 
>    the foreseeable future until this all gets merged in mainline.
>
> So... WTF is the actual problem here?

I hadn't really brought this up as a problem, but was mostly wondering
if it was ok to just have Stephen carry the conflict resolution until
the next merge window.  The rest of the comments came from Greg.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[David Brown]

On Wed, Feb 02 2011, Nicolas Pitre wrote:

> The actual problem here is that some people, notably the msm folks, are 
> bypassing the maintainer hierarchy and going straight to Linus for their 
> pull requests instead of asking RMK to pull.  We once debated this at 
> some point and it was agreed that completely independent SOC specific 
> code with no dependencies on the common ARM code _could_ go straight to 
> Linus directly if they crave for it.

I also have no real problem sending pull requests to RMK instead of
Linus, as long as it isn't a pain.  Linus gives clear directions as to
how his tree works, and when he expects what kinds of pull requests.
Weird web-based patch tracking systems are a pain.  Pull requests from
git with a fairly easy way to know when they've been pulled are not.

I also find that http://ftp.arm.linux.org.uk/ is frequently
inaccessable, and usually slow.

As it stands, so far, it's been a lot less work for me to send directly
to Linus, and resolve the issues that come up when they do.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[Nicolas Pitre]

On Wed, 2 Feb 2011, David Brown wrote:

> On Wed, Feb 02 2011, Nicolas Pitre wrote:
> 
> > The actual problem here is that some people, notably the msm folks, are 
> > bypassing the maintainer hierarchy and going straight to Linus for their 
> > pull requests instead of asking RMK to pull.  We once debated this at 
> > some point and it was agreed that completely independent SOC specific 
> > code with no dependencies on the common ARM code _could_ go straight to 
> > Linus directly if they crave for it.
> 
> I also have no real problem sending pull requests to RMK instead of
> Linus, as long as it isn't a pain.  Linus gives clear directions as to
> how his tree works, and when he expects what kinds of pull requests.
> Weird web-based patch tracking systems are a pain.  Pull requests from
> git with a fairly easy way to know when they've been pulled are not.

RMK accepts pull requests.  He also stated pretty clearly when he wishes 
for those requests to happen, or rather when it is too late for those 
requests to come by so he has a chance to sort his tree out in time for 
the merge window.

> I also find that http://ftp.arm.linux.org.uk/ is frequently
> inaccessable, and usually slow.

The "slow" part should be fixed now that the Git server over there has 
been configured to serve Git requests using the Git smart protocol over 
HTTP.

Admitedly, if RMK had a public mirror on git.kernel.org that would help 
things (a lot of people do have rebasing Git repos there already).

> As it stands, so far, it's been a lot less work for me to send directly
> to Linus, and resolve the issues that come up when they do.

This is however more work for Linus who already expressed some concerns 
about too many people going to him directly while he'd prefer a more 
distributed flow.


Nicolas

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

[Daniel Walker]

On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> The actual problem here is that some people, notably the msm folks,
> are 
> bypassing the maintainer hierarchy and going straight to Linus for
> their 
> pull requests instead of asking RMK to pull.  We once debated this at 

I don't think it's fair to single out MSM here. Going straight to Linus
was discussed at one point, as I recall, and Russell didn't oppose it at
the time. There are a number of ARM sub-architecture maintainers that do
this.. None of that is related to the rejects created here, those would
happen no matter who we submitted pull requests to.

I think the issue is more that MSM is actively being cleanup , and
Russell is touching code that we're working on also. So we need a way to
work together .. In this case the collision is so simple that either
Linus or Russell would just fix it up while pulling, and both would
likely be fine with that. In the past I've tried to fix up these issues,
but now I think maybe it's doesn't matter.

In terms of Russell rebasing, I don't really like that. I've based MSM
trees on Russell's stable branch and it's worked in the past. If
Russell's rebasing then we can't really do that, so one tool to fix
these problems is gone.

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

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

[Russell King]

On Fri, Feb 04, 2011 at 09:17:34AM -0800, Daniel Walker wrote:
> On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> > The actual problem here is that some people, notably the msm folks,
> > are 
> > bypassing the maintainer hierarchy and going straight to Linus for
> > their 
> > pull requests instead of asking RMK to pull.  We once debated this at 
> 
> I don't think it's fair to single out MSM here. Going straight to Linus
> was discussed at one point, as I recall, and Russell didn't oppose it at
> the time. There are a number of ARM sub-architecture maintainers that do
> this.. None of that is related to the rejects created here, those would
> happen no matter who we submitted pull requests to.
> 
> I think the issue is more that MSM is actively being cleanup , and
> Russell is touching code that we're working on also. So we need a way to
> work together .. In this case the collision is so simple that either
> Linus or Russell would just fix it up while pulling, and both would
> likely be fine with that. In the past I've tried to fix up these issues,
> but now I think maybe it's doesn't matter.
> 
> In terms of Russell rebasing, I don't really like that. I've based MSM
> trees on Russell's stable branch and it's worked in the past. If
> Russell's rebasing then we can't really do that, so one tool to fix
> these problems is gone.

The alternative is that I don't publish patches in git form.  Or do I
publish patches in git form and never add any acks or tested-by
information to them ever.

It's really no skin off my nose if I never add any acks, tested-by or
reviewed-by tags to my patches - it actually means _less_ work for me.
I'd prefer to give credit where credit is due, but if idiotic rules
mean that I can't, that's really not my problem.

Goody, I can spend that time doing more productive work.

So, here's a questionaire:

1. Would it be acceptable to keep the p2v changes hidden from public view
via git for months, and only available in patch form as I'm waiting for
acks from people?

2. Would you have found this if these changes weren't in linux-next?

3. Would you have found it by applying my patches from the mailing list to
your tree?

4. Is it acceptable not to acknowledge people who've tested and reviewed?

The answers are most probably: no, no, no and no.

And now you see my dilema: 1 is incompatible with 4.

I argue that you're better off _seeing_ the changes via git and linux-next
because then linux-next can pick up these conflicts when they happen and
we can sort out the resulting mess when that happens.

I've no problem _eventually_ freezing the p2v branch, but the p2v stuff is
currently in flux: althrough I've requested acks from Nicolas, none are
forthcoming yet - and there's going to be some further work:

| > Thanks, merged those in.  Can I have new acks for the p2v branch please?
|
| Yes, hopefully soon.  I should also restore Thumb2
| support in the process.

So you tell me - do I take the p2v stuff out of public view tonight
because it's not stable, and therefore you don't even know about the
conflict?

Or do I continue publishing the unstable changes so that people have
the ability to see what's going on in my tree and find potential
conflicts?

I really don't care which - but I'll warn you that keeping changes
hidden will result in a reduction of patch quality, and much much
much less testing of those changes.  And I won't care at all when you
complain that MSM's broken because of one of my patches.

Exactly what would you prefer?

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

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

[David Brown]

On Fri, Feb 04 2011, Russell King wrote:

> I really don't care which - but I'll warn you that keeping changes
> hidden will result in a reduction of patch quality, and much much
> much less testing of those changes.  And I won't care at all when you
> complain that MSM's broken because of one of my patches.
>
> Exactly what would you prefer?

I'd like to get a little bit of an idea what you would prefer me to do.

I see two reasonable workflows:

  - I make a branch for the files that conflict with other changes in
    the ARM tree and submit pull requests to you (Russell) for these
    changes.  Other MSM-specific changes would be in another tree that
    goes to Linus.

  - I submit everything via pull requests to you.  This would probably
    result in one additional request to you, that contained the stuff
    that didn't conflict, since it would be nice to resolve the obvious
    conflicts earlier.

The later is more work for you, and less for Linus.

Thanks,
David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[Daniel Walker]

On Fri, 2011-02-04 at 17:42 +0000, Russell King wrote:
> So you tell me - do I take the p2v stuff out of public view tonight
> because it's not stable, and therefore you don't even know about the
> conflict?
> 
> Or do I continue publishing the unstable changes so that people have
> the ability to see what's going on in my tree and find potential
> conflicts?
> 
> I really don't care which - but I'll warn you that keeping changes
> hidden will result in a reduction of patch quality, and much much
> much less testing of those changes.  And I won't care at all when you
> complain that MSM's broken because of one of my patches.
> 
> Exactly what would you prefer? 

I'm not really opposed to any of your objectives. What it sounds like is
that you have a "stable" branch, and an "unstable" branch. Both branches
are in linux-next , and we're seeing conflicts from the unstable one. Is
that accurate?

I think we can deal with the issues as long as you have one branch that
you don't rebase, and things eventually move into that branch. So if we
have a conflict then we can base our tree on your stable branch , and
have confidence that your not rebasing it, or merge that into our tree.

I think the problem is that when you say your rebase it's not clear if
your rebasing all your branches, or if you only rebasing one unstable
branch..

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

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

[Nicolas Pitre]

On Fri, 4 Feb 2011, Daniel Walker wrote:

> On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote:
> > The actual problem here is that some people, notably the msm folks,
> > are 
> > bypassing the maintainer hierarchy and going straight to Linus for
> > their 
> > pull requests instead of asking RMK to pull.  We once debated this at 
> 
> I don't think it's fair to single out MSM here. Going straight to Linus
> was discussed at one point, as I recall, and Russell didn't oppose it at
> the time. There are a number of ARM sub-architecture maintainers that do
> this..

The point still stands for msm as well as for the others.  And this is 
now causing fuss amongst second guessers as this thread is showing.  
But this aside, this is still putting more load on Linus while this load 
could be more distributed.

> None of that is related to the rejects created here, those would
> happen no matter who we submitted pull requests to.

Indeed.  And trivial is the fix, which is what I've said too.

> I think the issue is more that MSM is actively being cleanup , and
> Russell is touching code that we're working on also. So we need a way to
> work together .. In this case the collision is so simple that either
> Linus or Russell would just fix it up while pulling, and both would
> likely be fine with that. 

Exact.

Maybe this would be nicer to Russell and others performing wide ranging 
changes to the ARM code if the msm tree was more visible downstream, and 
potentially help to avoid making a mountain out of a mole hill.

> In the past I've tried to fix up these issues,
> but now I think maybe it's doesn't matter.

I'm sure Stephen knows about git's rerere facility, or he might have 
developed one of his own by now, hence his proposal to carry simple 
conflict resolution for as long as required.  So yes, I don't think this 
is something that must be "fixed" if carrying the fix in the downstream 
tree causes more trouble than the trivial merge involved.

> In terms of Russell rebasing, I don't really like that. I've based MSM
> trees on Russell's stable branch and it's worked in the past. If
> Russell's rebasing then we can't really do that, so one tool to fix
> these problems is gone.

Russell has so named his "stable" branch for a reason.  I'll let you 
guess what it is.  :-)


Nicolas

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

[David Brown]

On Fri, Feb 04 2011, Nicolas Pitre wrote:

> Maybe this would be nicer to Russell and others performing wide ranging 
> changes to the ARM code if the msm tree was more visible downstream, and 
> potentially help to avoid making a mountain out of a mole hill.

Currently, the msm tree is in linux-next, and the URL is in the
MAINTAINER's file.  The only want to make it more visible would be to
give frequent pull requests to RMK, which would create extra work for
him.  I think I just need to come up with the right balance of how often
to give the tree to RMK.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[Stephen Rothwell]

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

Hi David,

Today's linux-next merge of the msm tree got a conflict in
arch/arm/Kconfig.debug between several commits from the arm tree and
commit 7bd51cd4526d ("ARM: msm: Move debug-macro.S to include/debug")
from the msm tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

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

diff --cc arch/arm/Kconfig.debug
index 38c92d7,4a62a8d..0000000
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -886,178 -775,43 +886,183 @@@ config DEBUG_LL_INCLUD
  				 DEBUG_IMX53_UART ||\
  				 DEBUG_IMX6Q_UART || \
  				 DEBUG_IMX6SL_UART
 -	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 -				      DEBUG_KEYSTONE_UART1
+ 	default "debug/msm.S" if DEBUG_MSM_UART1 || \
+ 				 DEBUG_MSM_UART2 || \
+ 				 DEBUG_MSM_UART3 || \
+ 				 DEBUG_MSM8660_UART || \
+ 				 DEBUG_MSM8960_UART
 -	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
 -				   DEBUG_MVEBU_UART_ALTERNATE
 -	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 -	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
 -	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
 -					DEBUG_NSPIRE_CLASSIC_UART
  	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 -	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 -	default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
 -				 DEBUG_MMP_UART3
 -	default "debug/rockchip.S" if DEBUG_ROCKCHIP_UART
  	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 -	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
  	default "debug/sti.S" if DEBUG_STI_UART
 -	default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
  	default "debug/tegra.S" if DEBUG_TEGRA_UART
 -	default "debug/u300.S" if DEBUG_U300_UART
  	default "debug/ux500.S" if DEBUG_UX500_UART
 -	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
 -		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
 -		DEBUG_VEXPRESS_UART0_CRX
 +	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
 +	default "debug/vf.S" if DEBUG_VF_UART
  	default "debug/vt8500.S" if DEBUG_VT8500_UART0
  	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
  	default "mach/debug-macro.S"
  
 +# Compatibility options for PL01x
 +config DEBUG_UART_PL01X
 +	def_bool ARCH_EP93XX || \
 +		ARCH_INTEGRATOR || \
 +		ARCH_SPEAR3XX || \
 +		ARCH_SPEAR6XX || \
 +		ARCH_SPEAR13XX || \
 +		ARCH_VERSATILE
 +
 +# Compatibility options for 8250
 +config DEBUG_UART_8250
 +	def_bool ARCH_DOVE || ARCH_EBSA110 || \
 +		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
 +		ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
 +		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
 +		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
 +
 +config DEBUG_UART_PHYS
 +	hex "Physical base address of debug UART"
 +	default 0x01c20000 if DEBUG_DAVINCI_DMx_UART0
 +	default 0x01c28000 if DEBUG_SUNXI_UART0
 +	default 0x01c28400 if DEBUG_SUNXI_UART1
 +	default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
 +	default 0x01d0d000 if DEBUG_DAVINCI_DA8XX_UART2
 +	default 0x02530c00 if DEBUG_KEYSTONE_UART0
 +	default 0x02531000 if DEBUG_KEYSTONE_UART1
 +	default 0x03010fe0 if ARCH_RPC
 +	default 0x08108300 if DEBUG_DAVINCI_TNETV107X_UART1
 +	default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \
 +				DEBUG_VEXPRESS_UART0_CA9
 +	default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
 +	default 0x10124000 if DEBUG_RK3X_UART0
 +	default 0x10126000 if DEBUG_RK3X_UART1
 +	default 0x101f1000 if ARCH_VERSATILE
 +	default 0x101fb000 if DEBUG_NOMADIK_UART
 +	default 0x16000000 if ARCH_INTEGRATOR
 +	default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
 +	default 0x20060000 if DEBUG_RK29_UART0
 +	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 +	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 +	default 0x20201000 if DEBUG_BCM2835
 +	default 0x40090000 if ARCH_LPC32XX
 +	default 0x40100000 if DEBUG_PXA_UART1
 +	default 0x42000000 if ARCH_GEMINI
 +	default 0x7c0003f8 if FOOTBRIDGE
 +	default 0x80230000 if DEBUG_PICOXCELL_UART
 +	default 0x80070000 if DEBUG_IMX23_UART
 +	default 0x80074000 if DEBUG_IMX28_UART
 +	default 0x808c0000 if ARCH_EP93XX
 +	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 +	default 0xb0090000 if DEBUG_VEXPRESS_UART0_CRX
 +	default 0xc0013000 if DEBUG_U300_UART
 +	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 +	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 +	default 0xd0000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
 +	default 0xd0012000 if DEBUG_MVEBU_UART
 +	default 0xd4017000 if DEBUG_MMP_UART2
 +	default 0xd4018000 if DEBUG_MMP_UART3
 +	default 0xe0000000 if ARCH_SPEAR13XX
 +	default 0xf0000be0 if ARCH_EBSA110
 +	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
 +	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
 +				ARCH_ORION5X
 +	default 0xfe800000 if ARCH_IOP32X
 +	default 0xffc02000 if DEBUG_SOCFPGA_UART
 +	default 0xffd82340 if ARCH_IOP13XX
 +	default 0xfff36000 if DEBUG_HIGHBANK_UART
 +	default 0xfffff700 if ARCH_IOP33X
 +	depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
 +		DEBUG_UART_8250 || DEBUG_UART_PL01X
 +
 +config DEBUG_UART_VIRT
 +	hex "Virtual base address of debug UART"
 +	default 0xe0010fe0 if ARCH_RPC
 +	default 0xf0000be0 if ARCH_EBSA110
 +	default 0xf0009000 if DEBUG_CNS3XXX
 +	default 0xf01fb000 if DEBUG_NOMADIK_UART
 +	default 0xf0201000 if DEBUG_BCM2835
 +	default 0xf11f1000 if ARCH_VERSATILE
 +	default 0xf1600000 if ARCH_INTEGRATOR
 +	default 0xf1c28000 if DEBUG_SUNXI_UART0
 +	default 0xf1c28400 if DEBUG_SUNXI_UART1
 +	default 0xf2100000 if DEBUG_PXA_UART1
 +	default 0xf4090000 if ARCH_LPC32XX
 +	default 0xf4200000 if ARCH_GEMINI
 +	default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
 +	default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
 +	default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
 +	default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
 +	default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
 +	default 0xfd000000 if ARCH_SPEAR13XX
 +	default 0xfd012000 if ARCH_MV78XX0
 +	default 0xfde12000 if ARCH_DOVE
 +	default 0xfe012000 if ARCH_ORION5X
 +	default 0xfe017000 if DEBUG_MMP_UART2
 +	default 0xfe018000 if DEBUG_MMP_UART3
 +	default 0xfe100000 if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 +	default 0xfe230000 if DEBUG_PICOXCELL_UART
 +	default 0xfe800000 if ARCH_IOP32X
 +	default 0xfeb24000 if DEBUG_RK3X_UART0
 +	default 0xfeb26000 if DEBUG_RK3X_UART1
 +	default 0xfeb30c00 if DEBUG_KEYSTONE_UART0
 +	default 0xfeb31000 if DEBUG_KEYSTONE_UART1
 +	default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE
 +	default 0xfed60000 if DEBUG_RK29_UART0
 +	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 +	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 +	default 0xfec02000 if DEBUG_SOCFPGA_UART
 +	default 0xfec20000 if DEBUG_DAVINCI_DMx_UART0
 +	default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1
 +	default 0xfed0d000 if DEBUG_DAVINCI_DA8XX_UART2
 +	default 0xfed12000 if ARCH_KIRKWOOD
 +	default 0xfedc0000 if ARCH_EP93XX
 +	default 0xfee003f8 if FOOTBRIDGE
 +	default 0xfee08300 if DEBUG_DAVINCI_TNETV107X_UART1
 +	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 +	default 0xfee36000 if DEBUG_HIGHBANK_UART
 +	default 0xfee82340 if ARCH_IOP13XX
 +	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 +	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 +	default 0xfefff700 if ARCH_IOP33X
 +	default 0xff003000 if DEBUG_U300_UART
 +	default DEBUG_UART_PHYS if !MMU
 +	depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
 +		DEBUG_UART_8250 || DEBUG_UART_PL01X
 +
 +config DEBUG_UART_8250_SHIFT
 +	int "Register offset shift for the 8250 debug UART"
 +	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 +	default 0 if FOOTBRIDGE || ARCH_IOP32X
 +	default 2
 +
 +config DEBUG_UART_8250_WORD
 +	bool "Use 32-bit accesses for 8250 UART"
 +	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 +	depends on DEBUG_UART_8250_SHIFT >= 2
 +	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \
 +		ARCH_KEYSTONE || \
 +		DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
 +		DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1
 +
 +config DEBUG_UART_8250_FLOW_CONTROL
 +	bool "Enable flow control for 8250 UART"
 +	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 +	default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
 +
  config DEBUG_UNCOMPRESS
  	bool
- 	depends on ARCH_MULTIPLATFORM
 -	default y if (ARCH_MULTIPLATFORM || ARCH_MSM) && DEBUG_LL && \
 -		     !DEBUG_OMAP2PLUS_UART && \
++	depends on ARCH_MULTIPLATFORM || ARCH_MSM
 +	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
  		     !DEBUG_TEGRA_UART
 +	help
 +	  This option influences the normal decompressor output for
 +	  multiplatform kernels.  Normally, multiplatform kernels disable
 +	  decompressor output because it is not possible to know where to
 +	  send the decompressor output.
 +
 +	  When this option is set, the selected DEBUG_LL output method
 +	  will be re-used for normal decompressor output on multiplatform
 +	  kernels.
 +	  
  
  config UNCOMPRESS_INCLUDE
  	string

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

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

[Stephen Rothwell]

Hi David,

Today's linux-next merge of the msm tree got a conflict in
arch/arm/mach-msm/include/mach/memory.h between commit
66a37c58abc2d7e953e339c64721dc53fb140b38 ("ARM: P2V: separate PHYS_OFFSET
from platform definitions") from the arm tree and commit
a2ad9421ce19f57e99b7a5e8798b8697b916d673 ("msm: Physical offset for
MSM8960") from the msm 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-msm/include/mach/memory.h
index 176875d,014bbd3..0000000
--- a/arch/arm/mach-msm/include/mach/memory.h
+++ b/arch/arm/mach-msm/include/mach/memory.h
@@@ -18,15 -18,17 +18,17 @@@
  
  /* physical offset of RAM */
  #if defined(CONFIG_ARCH_QSD8X50) && defined(CONFIG_MSM_SOC_REV_A)
 -#define PHYS_OFFSET		UL(0x00000000)
 +#define PLAT_PHYS_OFFSET		UL(0x00000000)
  #elif defined(CONFIG_ARCH_QSD8X50)
 -#define PHYS_OFFSET		UL(0x20000000)
 +#define PLAT_PHYS_OFFSET		UL(0x20000000)
  #elif defined(CONFIG_ARCH_MSM7X30)
 -#define PHYS_OFFSET		UL(0x00200000)
 +#define PLAT_PHYS_OFFSET		UL(0x00200000)
  #elif defined(CONFIG_ARCH_MSM8X60)
 -#define PHYS_OFFSET		UL(0x40200000)
 +#define PLAT_PHYS_OFFSET		UL(0x40200000)
+ #elif defined(CONFIG_ARCH_MSM8960)
 -#define PHYS_OFFSET		UL(0x40200000)
++#define PLAT_PHYS_OFFSET		UL(0x40200000)
  #else
 -#define PHYS_OFFSET		UL(0x10000000)
 +#define PLAT_PHYS_OFFSET		UL(0x10000000)
  #endif
  
  #endif

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

[Daniel Walker]

On Tue, 2010-10-19 at 19:53 +0100, Russell King wrote:
> On Tue, Oct 19, 2010 at 11:42:37AM -0700, Daniel Walker wrote:
> > 
> > > That's why on occasions we do transgress the established process to 
> > > accommodate such changes.  Imagine just for a moment the patch that 
> > > modified the interrupt callback prototype to remove the useless pt_regs 
> > > argument.  Obviously, it had to be done atomically to the _whole_ tree, 
> > > and it was agreed that this patch was to be applied at the end of the 
> > > merge window.  But no one expected a single minute sending a CC to _all_ 
> > > the driver authors.
> > 
> > I don't actually know which patch your talking about, but it sounds
> > pretty simple.. I'm not really addressing really simple fixes, even tho
> > changing a single parameter on a function could be done broken up
> > depending on what it is.
> 
> As you think that it's a simple matter, I challenge you to break this
> change up in a way that doesn't result in any build breakage:
> 	7d12e780e003f93433d49ce78cfedf4b4c52adc5

I wasn't saying it's simple to break patches up. I was just saying the
patch sounded like something simple, like running sed over the source or
a change replace type patch.

I'll look at the patch you reference tho, maybe I can break it up.

Daniel

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

[Russell King]

On Tue, Oct 19, 2010 at 11:42:37AM -0700, Daniel Walker wrote:
> 
> > That's why on occasions we do transgress the established process to 
> > accommodate such changes.  Imagine just for a moment the patch that 
> > modified the interrupt callback prototype to remove the useless pt_regs 
> > argument.  Obviously, it had to be done atomically to the _whole_ tree, 
> > and it was agreed that this patch was to be applied at the end of the 
> > merge window.  But no one expected a single minute sending a CC to _all_ 
> > the driver authors.
> 
> I don't actually know which patch your talking about, but it sounds
> pretty simple.. I'm not really addressing really simple fixes, even tho
> changing a single parameter on a function could be done broken up
> depending on what it is.

As you think that it's a simple matter, I challenge you to break this
change up in a way that doesn't result in any build breakage:
	7d12e780e003f93433d49ce78cfedf4b4c52adc5

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

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

[Daniel Walker]

On Tue, 2010-10-19 at 19:34 +0100, Russell King wrote:
> On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> > On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > > On Tuesday 19 October 2010, Joe Perches wrote:
> > > > This could have been done:
> > > > 
> > > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > > 35
> > > > 
> > > > Even then, using 35 CCs is generally silly.
> > > > 
> > > > It might make some sense for a cover letter and a
> > > > patch series where the series made tree-wide changes
> > > > in multiple directories.
> > > 
> > > Probably not even then: When a single mail header gets too long, you usually land
> > > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > > characters (this may come from an official RFC, don't know), which is usually less
> > > than 35 recipients.
> > 
> > Patches just shouldn't be this large.
> 
> Patches get large.  Sometimes they can't be sensibly broken up.  We
> have to accept them as is sometimes.  This is one of those occasions.
> See the example Nicolas gave you - it's no different.
> 
> As for you saying that I'm the one getting excited about this - I'm not.
> I'm getting pissed off by how much discussion effort this trivial matter
> is taking and how much time it's wasting, which really isn't necessary.
> There's far better things to be done (such as testing) rather than taking
> hours to sort out what is basically a trivial merge issue.
> 
> Now, you've said in your pull request:
> 
> | Here is your pull request Russell. This has the patch which was part of
> | the conflict in MSM, "msm: allow uart to be conditionally disabled"..
> | 
> | It's on top of v2.6.36-rc5, and it has one patch that is already in your
> | tree. It's "GIC: Dont disable INT in ack callback" .
> | 
> | This pull request is exactly what I would send to Linus is the merge
> | window was open.
> 
> As I'm merging it into a tree which does _not_ have the changes from
> Jeremy and Nicolas, what's this "the patch which was part of the
> conflict" and what's it going to do without Nicolas' changes?

Um , the patches I sent you are un-altered from what was originally in
my tree prior to the conflict.

I was just making note of the fact that a conflict in -next happened in
relation to that patch in my tree. I wasn't suggesting that my tree
changed at all.

> The point of dropping Jeremy and Nicolas' changes are to return to a
> state where things were before the troublesome change, so that the
> existing code works.  Then Nicolas was going to take what is in my
> tree, and update the patches to take account of what's there.

yeah, that's what I'm assuming.. So I sent you exactly what I would have
sent Linus , i.e. doesn't take into account and troublesome patches of
any kind.

> If you're going to pre-empt that by fixing the stuff yourself, this
> whole exercise has been pointless, because it means that the code in
> your tree currently won't build without these other changes.

There's nothing fixed in my tree. I sent you a the pre-fixed tree. And
the troublesome patches will need to be conflict resolved even after my
tree is pulled.

> So at the moment I don't know whether or not I should pull your tree.

The tree should be what you wanted ..

Daniel

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

[Daniel Walker]

> That's why on occasions we do transgress the established process to 
> accommodate such changes.  Imagine just for a moment the patch that 
> modified the interrupt callback prototype to remove the useless pt_regs 
> argument.  Obviously, it had to be done atomically to the _whole_ tree, 
> and it was agreed that this patch was to be applied at the end of the 
> merge window.  But no one expected a single minute sending a CC to _all_ 
> the driver authors.

I don't actually know which patch your talking about, but it sounds
pretty simple.. I'm not really addressing really simple fixes, even tho
changing a single parameter on a function could be done broken up
depending on what it is.

Daniel

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

[Russell King]

On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Joe Perches wrote:
> > > This could have been done:
> > > 
> > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > 35
> > > 
> > > Even then, using 35 CCs is generally silly.
> > > 
> > > It might make some sense for a cover letter and a
> > > patch series where the series made tree-wide changes
> > > in multiple directories.
> > 
> > Probably not even then: When a single mail header gets too long, you usually land
> > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > characters (this may come from an official RFC, don't know), which is usually less
> > than 35 recipients.
> 
> Patches just shouldn't be this large.

Patches get large.  Sometimes they can't be sensibly broken up.  We
have to accept them as is sometimes.  This is one of those occasions.
See the example Nicolas gave you - it's no different.

As for you saying that I'm the one getting excited about this - I'm not.
I'm getting pissed off by how much discussion effort this trivial matter
is taking and how much time it's wasting, which really isn't necessary.
There's far better things to be done (such as testing) rather than taking
hours to sort out what is basically a trivial merge issue.

Now, you've said in your pull request:

| Here is your pull request Russell. This has the patch which was part of
| the conflict in MSM, "msm: allow uart to be conditionally disabled"..
| 
| It's on top of v2.6.36-rc5, and it has one patch that is already in your
| tree. It's "GIC: Dont disable INT in ack callback" .
| 
| This pull request is exactly what I would send to Linus is the merge
| window was open.

As I'm merging it into a tree which does _not_ have the changes from
Jeremy and Nicolas, what's this "the patch which was part of the
conflict" and what's it going to do without Nicolas' changes?

The point of dropping Jeremy and Nicolas' changes are to return to a
state where things were before the troublesome change, so that the
existing code works.  Then Nicolas was going to take what is in my
tree, and update the patches to take account of what's there.

If you're going to pre-empt that by fixing the stuff yourself, this
whole exercise has been pointless, because it means that the code in
your tree currently won't build without these other changes.

So at the moment I don't know whether or not I should pull your tree.

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

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

[Nicolas Pitre]

On Tue, 19 Oct 2010, Daniel Walker wrote:

> On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Joe Perches wrote:
> > > This could have been done:
> > > 
> > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > 35
> > > 
> > > Even then, using 35 CCs is generally silly.
> > > 
> > > It might make some sense for a cover letter and a
> > > patch series where the series made tree-wide changes
> > > in multiple directories.
> > 
> > Probably not even then: When a single mail header gets too long, you usually land
> > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > characters (this may come from an official RFC, don't know), which is usually less
> > than 35 recipients.
> 
> Patches just shouldn't be this large. You want smaller patches for a lot
> of reason. Take the BKL, would it have been acceptable to make all the
> BKL changes in a single patch (and what would the CC have looked like)?
> If you do anything remotely sophisticated then , from my perspective, a
> tree wide patch just isn't going to work.

That's why on occasions we do transgress the established process to 
accommodate such changes.  Imagine just for a moment the patch that 
modified the interrupt callback prototype to remove the useless pt_regs 
argument.  Obviously, it had to be done atomically to the _whole_ tree, 
and it was agreed that this patch was to be applied at the end of the 
merge window.  But no one expected a single minute sending a CC to _all_ 
the driver authors.


Nicolas

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

[Daniel Walker]

On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010, Joe Perches wrote:
> > This could have been done:
> > 
> > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > 35
> > 
> > Even then, using 35 CCs is generally silly.
> > 
> > It might make some sense for a cover letter and a
> > patch series where the series made tree-wide changes
> > in multiple directories.
> 
> Probably not even then: When a single mail header gets too long, you usually land
> in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> characters (this may come from an official RFC, don't know), which is usually less
> than 35 recipients.

Patches just shouldn't be this large. You want smaller patches for a lot
of reason. Take the BKL, would it have been acceptable to make all the
BKL changes in a single patch (and what would the CC have looked like)?
If you do anything remotely sophisticated then , from my perspective, a
tree wide patch just isn't going to work.

Daniel

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

[Daniel Walker]

On Mon, 2010-10-18 at 22:47 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
> 
> > I can say that I know for a fact that people don't read every patch, or
> > every email, or keep track of every single thread. I don't think it's
> > reasonable to expect people to do that. there's too many email, too many
> > threads, too many discussions etc ..
> 
> I'm not saying that you should keep track of every threads.  But you 
> should at least pay attention to what thread is being discussed, simply 
> by looking at the subject line.  Any good MUA will let you sort emails 
> and collapse them into thread view.  And scoring those incoming emails 
> with "arch/arm/mach-msm" for example is a quick way for you to be 
> noticed when a patch might be changing something in your area.  Tools 
> are there for you.

AFAIK before this thread, I should get CC'd when you modify me tree..
Maybe I'll setup some tools _now_ ..

> > This discussion isn't really about that. It's not about people reading
> > every single patch, which we know they don't do. This is about conflicts
> > in -next.
> 
> Glad to get back to the original issue.
> 
> > These patches caused conflicts in -next .. What more could I have done
> > to prevent conflicts coming from another tree and patches that appear
> > not to effect me? Even if I read all the patches, and threads, it still
> > seems unreasonable to expect maintainers to predict conflicts not coming
> > from their own tree's.
> 
> In this particular case, Stephen did fix the trivial merge conflict.  
> Most probably Linus could have done the same.  There is nothing you 
> needed to do in that case.  Or you could have waited until RMK's tree 
> hits mainline, then you merge that, fixing the issue within that merge, 
> before asking Linus to pull.
> 
> And if the merge in linux-next turned out not to be that trivial, or you 
> have new machine entries in your tree that failed to compile due to the 
> missing fixup, well that's fine too because that's _exactly_ what the 
> purpose of the linux-next tree is: finding issues like this before the 
> real merge in Linus' tree.  So in this case the system did work: the 
> conflict was identified by the tool and you were notified.
> 
> And the simplest solution to this is simply to merge your stuff into 
> RMK's tree in this case, so the generic change affecting all ARM 
> machines will cover yours as well.  Incidentally that's what has been 
> asked of you.
> 
> See?  Nothing to really get excited about.

Am I excited? Russell is the one getting excited .. I was the one trying
to correct the issues , so Linus doesn't have to deal with it.

Daniel

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

[Arnd Bergmann]

On Tuesday 19 October 2010, Joe Perches wrote:
> This could have been done:
> 
> $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> 35
> 
> Even then, using 35 CCs is generally silly.
> 
> It might make some sense for a cover letter and a
> patch series where the series made tree-wide changes
> in multiple directories.

Probably not even then: When a single mail header gets too long, you usually land
in some spam filter and get hate mail from the list owners. The lkml limit is 1024
characters (this may come from an official RFC, don't know), which is usually less
than 35 recipients.

	Arnd

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> I can say that I know for a fact that people don't read every patch, or
> every email, or keep track of every single thread. I don't think it's
> reasonable to expect people to do that. there's too many email, too many
> threads, too many discussions etc ..

I'm not saying that you should keep track of every threads.  But you 
should at least pay attention to what thread is being discussed, simply 
by looking at the subject line.  Any good MUA will let you sort emails 
and collapse them into thread view.  And scoring those incoming emails 
with "arch/arm/mach-msm" for example is a quick way for you to be 
noticed when a patch might be changing something in your area.  Tools 
are there for you.

> This discussion isn't really about that. It's not about people reading
> every single patch, which we know they don't do. This is about conflicts
> in -next.

Glad to get back to the original issue.

> These patches caused conflicts in -next .. What more could I have done
> to prevent conflicts coming from another tree and patches that appear
> not to effect me? Even if I read all the patches, and threads, it still
> seems unreasonable to expect maintainers to predict conflicts not coming
> from their own tree's.

In this particular case, Stephen did fix the trivial merge conflict.  
Most probably Linus could have done the same.  There is nothing you 
needed to do in that case.  Or you could have waited until RMK's tree 
hits mainline, then you merge that, fixing the issue within that merge, 
before asking Linus to pull.

And if the merge in linux-next turned out not to be that trivial, or you 
have new machine entries in your tree that failed to compile due to the 
missing fixup, well that's fine too because that's _exactly_ what the 
purpose of the linux-next tree is: finding issues like this before the 
real merge in Linus' tree.  So in this case the system did work: the 
conflict was identified by the tool and you were notified.

And the simplest solution to this is simply to merge your stuff into 
RMK's tree in this case, so the generic change affecting all ARM 
machines will cover yours as well.  Incidentally that's what has been 
asked of you.

See?  Nothing to really get excited about.


Nicolas

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

[Daniel Walker]

On Mon, 2010-10-18 at 19:32 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
> 
> > On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:
> > 
> > > > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> > > >      58     163    2169
> > > > 
> > > > That's the patch we're actually discussing too. It's about one CC per
> > > > file modified.
> > > 
> > > What is a mailing list for, then?  Why are you subscribed?
> > 
> > I'm subscribes to review code .. Do you read every patch that cross the
> > arm list?
> 
> No, But I do read every email subject, and most patch messages.  Only 
> those subjects I know for sure I have no interest in I do delete right 
> away.
> 
> And being a human I sometimes screw up and let something I should have 
> paid attention fall through the cracks.  When that happens I simply fix 
> the issue after the fact and send a patch, and then life goes on.
> 
> If you don't want to actually follow the mailing list traffic, you can 
> at least filter it by flagging those messages that contain a patch which 
> touches one of those files you do care about.

I can say that I know for a fact that people don't read every patch, or
every email, or keep track of every single thread. I don't think it's
reasonable to expect people to do that. there's too many email, too many
threads, too many discussions etc ..

This discussion isn't really about that. It's not about people reading
every single patch, which we know they don't do. This is about conflicts
in -next.

These patches caused conflicts in -next .. What more could I have done
to prevent conflicts coming from another tree and patches that appear
not to effect me? Even if I read all the patches, and threads, it still
seems unreasonable to expect maintainers to predict conflicts not coming
from their own tree's.

Daniel

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:
> 
> > > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> > >      58     163    2169
> > > 
> > > That's the patch we're actually discussing too. It's about one CC per
> > > file modified.
> > 
> > What is a mailing list for, then?  Why are you subscribed?
> 
> I'm subscribes to review code .. Do you read every patch that cross the
> arm list?

No, But I do read every email subject, and most patch messages.  Only 
those subjects I know for sure I have no interest in I do delete right 
away.

And being a human I sometimes screw up and let something I should have 
paid attention fall through the cracks.  When that happens I simply fix 
the issue after the fact and send a patch, and then life goes on.

If you don't want to actually follow the mailing list traffic, you can 
at least filter it by flagging those messages that contain a patch which 
touches one of those files you do care about.


Nicolas

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

[Daniel Walker]

On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:

> > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> >      58     163    2169
> > 
> > That's the patch we're actually discussing too. It's about one CC per
> > file modified.
> 
> What is a mailing list for, then?  Why are you subscribed?

I'm subscribes to review code .. Do you read every patch that cross the
arm list?


Daniel

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

[Joe Perches]

On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> > > On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > > > That's why we have get_maintainer.pl, it adds in all the CC's
> > > > automatically ..
> > > $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc 
> > >     209     624    8021
> > > 209 recipients / 8K of To:/CC: is reasonable?
> > What it's showing you is anyone that's ever modified those files.. You
> > just need the people who maintain the files.
> > how about this,
> > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> >      58     163    2169
> > That's the patch we're actually discussing too. It's about one CC per
> > file modified.
> What is a mailing list for, then?  Why are you subscribed?
> Please get real or get away.

Too true.  The patch is entirely for arch/arm and
relatively few if any maintainers need to be cc'd.

This could have been done:

$ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
35

Even then, using 35 CCs is generally silly.

It _might_ make some sense for a cover letter and a
patch series where the series made tree-wide changes
in multiple directories.

Even so, lkml will sensibly reject emails with more
than a couple dozen CC's as likely spam.

For cover letters, I generally use:

	./scripts/get_maintainer.pl --nom -l --nogit

and for each patch in a series

	./scripts/get_maintainer.pl --no-git

There is a change in the get_maintainers.pl in Andrew
Morton's mm tree to default to --nogit.

The new get_maintainer.pl is available from:
	git://repo.or.cz/linux-2.6/get_maintainer.git 20100922_gm 
Have a look at:
	http://repo.or.cz/w/linux-2.6/get_maintainer.git

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > > That's why we have get_maintainer.pl, it adds in all the CC's
> > > automatically ..
> > 
> > $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc 
> >     209     624    8021
> > 
> > 209 recipients / 8K of To:/CC: is reasonable?
> 
> 
> The answer is not "The tool doesn't work like I want, so screw it." If
> the tool doesn't work like we want, then we need to fix the tool not
> just walk away. Not to mention that the people involved in making these
> patches should still be CC'ing people even if this tool is just helping
> them out instead of actually doing it for them.
> 
> What it's showing you is anyone that's ever modified those files.. You
> just need the people who maintain the files.
> 
> how about this,
> 
> git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
>      58     163    2169
> 
> That's the patch we're actually discussing too. It's about one CC per
> file modified.

What is a mailing list for, then?  Why are you subscribed?

Please get real or get away.


Nicolas

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

[Daniel Walker]

On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > That's why we have get_maintainer.pl, it adds in all the CC's
> > automatically ..
> 
> $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc 
>     209     624    8021
> 
> 209 recipients / 8K of To:/CC: is reasonable?


The answer is not "The tool doesn't work like I want, so screw it." If
the tool doesn't work like we want, then we need to fix the tool not
just walk away. Not to mention that the people involved in making these
patches should still be CC'ing people even if this tool is just helping
them out instead of actually doing it for them.

What it's showing you is anyone that's ever modified those files.. You
just need the people who maintain the files.

how about this,

git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
     58     163    2169

That's the patch we're actually discussing too. It's about one CC per
file modified.

Daniel

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

[Russell King]

On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> That's why we have get_maintainer.pl, it adds in all the CC's
> automatically ..

$ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc 
    209     624    8021

209 recipients / 8K of To:/CC: is reasonable?

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

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

[Daniel Walker]

On Mon, 2010-10-18 at 17:17 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
> 
> > I guess your assuming I send my pull request after Russell's, which
> > isn't necessarily true, and I'd rather not have that dependency if I
> > don't have to. 
> 
> Look, we're not establishing a straight rule here -- just figuring out a 
> way to move forward.  What we're asking you to do is either ask RMK to 
> pull your tree now, or wait until RMK's tree has hit mainline so you can 
> pull Linus' tree and fix the issue yourself before asking Linus to pull, 
> or whatever.  Is some collaboration on your part for this particular 
> issue too much to ask for?

I'm always very cooperative, if you read back in the thread I basically
suggested I would be sending a pull request to Russell. That was prior
to Arnd'd comments.

Daniel

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

[Daniel Walker]

On Mon, 2010-10-18 at 21:58 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 01:12:54PM -0700, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> > 
> > > > Ok, well in that case why not accept this immediately after the merge
> > > > window? A point when everything is quiet, and most of the tree's are
> > > > empty?
> > > 
> > > RMK has his own merge window which closes about at the same time as 
> > > Linus' one opens.  We thought this was happening last week and therefore 
> > > this change was supposed to be the last one.
> > 
> > It seems like that could potentially make these kinds of problem worse,
> > since your merging things immediately before sending them to Linus. Like
> > right now we only have a fairly short amount of time to correct this
> > conflict. 
> 
> What I would like to do in an ideal world is stop merging stuff into my
> tree one week before the merge window opens precisely so that people can
> regression test it.  If I were to conform to that, I'd be saying "tough,
> it's your problem" right now.  Why?
> 
> This change has been discussed at length on the linux-arm-kernel mailing
> list, where patches have been posted and reviewed for it several times
> since July:
> 
> 	http://marc.info/?l=linux-arm-kernel&w=2&r=1&s=late+mdesc&q=b
> 
> In September it became ready for merging, and this is what I said:
> 
> 	http://marc.info/?l=linux-arm-kernel&m=128332699032679&w=2
> 
> So, there should be absolutely no surprise over it, except from people
> who ignore what's going on in the generic ARM world.  No, you can't
> expect people to copy every single board maintainer - we have something
> like 300 odd board files with various maintainers.  It's one of the
> reasons that we have mailing lists.

That's why we have get_maintainer.pl, it adds in all the CC's
automatically .. I can notice the thread on the list, but I have no idea
it's modifying my tree unless I examine every patch's diffstat .. To me
it's way more reasonable to ask the patch author to get the CC's right.
That way we all get active notification when something is modifying our
tree's ..

> What I should be saying at this point is "tough, you've got a problem"
> but I won't.  I've rewound my tree to drop these changes, because it
> seems several people need more time.  You have it - until Tuesday - when
> Nicolas will re-do his patch set on top of whatever my tree is at that
> point.
> 
> If you haven't sent me a pull request by Tuesday[*] evening my time, it
> becomes _your_ problem to fix the resulting breakage.  A warning: make
> sure your tree is not based on my devel branch - it's regressed to
> 'unstable' state because of this.
> 

Ok ..

Daniel

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> I guess your assuming I send my pull request after Russell's, which
> isn't necessarily true, and I'd rather not have that dependency if I
> don't have to. 

Look, we're not establishing a straight rule here -- just figuring out a 
way to move forward.  What we're asking you to do is either ask RMK to 
pull your tree now, or wait until RMK's tree has hit mainline so you can 
pull Linus' tree and fix the issue yourself before asking Linus to pull, 
or whatever.  Is some collaboration on your part for this particular 
issue too much to ask for?


Nicolas

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> I think the term "merge window" is a little mis-leading here.. Your
> describing development. To me the term merge window is indicating a
> short period when you get changes in, not the whole -rc cycle.

There are overlaps.  The two-week merge window is for subsystem 
maintainers to push their stuff to Linus.  Obviously those subsystem 
maintainers must have merge windows of their own prior pushing their 
tree to Linus.  This is a pipeline.

And folks let's not get too excited about this.  The idea of having this 
change at the end of RMK's merge window is to catch most (if not all) 
ARM targets being affected.  Last time I checked this affected something 
like 367 machines.  This is not a catastrophic issue if support for one 
or two machines get merged outside of RMK's tree and a build error 
happens for them once in Linus' tree.  The fix should be obvious and the 
-rc period is long enough to fix those things.  Or the merge actually 
flags a conflict that should be trivial to fix as Stephen did in 
linux-next.

Merge conflicts do happen.  If those conflicts remain small and trivial 
this is _fine_.


Nicolas

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

[Daniel Walker]

On Mon, 2010-10-18 at 22:48 +0200, Arnd Bergmann wrote:
> On Monday 18 October 2010 22:37:31 Daniel Walker wrote:
> > > When you know that Russell does not rebase his tree, you can pull his
> > > tree into yours whenever a change hits his tree that impacts you in
> > > a major way. You shouldn't do this too frequently, but it's a good way
> > > to resolve conflicts like this one.
> > 
> > If I did that all of Russell's changesets would get mixed with mine when
> > I send the pull request .. That would just create confusion .. It's OK
> > if Russell sends my commits to Linus, but I'm not going to send
> > Russell's commits.
> 
> Actually both are ok, as long as you as the sub-maintainer send your
> pull request after Russell's tree has been merged and you don't
> ask anyone else to pull your tree who has not pulled Russell's tree
> explicitly or implicitly through Linus.
> 
> git-request-pull is smart enough to list only the changesets that
> are not in the upstream tree, as will git "log your-branch...upstream"
> or "git diff your-branch upstream".

I guess your assuming I send my pull request after Russell's, which
isn't necessarily true, and I'd rather not have that dependency if I
don't have to. 

Even with a one time event what your suggesting seems like it would be
some what freaky. I wouldn't want to wait around for Russell to get his
tree merged before I can get a reasonable log of my own activities
(without jumping through hoops).

Of course I could do what your suggesting, I just don't think it's the
easiest way to fix this.

Daniel

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

[Russell King]

On Mon, Oct 18, 2010 at 01:12:54PM -0700, Daniel Walker wrote:
> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> 
> > > Ok, well in that case why not accept this immediately after the merge
> > > window? A point when everything is quiet, and most of the tree's are
> > > empty?
> > 
> > RMK has his own merge window which closes about at the same time as 
> > Linus' one opens.  We thought this was happening last week and therefore 
> > this change was supposed to be the last one.
> 
> It seems like that could potentially make these kinds of problem worse,
> since your merging things immediately before sending them to Linus. Like
> right now we only have a fairly short amount of time to correct this
> conflict. 

What I would like to do in an ideal world is stop merging stuff into my
tree one week before the merge window opens precisely so that people can
regression test it.  If I were to conform to that, I'd be saying "tough,
it's your problem" right now.  Why?

This change has been discussed at length on the linux-arm-kernel mailing
list, where patches have been posted and reviewed for it several times
since July:

	http://marc.info/?l=linux-arm-kernel&w=2&r=1&s=late+mdesc&q=b

In September it became ready for merging, and this is what I said:

	http://marc.info/?l=linux-arm-kernel&m=128332699032679&w=2

So, there should be absolutely no surprise over it, except from people
who ignore what's going on in the generic ARM world.  No, you can't
expect people to copy every single board maintainer - we have something
like 300 odd board files with various maintainers.  It's one of the
reasons that we have mailing lists.

What I should be saying at this point is "tough, you've got a problem"
but I won't.  I've rewound my tree to drop these changes, because it
seems several people need more time.  You have it - until Tuesday - when
Nicolas will re-do his patch set on top of whatever my tree is at that
point.

If you haven't sent me a pull request by Tuesday[*] evening my time, it
becomes _your_ problem to fix the resulting breakage.  A warning: make
sure your tree is not based on my devel branch - it's regressed to
'unstable' state because of this.

You have the opportunity to sort this out avoiding conflicts and bisect
problems.  I suggest you take advantage of that.  But don't expect me
to keep on making these kinds of concessions.

* - I really don't like making deadlines for Tuesdays and Wednesdays
because I tend to only be around in the evening - but there is no option.
So don't expect something which arrives here at midnight Tuesday to get
merged.

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

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> 
> > RMK has his own merge window which closes about at the same time as 
> > Linus' one opens.  We thought this was happening last week and therefore 
> > this change was supposed to be the last one.
> 
> I guess what I'm missing here is when does this window open? Is it a two
> week deal, or does it last the whole -rc cycle?

Linus' merge window is indeed the two-week thing.  No one can predict 
with certainty when it'll happen, as demonstrated by our merging of the 
debug macro in RMK's tree last week based on the presumption that we 
would be in the two-week merge now.


Nicolas

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

[Arnd Bergmann]

On Monday 18 October 2010 22:37:31 Daniel Walker wrote:
> > When you know that Russell does not rebase his tree, you can pull his
> > tree into yours whenever a change hits his tree that impacts you in
> > a major way. You shouldn't do this too frequently, but it's a good way
> > to resolve conflicts like this one.
> 
> If I did that all of Russell's changesets would get mixed with mine when
> I send the pull request .. That would just create confusion .. It's OK
> if Russell sends my commits to Linus, but I'm not going to send
> Russell's commits.

Actually both are ok, as long as you as the sub-maintainer send your
pull request after Russell's tree has been merged and you don't
ask anyone else to pull your tree who has not pulled Russell's tree
explicitly or implicitly through Linus.

git-request-pull is smart enough to list only the changesets that
are not in the upstream tree, as will git "log your-branch...upstream"
or "git diff your-branch upstream".

The other option you have is to ask Russell to pull your tree
at an early enough time, which also works if you did the occasional
pull from him before that.

	Arnd

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

[Daniel Walker]

On Mon, 2010-10-18 at 22:19 +0200, Arnd Bergmann wrote:
> On Monday 18 October 2010 22:12:54 Daniel Walker wrote:
> > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> > 
> > > > Ok, well in that case why not accept this immediately after the merge
> > > > window? A point when everything is quiet, and most of the tree's are
> > > > empty?
> > > 
> > > RMK has his own merge window which closes about at the same time as 
> > > Linus' one opens.  We thought this was happening last week and therefore 
> > > this change was supposed to be the last one.
> > 
> > It seems like that could potentially make these kinds of problem worse,
> > since your merging things immediately before sending them to Linus. Like
> > right now we only have a fairly short amount of time to correct this
> > conflict. 
> 
> What Nicolas was talking about is the *end* of the merge window, not the
> start. This is how all sensible maintainer trees work: you get to
> merge stuff into the maintainer tree for a number of weeks (some start
> at -rc1, other start a bit later). When Linus tells people to get ready
> for the release, the subsystem goes into regression fix mode and when
> Linus opens his merge window, everything should be reasonably stable.

I think the term "merge window" is a little mis-leading here.. Your
describing development. To me the term merge window is indicating a
short period when you get changes in, not the whole -rc cycle.

> > > > Well how about I merge this change into my tree ?
> > > 
> > > If you ask RMK to merge your tree in his that would be much simpler to 
> > > add this change in a single pass afterwards.
> > 
> > I can do that , but would I still be able to merge stuff into my tree?
> > Seems like I could, Russell would just clean up the conflict and my tree
> > would just move forward like it has been already , and I would send the
> > whole thing to Linus.
> 
> When you know that Russell does not rebase his tree, you can pull his
> tree into yours whenever a change hits his tree that impacts you in
> a major way. You shouldn't do this too frequently, but it's a good way
> to resolve conflicts like this one.

If I did that all of Russell's changesets would get mixed with mine when
I send the pull request .. That would just create confusion .. It's OK
if Russell sends my commits to Linus, but I'm not going to send
Russell's commits.

Daniel

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

[Daniel Walker]

On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:

> RMK has his own merge window which closes about at the same time as 
> Linus' one opens.  We thought this was happening last week and therefore 
> this change was supposed to be the last one.

I guess what I'm missing here is when does this window open? Is it a two
week deal, or does it last the whole -rc cycle?

Daniel

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

[Arnd Bergmann]

On Monday 18 October 2010 22:12:54 Daniel Walker wrote:
> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> 
> > > Ok, well in that case why not accept this immediately after the merge
> > > window? A point when everything is quiet, and most of the tree's are
> > > empty?
> > 
> > RMK has his own merge window which closes about at the same time as 
> > Linus' one opens.  We thought this was happening last week and therefore 
> > this change was supposed to be the last one.
> 
> It seems like that could potentially make these kinds of problem worse,
> since your merging things immediately before sending them to Linus. Like
> right now we only have a fairly short amount of time to correct this
> conflict. 

What Nicolas was talking about is the *end* of the merge window, not the
start. This is how all sensible maintainer trees work: you get to
merge stuff into the maintainer tree for a number of weeks (some start
at -rc1, other start a bit later). When Linus tells people to get ready
for the release, the subsystem goes into regression fix mode and when
Linus opens his merge window, everything should be reasonably stable.

> > > Well how about I merge this change into my tree ?
> > 
> > If you ask RMK to merge your tree in his that would be much simpler to 
> > add this change in a single pass afterwards.
> 
> I can do that , but would I still be able to merge stuff into my tree?
> Seems like I could, Russell would just clean up the conflict and my tree
> would just move forward like it has been already , and I would send the
> whole thing to Linus.

When you know that Russell does not rebase his tree, you can pull his
tree into yours whenever a change hits his tree that impacts you in
a major way. You shouldn't do this too frequently, but it's a good way
to resolve conflicts like this one.

	Arnd

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

[Daniel Walker]

On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:

> > Ok, well in that case why not accept this immediately after the merge
> > window? A point when everything is quiet, and most of the tree's are
> > empty?
> 
> RMK has his own merge window which closes about at the same time as 
> Linus' one opens.  We thought this was happening last week and therefore 
> this change was supposed to be the last one.

It seems like that could potentially make these kinds of problem worse,
since your merging things immediately before sending them to Linus. Like
right now we only have a fairly short amount of time to correct this
conflict. 

> > Well how about I merge this change into my tree ?
> 
> If you ask RMK to merge your tree in his that would be much simpler to 
> add this change in a single pass afterwards.

I can do that , but would I still be able to merge stuff into my tree?
Seems like I could, Russell would just clean up the conflict and my tree
would just move forward like it has been already , and I would send the
whole thing to Linus.

Daniel

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

[Nicolas Pitre]

On Mon, 18 Oct 2010, Daniel Walker wrote:

> On Mon, 2010-10-18 at 19:20 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> > > On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > > > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > > > [ Just cc'ing Russell, sorry about that]
> > > > > 
> > > > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >
> > > > > > Hi Daniel,
> > > > > > 
> > > > > > Today's linux-next merge of the msm tree got a conflict in
> > > > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > > > virtual addresses from addruart") from the arm tree and commit
> > > > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > > > conditionally disabled") from the msm tree.
> > > > > > 
> > > > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > > > necessary.
> > > > 
> > > > Thanks, but I don't think there's much which can be done about these.
> > > > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > > > spread across multiple git trees...
> > > > 
> > > > I think there's going to be some problems during this forthcoming merge
> > > > window.
> > > 
> > > Would be nice to get CC'd ...
> > > 
> > > Ideally this patch should have been broken up and sent individually to
> > > each maintainer .. Then I could manage this within my own tree..
> > 
> > Err no.  It is one complete change which can't be broken up sensibly.
> > Breaking it up will mean either you lose functionality or you break
> > your build.
> 
> 
> Ok, well in that case why not accept this immediately after the merge
> window? A point when everything is quiet, and most of the tree's are
> empty?

RMK has his own merge window which closes about at the same time as 
Linus' one opens.  We thought this was happening last week and therefore 
this change was supposed to be the last one.

> Well how about I merge this change into my tree ?

If you ask RMK to merge your tree in his that would be much simpler to 
add this change in a single pass afterwards.


Nicolas

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

[Daniel Walker]

On Mon, 2010-10-18 at 19:20 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > > [ Just cc'ing Russell, sorry about that]
> > > > 
> > > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > Hi Daniel,
> > > > > 
> > > > > Today's linux-next merge of the msm tree got a conflict in
> > > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > > virtual addresses from addruart") from the arm tree and commit
> > > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > > conditionally disabled") from the msm tree.
> > > > > 
> > > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > > necessary.
> > > 
> > > Thanks, but I don't think there's much which can be done about these.
> > > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > > spread across multiple git trees...
> > > 
> > > I think there's going to be some problems during this forthcoming merge
> > > window.
> > 
> > Would be nice to get CC'd ...
> > 
> > Ideally this patch should have been broken up and sent individually to
> > each maintainer .. Then I could manage this within my own tree..
> 
> Err no.  It is one complete change which can't be broken up sensibly.
> Breaking it up will mean either you lose functionality or you break
> your build.


Ok, well in that case why not accept this immediately after the merge
window? A point when everything is quiet, and most of the tree's are
empty?

Well how about I merge this change into my tree ?

Daniel

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

[Russell King]

On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > [ Just cc'ing Russell, sorry about that]
> > > 
> > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi Daniel,
> > > > 
> > > > Today's linux-next merge of the msm tree got a conflict in
> > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > virtual addresses from addruart") from the arm tree and commit
> > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > conditionally disabled") from the msm tree.
> > > > 
> > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > 
> > Thanks, but I don't think there's much which can be done about these.
> > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > spread across multiple git trees...
> > 
> > I think there's going to be some problems during this forthcoming merge
> > window.
> 
> Would be nice to get CC'd ...
> 
> Ideally this patch should have been broken up and sent individually to
> each maintainer .. Then I could manage this within my own tree..

Err no.  It is one complete change which can't be broken up sensibly.
Breaking it up will mean either you lose functionality or you break
your build.

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

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

[Daniel Walker]

On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > [ Just cc'ing Russell, sorry about that]
> > 
> > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Daniel,
> > > 
> > > Today's linux-next merge of the msm tree got a conflict in
> > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > virtual addresses from addruart") from the arm tree and commit
> > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > conditionally disabled") from the msm tree.
> > > 
> > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > necessary.
> 
> Thanks, but I don't think there's much which can be done about these.
> Changes such as 08a610d affect all ARM sub-architectures, and as they're
> spread across multiple git trees...
> 
> I think there's going to be some problems during this forthcoming merge
> window.

Would be nice to get CC'd ...

Ideally this patch should have been broken up and sent individually to
each maintainer .. Then I could manage this within my own tree..

Daniel

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

[Russell King]

On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> [ Just cc'ing Russell, sorry about that]
> 
> On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Daniel,
> > 
> > Today's linux-next merge of the msm tree got a conflict in
> > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > virtual addresses from addruart") from the arm tree and commit
> > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > conditionally disabled") from the msm tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.

Thanks, but I don't think there's much which can be done about these.
Changes such as 08a610d affect all ARM sub-architectures, and as they're
spread across multiple git trees...

I think there's going to be some problems during this forthcoming merge
window.

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

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

[Stephen Rothwell]

[ Just cc'ing Russell, sorry about that]

On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Daniel,
> 
> Today's linux-next merge of the msm tree got a conflict in
> arch/arm/mach-msm/include/mach/debug-macro.S between commit
> 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> virtual addresses from addruart") from the arm tree and commit
> 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> conditionally disabled") from the msm 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-msm/include/mach/debug-macro.S
> index 3c35b0d,238c4f1..0000000
> --- a/arch/arm/mach-msm/include/mach/debug-macro.S
> +++ b/arch/arm/mach-msm/include/mach/debug-macro.S
> @@@ -19,11 -19,13 +19,11 @@@
>   #include <mach/hardware.h>
>   #include <mach/msm_iomap.h>
>   
> - #ifdef CONFIG_MSM_DEBUG_UART
> + #ifdef CONFIG_HAS_MSM_DEBUG_UART_PHYS
>  -	.macro	addruart, rx, tmp
>  +	.macro	addruart, rp, rv
>   	@ see if the MMU is enabled and select appropriate base address
>  -	mrc	p15, 0, \rx, c1, c0
>  -	tst	\rx, #1
>  -	ldreq	\rx, =MSM_DEBUG_UART_PHYS
>  -	ldrne	\rx, =MSM_DEBUG_UART_BASE
>  +	ldr	\rp, =MSM_DEBUG_UART_PHYS
>  +	ldr	\rv, =MSM_DEBUG_UART_BASE
>   	.endm
>   
>   	.macro	senduart,rd,rx

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

[Stephen Rothwell]

Hi Daniel,

Today's linux-next merge of the msm tree got a conflict in
arch/arm/mach-msm/include/mach/debug-macro.S between commit
08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
virtual addresses from addruart") from the arm tree and commit
46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
conditionally disabled") from the msm 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-msm/include/mach/debug-macro.S
index 3c35b0d,238c4f1..0000000
--- a/arch/arm/mach-msm/include/mach/debug-macro.S
+++ b/arch/arm/mach-msm/include/mach/debug-macro.S
@@@ -19,11 -19,13 +19,11 @@@
  #include <mach/hardware.h>
  #include <mach/msm_iomap.h>
  
- #ifdef CONFIG_MSM_DEBUG_UART
+ #ifdef CONFIG_HAS_MSM_DEBUG_UART_PHYS
 -	.macro	addruart, rx, tmp
 +	.macro	addruart, rp, rv
  	@ see if the MMU is enabled and select appropriate base address
 -	mrc	p15, 0, \rx, c1, c0
 -	tst	\rx, #1
 -	ldreq	\rx, =MSM_DEBUG_UART_PHYS
 -	ldrne	\rx, =MSM_DEBUG_UART_BASE
 +	ldr	\rp, =MSM_DEBUG_UART_PHYS
 +	ldr	\rv, =MSM_DEBUG_UART_BASE
  	.endm
  
  	.macro	senduart,rd,rx

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

[Stephen Rothwell]

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

Hi Daniel,

On Tue, 04 May 2010 09:42:13 -0700 Daniel Walker <dwalker@codeaurora.org> wrote:
>
> On Tue, 2010-05-04 at 11:07 +1000, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the msm tree got a conflict in
> > arch/arm/mach-msm/Kconfig between commit
> > 4b53eb4f5d78416456bb969ce30e3bed2731d744 ("arm: msm: allow ARCH_MSM to
> > have v7 cpus") from the arm tree and commit
> > e17047ea51cc2eac3e920e5a669f99efd44f446f ("arm: msm: smd: use either
> > package v3 or v4 not both") from the msm tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> Ok .. I'll merge the changes in Russell tree into my tree, that should
> fix it I think.

OK, thanks.  For simple things like this, I have no problem carrying
fixes until they are repaired in the normal course of events.  "git
rerere" does all the work for me.

-- 
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 msm tree with the arm tree

[Daniel Walker]

On Tue, 2010-05-04 at 11:07 +1000, Stephen Rothwell wrote:
> Hi Daniel,
> 
> Today's linux-next merge of the msm tree got a conflict in
> arch/arm/mach-msm/Kconfig between commit
> 4b53eb4f5d78416456bb969ce30e3bed2731d744 ("arm: msm: allow ARCH_MSM to
> have v7 cpus") from the arm tree and commit
> e17047ea51cc2eac3e920e5a669f99efd44f446f ("arm: msm: smd: use either
> package v3 or v4 not both") from the msm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Ok .. I'll merge the changes in Russell tree into my tree, that should
fix it I think.

Daniel

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

[Stephen Rothwell]

Hi Daniel,

Today's linux-next merge of the msm tree got a conflict in
arch/arm/mach-msm/Kconfig between commit
4b53eb4f5d78416456bb969ce30e3bed2731d744 ("arm: msm: allow ARCH_MSM to
have v7 cpus") from the arm tree and commit
e17047ea51cc2eac3e920e5a669f99efd44f446f ("arm: msm: smd: use either
package v3 or v4 not both") from the msm 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-msm/Kconfig
index b9fd5c5,69cc693..0000000
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@@ -28,15 -45,14 +45,16 @@@ choic
  endchoice
  
  config MACH_HALIBUT
- 	depends on ARCH_MSM
+ 	depends on ARCH_MSM7X00A
 +	select CPU_V6
  	default y
  	bool "Halibut Board (QCT SURF7201A)"
  	help
  	  Support for the Qualcomm SURF7201A eval board.
  
  config MACH_TROUT
+ 	depends on ARCH_MSM7X00A
 +	select CPU_V6
  	default y
  	bool "HTC Dream (aka trout)"
  	help