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

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

[Stephen Rothwell]

Hi Russell,

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

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

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

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

[H Hartley Sweeten]

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

Russell,

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

Regards,
Hartley

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

[Stephen Rothwell]

Hi Russell,

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

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

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

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

[Eric Miao]

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

Hi Stephen,

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

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

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

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

[Stephen Rothwell]

Hi Russell,

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

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

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

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

[Linus Walleij]

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

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

The fix is correct, thanks Stephen.

Yours,
Linus Walleij

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Ingo Molnar]

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

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

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

That approach would also avoid conflicts as a side effect.

Thanks,

	Ingo

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

[Russell King]

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

Please check your mailbox:

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

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

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

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

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

[Ingo Molnar]

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

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

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

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

Thanks,

	Ingo

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

[Russell King]

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

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

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

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

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

[Ingo Molnar]

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

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

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

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

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

Let me quote PeterZ again:

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

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

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

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

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

You never replied to PeterZ that I can see.

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

Thanks,

	Ingo

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

[Russell King]

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

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

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

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

[Ingo Molnar]

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

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

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

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

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

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

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

Thanks,

	Ingo

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

[Russell King]

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

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

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

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

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

[Ingo Molnar]

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

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

He provided it via email to lkml:

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

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

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

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

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

Thanks,

	Ingo

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

[Russell King]

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

Hi Russell,

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

Thanks,

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

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

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

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

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

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

[Russell King]

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

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

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

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

[Stephen Rothwell]

Hi Russell,

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

  drivers/gpu/drm/rockchip/rockchip_drm_drv.c

between commit:

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

from Linus' tree and commit:

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

from the arm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Russell King]

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

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

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

Thanks anyway.

-- 
Russell King
ARM architecture Linux Kernel maintainer

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm/boot/compressed/head.S

between commit:

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

from Linus' tree and commit:

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

from the arm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Russell King - ARM Linux admin]

Ard,

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

Thanks.

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



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

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

[Ard Biesheuvel]

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

Sorry for that.

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



The following changes since commit d0f9ca9be11f25ef4151195eab7ea36d136084f6:

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

are available in the Git repository at:

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

for you to fetch changes up to 5aa87eb1b4e3f1b50ee4a42e8cd933d3d39927b3:

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

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

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

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

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

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

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


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

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

[Russell King - ARM Linux admin]

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

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

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

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

[Ard Biesheuvel]

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

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

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

[Russell King - ARM Linux admin]

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

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

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

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

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

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

[Stephen Rothwell]

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

Hi Russell,

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

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

-- 
Cheers,
Stephen Rothwell

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

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

[Ard Biesheuvel]

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

That was not clear to me.

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

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

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

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

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

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm/kernel/traps.c

between commit:

  04e91b732476 ("ARM: early traps initialisation")

from Linus' tree and commits:

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

from the arm tree.

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

-- 
Cheers,
Stephen Rothwell

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

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