Re: linux-next: manual merge of the powerpc tree with the mm-stable tree

[Michael Ellerman]

Christophe Leroy  writes:
> Le 29/02/2024 à 07:37, Michael Ellerman a écrit :
>> Stephen Rothwell  writes:
>>> Hi all,
>>>
>>> Today's linux-next merge of the powerpc tree got a conflict in:
>>>
>>>arch/powerpc/mm/pgtable_32.c
>>>
>>> between commit:
>>>
>>>a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor 
>>> CONFIG_DEBUG_WX")
>>>
>>> from the mm-stable tree and commit:
>>>
>>>8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and 
>>> mark_initmem_nx()")
>>>
>>> from the powerpc tree.
>> 
>> Thanks. That's a fairly ugly conflict.
>> 
>> Maybe I'll drop that patch until the generic change has gone in.
>> 
>
> The change is now in linus tree.

Thanks. I have moved my next up and applied your v2 on top of the
upstream changes.

cheers

Re: linux-next: manual merge of the powerpc tree with the mm-stable tree

[Christophe Leroy]

Le 29/02/2024 à 07:37, Michael Ellerman a écrit :
> Stephen Rothwell  writes:
>> Hi all,
>>
>> Today's linux-next merge of the powerpc tree got a conflict in:
>>
>>arch/powerpc/mm/pgtable_32.c
>>
>> between commit:
>>
>>a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor 
>> CONFIG_DEBUG_WX")
>>
>> from the mm-stable tree and commit:
>>
>>8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and 
>> mark_initmem_nx()")
>>
>> from the powerpc tree.
> 
> Thanks. That's a fairly ugly conflict.
> 
> Maybe I'll drop that patch until the generic change has gone in.
> 

The change is now in linus tree.

Christophe

Re: linux-next: manual merge of the powerpc tree with the mm-stable tree

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/mm/pgtable_32.c
>
> between commit:
>
>   a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor 
> CONFIG_DEBUG_WX")
>
> from the mm-stable tree and commit:
>
>   8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and 
> mark_initmem_nx()")
>
> from the powerpc tree.

Thanks. That's a fairly ugly conflict.

Maybe I'll drop that patch until the generic change has gone in.

cheers

linux-next: manual merge of the powerpc tree with the mm-stable tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/mm/pgtable_32.c

between commit:

  a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor 
CONFIG_DEBUG_WX")

from the mm-stable tree and commit:

  8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and 
mark_initmem_nx()")

from the powerpc 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/powerpc/mm/pgtable_32.c
index 12498017da8e,4be97b4a44f9..
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@@ -164,21 -174,17 +174,14 @@@ static int __mark_rodata_ro(void
numpages = PFN_UP((unsigned long)__end_rodata) -
   PFN_DOWN((unsigned long)_stext);
  
-   set_memory_ro((unsigned long)_stext, numpages);
+   return set_memory_ro((unsigned long)_stext, numpages);
+ }
+ 
+ void mark_rodata_ro(void)
+ {
+   int err = __mark_rodata_ro();
+ 
+   if (err)
+   panic("%s() failed, err = %d\n", __func__, err);
 -
 -  // mark_initmem_nx() should have already run by now
 -  ptdump_check_wx();
  }
  #endif
- 
- #if defined(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC) && 
defined(CONFIG_DEBUG_PAGEALLOC)
- void __kernel_map_pages(struct page *page, int numpages, int enable)
- {
-   unsigned long addr = (unsigned long)page_address(page);
- 
-   if (PageHighMem(page))
-   return;
- 
-   if (enable)
-   set_memory_p(addr, numpages);
-   else
-   set_memory_np(addr, numpages);
- }
- #endif /* CONFIG_DEBUG_PAGEALLOC */


pgpHYuNol7Vdi.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the mm-stable tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/Kconfig

between commit:

  8d05554dca2a ("powerpc: mm: convert to GENERIC_IOREMAP")

from the mm-stable tree and commit:

  0ceef6e99cc3 ("powerpc/idle: Add support for nohlt")

from the powerpc 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/powerpc/Kconfig
index 21edd664689e,c831e20cf40f..
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -195,7 -194,7 +196,8 @@@ config PP
select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
select GENERIC_EARLY_IOREMAP
select GENERIC_GETTIMEOFDAY
+   select GENERIC_IDLE_POLL_SETUP
 +  select GENERIC_IOREMAP
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAPif PCI


pgpgMePaKLYzL.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

On Tue, 4 Oct 2022 09:16:06 +1100 Stephen Rothwell  
wrote:
> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/Makefile
> 
> between commit:
> 
>   ce697ccee1a8 ("kbuild: remove head-y syntax")
> 
> from the kbuild tree and commit:
> 
>   dfc3095cec27 ("powerpc: Remove CONFIG_FSL_BOOKE")
> 
> from the powerpc tree.
> 
> I fixed it up (I used the former version of this file and added the
> following merge fix patch) 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.
> 
> From: Stephen Rothwell 
> Date: Tue, 4 Oct 2022 09:13:46 +1100
> Subject: [PATCH] powerpc: fix up for "kbuild: remove head-y syntax"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  scripts/head-object-list.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
> index dd2ba2eda636..e8219d65c3b7 100644
> --- a/scripts/head-object-list.txt
> +++ b/scripts/head-object-list.txt
> @@ -34,7 +34,7 @@ arch/powerpc/kernel/head_44x.o
>  arch/powerpc/kernel/head_64.o
>  arch/powerpc/kernel/head_8xx.o
>  arch/powerpc/kernel/head_book3s_32.o
> -arch/powerpc/kernel/head_fsl_booke.o
> +arch/powerpc/kernel/head_85xx.o
>  arch/powerpc/kernel/entry_64.o
>  arch/powerpc/kernel/fpu.o
>  arch/powerpc/kernel/vector.o
> -- 
> 2.35.1

This is now a conflict between the kbuild tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpeDYsObCPkm.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

On Tue, 4 Oct 2022 09:12:05 +1100 Stephen Rothwell  
wrote:
> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/kernel/Makefile
> 
> between commit:
> 
>   321648455061 ("kbuild: use obj-y instead extra-y for objects placed at the 
> head")
> 
> from the kbuild tree and commit:
> 
>   dfc3095cec27 ("powerpc: Remove CONFIG_FSL_BOOKE")
> 
> from the powerpc 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/powerpc/kernel/Makefile
> index ad3decb9f20b,1f121c188805..
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@@ -118,12 -116,12 +116,12 @@@ obj-$(CONFIG_PPC_E500)+= 
> cpu_setup_e5
>   obj-$(CONFIG_PPC_DOORBELL)  += dbell.o
>   obj-$(CONFIG_JUMP_LABEL)+= jump_label.o
>   
>  -extra-$(CONFIG_PPC64)   := head_64.o
>  -extra-$(CONFIG_PPC_BOOK3S_32)   := head_book3s_32.o
>  -extra-$(CONFIG_40x) := head_40x.o
>  -extra-$(CONFIG_44x) := head_44x.o
>  -extra-$(CONFIG_PPC_85xx):= head_85xx.o
>  -extra-$(CONFIG_PPC_8xx) := head_8xx.o
>  +obj-$(CONFIG_PPC64) += head_64.o
>  +obj-$(CONFIG_PPC_BOOK3S_32) += head_book3s_32.o
>  +obj-$(CONFIG_40x)   += head_40x.o
>  +obj-$(CONFIG_44x)   += head_44x.o
> - obj-$(CONFIG_FSL_BOOKE) += head_fsl_booke.o
> ++obj-$(CONFIG_PPC_85xx)  := head_85xx.o
>  +obj-$(CONFIG_PPC_8xx)   += head_8xx.o
>   extra-y += vmlinux.lds
>   
>   obj-$(CONFIG_RELOCATABLE)   += reloc_$(BITS).o

This is now a conflict between the kbuild tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpS0cjOjzLOa.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/Makefile

between commit:

  ce697ccee1a8 ("kbuild: remove head-y syntax")

from the kbuild tree and commit:

  dfc3095cec27 ("powerpc: Remove CONFIG_FSL_BOOKE")

from the powerpc tree.

I fixed it up (I used the former version of this file and added the
following merge fix patch) 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.

From: Stephen Rothwell 
Date: Tue, 4 Oct 2022 09:13:46 +1100
Subject: [PATCH] powerpc: fix up for "kbuild: remove head-y syntax"

Signed-off-by: Stephen Rothwell 
---
 scripts/head-object-list.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
index dd2ba2eda636..e8219d65c3b7 100644
--- a/scripts/head-object-list.txt
+++ b/scripts/head-object-list.txt
@@ -34,7 +34,7 @@ arch/powerpc/kernel/head_44x.o
 arch/powerpc/kernel/head_64.o
 arch/powerpc/kernel/head_8xx.o
 arch/powerpc/kernel/head_book3s_32.o
-arch/powerpc/kernel/head_fsl_booke.o
+arch/powerpc/kernel/head_85xx.o
 arch/powerpc/kernel/entry_64.o
 arch/powerpc/kernel/fpu.o
 arch/powerpc/kernel/vector.o
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell


pgpc_loXHWhAe.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/Makefile

between commit:

  321648455061 ("kbuild: use obj-y instead extra-y for objects placed at the 
head")

from the kbuild tree and commit:

  dfc3095cec27 ("powerpc: Remove CONFIG_FSL_BOOKE")

from the powerpc 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/powerpc/kernel/Makefile
index ad3decb9f20b,1f121c188805..
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@@ -118,12 -116,12 +116,12 @@@ obj-$(CONFIG_PPC_E500)  += cpu_setup_e5
  obj-$(CONFIG_PPC_DOORBELL)+= dbell.o
  obj-$(CONFIG_JUMP_LABEL)  += jump_label.o
  
 -extra-$(CONFIG_PPC64) := head_64.o
 -extra-$(CONFIG_PPC_BOOK3S_32) := head_book3s_32.o
 -extra-$(CONFIG_40x)   := head_40x.o
 -extra-$(CONFIG_44x)   := head_44x.o
 -extra-$(CONFIG_PPC_85xx)  := head_85xx.o
 -extra-$(CONFIG_PPC_8xx)   := head_8xx.o
 +obj-$(CONFIG_PPC64)   += head_64.o
 +obj-$(CONFIG_PPC_BOOK3S_32)   += head_book3s_32.o
 +obj-$(CONFIG_40x) += head_40x.o
 +obj-$(CONFIG_44x) += head_44x.o
- obj-$(CONFIG_FSL_BOOKE)   += head_fsl_booke.o
++obj-$(CONFIG_PPC_85xx):= head_85xx.o
 +obj-$(CONFIG_PPC_8xx) += head_8xx.o
  extra-y   += vmlinux.lds
  
  obj-$(CONFIG_RELOCATABLE) += reloc_$(BITS).o


pgp8sZdcwfUbm.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the kbuild tree

[broonie]

Hi all,

Today's linux-next merge of the powerpc tree got conflicts in:

  arch/powerpc/Makefile
  arch/powerpc/kernel/Makefile

between commits:

  4f62512adbe9a ("kbuild: use obj-y instead extra-y for objects placed at the 
head")
  0f17eda6118db ("kbuild: remove head-y syntax")

from the kbuild tree and commits:

  dfc3095cec27f ("powerpc: Remove CONFIG_FSL_BOOKE")
  688de017efaab ("powerpc: Change CONFIG_E500 to CONFIG_PPC_E500")
  3e7318584dfec ("powerpc: Remove CONFIG_PPC_FSL_BOOK3E")
  6556fd1a1e9fc ("powerpc: Cleanup idle for e500")

from the powerpc 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.

diff --cc arch/powerpc/Makefile
index 89c27827a11fb,19470d29de163..0
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
diff --cc arch/powerpc/kernel/Makefile
index ad3decb9f20ba,1f121c1888051..0
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@@ -118,12 -116,12 +116,12 @@@ obj-$(CONFIG_PPC_E500)  += cpu_setup_e5
  obj-$(CONFIG_PPC_DOORBELL)+= dbell.o
  obj-$(CONFIG_JUMP_LABEL)  += jump_label.o
  
 -extra-$(CONFIG_PPC64) := head_64.o
 -extra-$(CONFIG_PPC_BOOK3S_32) := head_book3s_32.o
 -extra-$(CONFIG_40x)   := head_40x.o
 -extra-$(CONFIG_44x)   := head_44x.o
 -extra-$(CONFIG_PPC_85xx)  := head_85xx.o
 -extra-$(CONFIG_PPC_8xx)   := head_8xx.o
 +obj-$(CONFIG_PPC64)   += head_64.o
 +obj-$(CONFIG_PPC_BOOK3S_32)   += head_book3s_32.o
 +obj-$(CONFIG_40x) += head_40x.o
 +obj-$(CONFIG_44x) += head_44x.o
- obj-$(CONFIG_FSL_BOOKE)   += head_fsl_booke.o
++obj-$(CONFIG_PPC_85xx)+= head_85xx.o
 +obj-$(CONFIG_PPC_8xx) += head_8xx.o
  extra-y   += vmlinux.lds
  
  obj-$(CONFIG_RELOCATABLE) += reloc_$(BITS).o

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

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/sysdev/xive/common.c

between commit:

  cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the 
IPIs")

from Linus' tree and commit:

  17df41fec5b8 ("powerpc: use IRQF_NO_DEBUG for IPIs")

from the powerpc 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/powerpc/sysdev/xive/common.c
index 943fd30095af,458645c7a72b..
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@@ -1170,22 -1166,6 +1157,22 @@@ out
return ret;
  }
  
 +static int __init xive_request_ipi(unsigned int cpu)
 +{
 +  struct xive_ipi_desc *xid = _ipis[early_cpu_to_node(cpu)];
 +  int ret;
 +
 +  if (atomic_inc_return(>started) > 1)
 +  return 0;
 +
 +  ret = request_irq(xid->irq, xive_muxed_ipi_action,
- IRQF_PERCPU | IRQF_NO_THREAD,
++IRQF_NO_DEBUG | IRQF_PERCPU | IRQF_NO_THREAD,
 +xid->name, NULL);
 +
 +  WARN(ret < 0, "Failed to request IPI %d: %d\n", xid->irq, ret);
 +  return ret;
 +}
 +
  static int xive_setup_cpu_ipi(unsigned int cpu)
  {
unsigned int xive_ipi_irq = xive_ipi_cpu_to_irq(cpu);


pgpBXawloJ5y6.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Michael Ellerman]

Catalin Marinas  writes:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
>> Stephen Rothwell  writes:
>> > Hi all,
>> >
>> > Today's linux-next merge of the powerpc tree got a conflict in:
>> >
>> >   arch/Kconfig
>> >
>> > between commit:
>> >
>> >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR 
>> > relocations")
>> >
>> > from the arm64 tree and commit:
>> >
>> >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to 
>> > arch/Kconfig")
>> >
>> > from the powerpc 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.
>> 
>> Thanks.
>> 
>> That conflict seems entirely trivial, but Catalin/Will if it bothers you
>> I have the conflicting commit in a topic branch based on rc2 which you
>> could merge to resolve it:
>
> It's a trivial conflict, easy to resolve. I don't think it's worth
> trying to avoid it (Linus normally doesn't mind such conflicts).

Yep, I agree.

cheers

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Will Deacon]

On Mon, Sep 02, 2019 at 10:08:46AM +0100, Catalin Marinas wrote:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> > Stephen Rothwell  writes:
> > > Hi all,
> > >
> > > Today's linux-next merge of the powerpc tree got a conflict in:
> > >
> > >   arch/Kconfig
> > >
> > > between commit:
> > >
> > >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR 
> > > relocations")
> > >
> > > from the arm64 tree and commit:
> > >
> > >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to 
> > > arch/Kconfig")
> > >
> > > from the powerpc 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.
> > 
> > Thanks.
> > 
> > That conflict seems entirely trivial, but Catalin/Will if it bothers you
> > I have the conflicting commit in a topic branch based on rc2 which you
> > could merge to resolve it:
> 
> It's a trivial conflict, easy to resolve. I don't think it's worth
> trying to avoid it (Linus normally doesn't mind such conflicts).

Agreed, we can live with this one :)

Will

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Catalin Marinas]

On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> Stephen Rothwell  writes:
> > Hi all,
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> >   arch/Kconfig
> >
> > between commit:
> >
> >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR 
> > relocations")
> >
> > from the arm64 tree and commit:
> >
> >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to 
> > arch/Kconfig")
> >
> > from the powerpc 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.
> 
> Thanks.
> 
> That conflict seems entirely trivial, but Catalin/Will if it bothers you
> I have the conflicting commit in a topic branch based on rc2 which you
> could merge to resolve it:

It's a trivial conflict, easy to resolve. I don't think it's worth
trying to avoid it (Linus normally doesn't mind such conflicts).

-- 
Catalin

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/Kconfig
>
> between commit:
>
>   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR 
> relocations")
>
> from the arm64 tree and commit:
>
>   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to 
> arch/Kconfig")
>
> from the powerpc 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.

Thanks.

That conflict seems entirely trivial, but Catalin/Will if it bothers you
I have the conflicting commit in a topic branch based on rc2 which you
could merge to resolve it:

  
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=topic/mem-encrypt=0c9c1d56397518eb823d458b00b06bcccd956794


cheers

> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/Kconfig
> index 6f4d3e9bf486,89e2e3f64f79..
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
> the chance of application behavior change because of timing
> differences. The counts are reported via debugfs.
>   
>  +# Select if the architecture has support for applying RELR relocations.
>  +config ARCH_HAS_RELR
>  +bool
>  +
>  +config RELR
>  +bool "Use RELR relocation packing"
>  +depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
>  +default y
>  +help
>  +  Store the kernel's dynamic relocations in the RELR relocation packing
>  +  format. Requires a compatible linker (LLD supports this feature), as
>  +  well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
>  +  are compatible).
>  +
> + config ARCH_HAS_MEM_ENCRYPT
> + bool
> + 
>   source "kernel/gcov/Kconfig"
>   
>   source "scripts/gcc-plugins/Kconfig"

linux-next: manual merge of the powerpc tree with the arm64 tree

[Stephen Rothwell]

Hi all,

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

  arch/Kconfig

between commit:

  5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR 
relocations")

from the arm64 tree and commit:

  0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to 
arch/Kconfig")

from the powerpc 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/Kconfig
index 6f4d3e9bf486,89e2e3f64f79..
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
  the chance of application behavior change because of timing
  differences. The counts are reported via debugfs.
  
 +# Select if the architecture has support for applying RELR relocations.
 +config ARCH_HAS_RELR
 +  bool
 +
 +config RELR
 +  bool "Use RELR relocation packing"
 +  depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
 +  default y
 +  help
 +Store the kernel's dynamic relocations in the RELR relocation packing
 +format. Requires a compatible linker (LLD supports this feature), as
 +well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
 +are compatible).
 +
+ config ARCH_HAS_MEM_ENCRYPT
+   bool
+ 
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"


pgp_GYYjuEGbM.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the dma-mapping tree

[Christoph Hellwig]

On Fri, Feb 22, 2019 at 02:43:41PM +1100, Michael Ellerman wrote:
> Stephen Rothwell  writes:
> 
> > Hi all,
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> >   arch/powerpc/kernel/dma-swiotlb.c
> >
> > between commit:
> >
> >   cfced786969c ("dma-mapping: remove the default map_resource 
> > implementation")
> >
> > from the dma-mapping tree and commit:
> >
> >   68005b67d15a ("powerpc/dma: use the generic direct mapping bypass")
> >
> > from the powerpc 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.
> 
> Thanks.
> 
> Christoph, I've put the powerpc dma changes in a topic branch if you
> want to merge it to reduce the conflicts. Up to you.

Thanks.  I think the conflicts are pretty harmless as we are mostly
removing code entirely in the powerpc tree that the dma-mapping tree
touches.

Re: linux-next: manual merge of the powerpc tree with the dma-mapping tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/kernel/dma-swiotlb.c
>
> between commit:
>
>   cfced786969c ("dma-mapping: remove the default map_resource implementation")
>
> from the dma-mapping tree and commit:
>
>   68005b67d15a ("powerpc/dma: use the generic direct mapping bypass")
>
> from the powerpc 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.

Thanks.

Christoph, I've put the powerpc dma changes in a topic branch if you
want to merge it to reduce the conflicts. Up to you.

  
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/dma


cheers

linux-next: manual merge of the powerpc tree with the dma-mapping tree

[Stephen Rothwell]

Hi all,

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

  kernel/dma/Kconfig

between commits:

  ff4c25f26a71 ("dma-mapping: improve selection of dma_declare_coherent 
availability")

from the dma-mapping tree and commit:

  11ddce15451e ("dma-mapping, powerpc: simplify the arch dma_set_mask override")

from the powerpc 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 kernel/dma/Kconfig
index 212aac7c675f,0711d18645de..
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@@ -16,13 -16,10 +16,16 @@@ config ARCH_DMA_ADDR_T_64BI
  config ARCH_HAS_DMA_COHERENCE_H
bool
  
+ config ARCH_HAS_DMA_SET_MASK
+   bool
+ 
 -config HAVE_GENERIC_DMA_COHERENT
 +config DMA_DECLARE_COHERENT
 +  bool
 +
 +config ARCH_HAS_SETUP_DMA_OPS
 +  bool
 +
 +config ARCH_HAS_TEARDOWN_DMA_OPS
bool
  
  config ARCH_HAS_SYNC_DMA_FOR_DEVICE


pgpXWFrlVDbi5.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the dma-mapping tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/dma.c

between commit:

  cfced786969c ("dma-mapping: remove the default map_resource implementation")

from the dma-mapping tree and commit:

  68005b67d15a ("powerpc/dma: use the generic direct mapping bypass")

from the powerpc tree.

I fixed it up (the latter removed the file, so I did that) 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


pgpZwUq8Lx5nh.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the dma-mapping tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/dma-swiotlb.c

between commit:

  cfced786969c ("dma-mapping: remove the default map_resource implementation")

from the dma-mapping tree and commit:

  68005b67d15a ("powerpc/dma: use the generic direct mapping bypass")

from the powerpc 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


pgpLI4YhlFLza.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

  Documentation/admin-guide/kernel-parameters.txt

between commits:

  05736e4ac13c ("cpu/hotplug: Provide knobs to control SMT")
  506a66f37489 ("Revert "x86/apic: Ignore secondary threads if nosmt=force"")

from Linus' tree and commit:

  26cb1f36c43e ("Documentation: Add nospectre_v1 parameter")

from the powerpc 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 Documentation/admin-guide/kernel-parameters.txt
index 5a67e409d370,4167bbea51e1..
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@@ -2761,10 -2687,10 +2761,14 @@@
nosmt   [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
  
 +  [KNL,x86] Disable symmetric multithreading (SMT).
 +  nosmt=force: Force disable SMT, cannot be undone
 +   via the sysfs control file.
 +
+   nospectre_v1[PPC] Disable mitigations for Spectre Variant 1 (bounds
+   check bypass). With this option data leaks are possible
+   in the system.
+ 
nospectre_v2[X86] Disable all mitigations for the Spectre variant 2
(indirect branch prediction) vulnerability. System may
allow data leaks with this option, which is equivalent


pgpMw0YI5f61K.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the m68k tree

[Finn Thain]

On Thu, 2 Aug 2018, Geert Uytterhoeven wrote:

> Hi Stephen,
> 
> On Thu, Aug 2, 2018 at 1:42 AM Stephen Rothwell  wrote:
> > [forgot the conflict resolution ...]
> >
> > On Thu, 2 Aug 2018 09:27:20 +1000 Stephen Rothwell  
> > wrote:
> > >
> > > Today's linux-next merge of the powerpc tree got a conflict in:
> > >
> > >   arch/m68k/mac/misc.c
> > >
> > > between commit:
> > >
> > >   5b9bfb8ec467 ("m68k: mac: Use time64_t in RTC handling")
> > >
> > > from the m68k tree and commit:
> > >
> > >   ebd722275f9c ("macintosh/via-pmu: Replace via-pmu68k driver with 
> > > via-pmu driver")
> > >
> > > from the powerpc 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.
> 
> Ah, now I remember Finn said he was going to rebase his series once the 
> time64_t patch has entered my tree...
> 

The conflict I was worried about was avoided when I dropped v3 patch 10/12 
("macintosh: Use common code to access RTC"). I'll rework that patch after 
all the PMU and RTC work makes its way into Linus' tree.

> > --- a/arch/m68k/mac/misc.c
> > +++ b/arch/m68k/mac/misc.c
> > @@@ -90,11 -85,11 +90,11 @@@ static void cuda_write_pram(int offset
> >   }
> >   #endif /* CONFIG_ADB_CUDA */
> >
> > - #ifdef CONFIG_ADB_PMU68K
> > + #ifdef CONFIG_ADB_PMU
> >  -static long pmu_read_time(void)
> >  +static time64_t pmu_read_time(void)
> >   {
> > struct adb_request req;
> >  -  long time;
> >  +  time64_t time;
> >
> > if (pmu_request(, NULL, 1, PMU_READ_RTC) < 0)
> > return 0;
> 
> Thanks, looks good to me!
> 

Looks good to me, too.

Thanks.

-- 

> Gr{oetje,eeting}s,
> 
> Geert
> 
> 

Re: linux-next: manual merge of the powerpc tree with the m68k tree

[Geert Uytterhoeven]

Hi Stephen,

On Thu, Aug 2, 2018 at 1:42 AM Stephen Rothwell  wrote:
> [forgot the conflict resolution ...]
>
> On Thu, 2 Aug 2018 09:27:20 +1000 Stephen Rothwell  
> wrote:
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> >   arch/m68k/mac/misc.c
> >
> > between commit:
> >
> >   5b9bfb8ec467 ("m68k: mac: Use time64_t in RTC handling")
> >
> > from the m68k tree and commit:
> >
> >   ebd722275f9c ("macintosh/via-pmu: Replace via-pmu68k driver with via-pmu 
> > driver")
> >
> > from the powerpc 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.

Ah, now I remember Finn said he was going to rebase his series once the time64_t
patch has entered my tree...

> --- a/arch/m68k/mac/misc.c
> +++ b/arch/m68k/mac/misc.c
> @@@ -90,11 -85,11 +90,11 @@@ static void cuda_write_pram(int offset
>   }
>   #endif /* CONFIG_ADB_CUDA */
>
> - #ifdef CONFIG_ADB_PMU68K
> + #ifdef CONFIG_ADB_PMU
>  -static long pmu_read_time(void)
>  +static time64_t pmu_read_time(void)
>   {
> struct adb_request req;
>  -  long time;
>  +  time64_t time;
>
> if (pmu_request(, NULL, 1, PMU_READ_RTC) < 0)
> return 0;

Thanks, looks good to me!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: linux-next: manual merge of the powerpc tree with the m68k tree

[Stephen Rothwell]

Hi all,

[forgot the conflict resolution ...]

On Thu, 2 Aug 2018 09:27:20 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/m68k/mac/misc.c
> 
> between commit:
> 
>   5b9bfb8ec467 ("m68k: mac: Use time64_t in RTC handling")
> 
> from the m68k tree and commit:
> 
>   ebd722275f9c ("macintosh/via-pmu: Replace via-pmu68k driver with via-pmu 
> driver")
> 
> from the powerpc 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/m68k/mac/misc.c
index 19e9d8eef1f2,28090a44fa09..3534aa6a4dc2
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@@ -90,11 -85,11 +90,11 @@@ static void cuda_write_pram(int offset
  }
  #endif /* CONFIG_ADB_CUDA */
  
- #ifdef CONFIG_ADB_PMU68K
+ #ifdef CONFIG_ADB_PMU
 -static long pmu_read_time(void)
 +static time64_t pmu_read_time(void)
  {
struct adb_request req;
 -  long time;
 +  time64_t time;
  
if (pmu_request(, NULL, 1, PMU_READ_RTC) < 0)
return 0;


pgpf0oTdwPhhP.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the m68k tree

[Stephen Rothwell]

Hi all,

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

  arch/m68k/mac/misc.c

between commit:

  5b9bfb8ec467 ("m68k: mac: Use time64_t in RTC handling")

from the m68k tree and commit:

  ebd722275f9c ("macintosh/via-pmu: Replace via-pmu68k driver with via-pmu 
driver")

from the powerpc 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


pgpZEHofoHrtx.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   drivers/vfio/vfio_iommu_spapr_tce.c
>
> between commit:
>
>   1463edca6734 ("vfio/spapr: Use IOMMU pageshift rather than pagesize")
>
> from the powerpc-fixes tree and commit:
>
>   00a5c58d9499 ("KVM: PPC: Make iommu_table::it_userspace big endian")
>
> from the powerpc tree.

Thanks.

That has turned into a real mess, with conflicting code in next, fixes
and topic/ppc-kvm.

I'll fix it all up before the merge window.

cheers

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  drivers/vfio/vfio_iommu_spapr_tce.c

between commit:

  1463edca6734 ("vfio/spapr: Use IOMMU pageshift rather than pagesize")

from the powerpc-fixes tree and commit:

  00a5c58d9499 ("KVM: PPC: Make iommu_table::it_userspace big endian")

from the powerpc 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/vfio/vfio_iommu_spapr_tce.c
index 7cd63b0c1a46,11a4c194d6e3..
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@@ -487,11 -449,11 +449,11 @@@ static void tce_iommu_unuse_page_v2(str
if (!pua)
return;
  
-   ret = tce_iommu_prereg_ua_to_hpa(container, *pua, tbl->it_page_shift,
-   , );
+   ret = tce_iommu_prereg_ua_to_hpa(container, be64_to_cpu(*pua),
 -  IOMMU_PAGE_SIZE(tbl), , );
++  tbl->it_page_shift, , );
if (ret)
-   pr_debug("%s: tce %lx at #%lx was not cached, ret=%d\n",
-   __func__, *pua, entry, ret);
+   pr_debug("%s: tce %llx at #%lx was not cached, ret=%d\n",
+   __func__, be64_to_cpu(*pua), entry, ret);
if (mem)
mm_iommu_mapped_dec(mem);
  
@@@ -599,19 -561,12 +561,12 @@@ static long tce_iommu_build_v2(struct t
unsigned long hpa;
enum dma_data_direction dirtmp;
  
-   if (!tbl->it_userspace) {
-   ret = tce_iommu_userspace_view_alloc(tbl, container->mm);
-   if (ret)
-   return ret;
-   }
- 
for (i = 0; i < pages; ++i) {
struct mm_iommu_table_group_mem_t *mem = NULL;
-   unsigned long *pua = IOMMU_TABLE_USERSPACE_ENTRY(tbl,
-   entry + i);
+   __be64 *pua = IOMMU_TABLE_USERSPACE_ENTRY(tbl, entry + i);
  
ret = tce_iommu_prereg_ua_to_hpa(container,
 -  tce, IOMMU_PAGE_SIZE(tbl), , );
 +  tce, tbl->it_page_shift, , );
if (ret)
break;
  


pgpFvm2nd2jBL.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

On Thu, 31 May 2018 09:32:16 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/kernel/module_64.c
> 
> between commit:
> 
>   06aeb9e3f2bc ("powerpc/kbuild: move -mprofile-kernel check to Kconfig")
> 
> from the kbuild tree and commit:
> 
>   250122baed29 ("powerpc64/module: Tighten detection of mcount call sites 
> with -mprofile-kernel")
> 
> from the powerpc 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/powerpc/kernel/module_64.c
> index 55bccc315e1a,f7667e2ebfcb..
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@@ -462,9 -466,12 +466,12 @@@ static unsigned long stub_for_addr(cons
>   return (unsigned long)[i];
>   }
>   
>  -#ifdef CC_USING_MPROFILE_KERNEL
>  +#ifdef CONFIG_MPROFILE_KERNEL
> - static bool is_early_mcount_callsite(u32 *instruction)
> + static bool is_mprofile_mcount_callsite(const char *name, u32 *instruction)
>   {
> + if (strcmp("_mcount", name))
> + return false;
> + 
>   /*
>* Check if this is one of the -mprofile-kernel sequences.
>*/

This is now a conflict between the kbuild tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpigJezwQ2US.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/module_64.c

between commit:

  06aeb9e3f2bc ("powerpc/kbuild: move -mprofile-kernel check to Kconfig")

from the kbuild tree and commit:

  250122baed29 ("powerpc64/module: Tighten detection of mcount call sites with 
-mprofile-kernel")

from the powerpc 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/powerpc/kernel/module_64.c
index 55bccc315e1a,f7667e2ebfcb..
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@@ -462,9 -466,12 +466,12 @@@ static unsigned long stub_for_addr(cons
return (unsigned long)[i];
  }
  
 -#ifdef CC_USING_MPROFILE_KERNEL
 +#ifdef CONFIG_MPROFILE_KERNEL
- static bool is_early_mcount_callsite(u32 *instruction)
+ static bool is_mprofile_mcount_callsite(const char *name, u32 *instruction)
  {
+   if (strcmp("_mcount", name))
+   return false;
+ 
/*
 * Check if this is one of the -mprofile-kernel sequences.
 */


pgpsEL__39KAb.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/include/asm/ftrace.h
>
> between commit:
>
>   edf6a2dfe388 ("powerpc/trace/syscalls: Update syscall name matching logic 
> to account for ppc_ prefix")
>
> from the powerpc-fixes tree and commit:
>
>   c3e59d778403 ("powerpc64/ftrace: Rearrange #ifdef sections in ftrace.h")
>
> from the powerpc 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.
>
> Michael, I think the version in your merge branch is not quite right ...

Yep.

Don't do merges after midnight kids.

I've pushed a fixed version, which I think matches yours.

I'll resolve it in my next when I merge my fixes & next later in the
cycle.

cheers

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/include/asm/ftrace.h

between commit:

  edf6a2dfe388 ("powerpc/trace/syscalls: Update syscall name matching logic to 
account for ppc_ prefix")

from the powerpc-fixes tree and commit:

  c3e59d778403 ("powerpc64/ftrace: Rearrange #ifdef sections in ftrace.h")

from the powerpc 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.

Michael, I think the version in your merge branch is not quite right ...
-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/include/asm/ftrace.h
index b2dabd06659d,fc3a2203c566..
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@@ -66,35 -62,39 +62,54 @@@ struct dyn_arch_ftrace 
  #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
  #define ARCH_SUPPORTS_FTRACE_OPS 1
  #endif
- #endif
+ #endif /* CONFIG_FUNCTION_TRACER */
  
- #if defined(CONFIG_FTRACE_SYSCALLS) && !defined(__ASSEMBLY__)
+ #ifndef __ASSEMBLY__
 -#if defined(CONFIG_FTRACE_SYSCALLS) && defined(PPC64_ELF_ABI_v1)
++#if defined(CONFIG_FTRACE_SYSCALLS)
 +/*
 + * Some syscall entry functions on powerpc start with "ppc_" (fork and clone,
 + * for instance) or ppc32_/ppc64_. We should also match the sys_ variant with
 + * those.
 + */
  #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
 +#ifdef PPC64_ELF_ABI_v1
  static inline bool arch_syscall_match_sym_name(const char *sym, const char 
*name)
  {
 -  /*
 -   * Compare the symbol name with the system call name. Skip the .sys or 
.SyS
 -   * prefix from the symbol name and the sys prefix from the system call 
name and
 -   * just match the rest. This is only needed on ppc64 since symbol names 
on
 -   * 32bit do not start with a period so the generic function will work.
 -   */
 -  return !strcmp(sym + 4, name + 3);
 +  /* We need to skip past the initial dot, and the __se_sys alias */
 +  return !strcmp(sym + 1, name) ||
 +  (!strncmp(sym, ".__se_sys", 9) && !strcmp(sym + 6, name)) ||
 +  (!strncmp(sym, ".ppc_", 5) && !strcmp(sym + 5, name + 4)) ||
 +  (!strncmp(sym, ".ppc32_", 7) && !strcmp(sym + 7, name + 4)) ||
 +  (!strncmp(sym, ".ppc64_", 7) && !strcmp(sym + 7, name + 4));
  }
 -#endif /* CONFIG_FTRACE_SYSCALLS && PPC64_ELF_ABI_v1 */
 +#else
 +static inline bool arch_syscall_match_sym_name(const char *sym, const char 
*name)
 +{
 +  return !strcmp(sym, name) ||
 +  (!strncmp(sym, "__se_sys", 8) && !strcmp(sym + 5, name)) ||
 +  (!strncmp(sym, "ppc_", 4) && !strcmp(sym + 4, name + 4)) ||
 +  (!strncmp(sym, "ppc32_", 6) && !strcmp(sym + 6, name + 4)) ||
 +  (!strncmp(sym, "ppc64_", 6) && !strcmp(sym + 6, name + 4));
 +}
- #endif
- #endif /* CONFIG_FTRACE_SYSCALLS && !__ASSEMBLY__ */
++#endif /* PPC64_ELF_ABI_v1 */
++#endif /* CONFIG_FTRACE_SYSCALLS */
+ 
+ #ifdef CONFIG_PPC64
+ #include 
+ 
+ static inline void this_cpu_disable_ftrace(void)
+ {
+   get_paca()->ftrace_enabled = 0;
+ }
+ 
+ static inline void this_cpu_enable_ftrace(void)
+ {
+   get_paca()->ftrace_enabled = 1;
+ }
+ #else /* CONFIG_PPC64 */
+ static inline void this_cpu_disable_ftrace(void) { }
+ static inline void this_cpu_enable_ftrace(void) { }
+ #endif /* CONFIG_PPC64 */
+ #endif /* !__ASSEMBLY__ */
  
  #endif /* _ASM_POWERPC_FTRACE */


pgpD1o__l4Q3t.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/include/asm/cputable.h
>   arch/powerpc/kernel/dt_cpu_ftrs.c
>
> between commit:
>
>   a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
>
> from the powerpc-fixes tree and commits:
>
>   9bbf0b576d32 ("powerpc: Free up CPU feature bits on 64-bit machines")
>   b5af4f279323 ("powerpc: Add CPU feature bits for TM bug workarounds on 
> POWER9 v2.2")
>
> from the powerpc tree.

Thanks, yeah that was a bit of disaster.

I'll merge fixes into next before sending to Linus.

cheers

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/include/asm/cputable.h
  arch/powerpc/kernel/dt_cpu_ftrs.c

between commit:

  a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")

from the powerpc-fixes tree and commits:

  9bbf0b576d32 ("powerpc: Free up CPU feature bits on 64-bit machines")
  b5af4f279323 ("powerpc: Add CPU feature bits for TM bug workarounds on POWER9 
v2.2")

from the powerpc 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/powerpc/include/asm/cputable.h
index 2e2bacbdf6ed,ecee84dea7e7..
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@@ -174,38 -181,40 +181,41 @@@ static inline void cpu_feature_keys_ini
  #define LONG_ASM_CONST(x) 0
  #endif
  
- #define CPU_FTR_HVMODE
LONG_ASM_CONST(0x0001)
- #define CPU_FTR_ARCH_201  LONG_ASM_CONST(0x0002)
- #define CPU_FTR_ARCH_206  LONG_ASM_CONST(0x0004)
- #define CPU_FTR_ARCH_207S LONG_ASM_CONST(0x0008)
- #define CPU_FTR_ARCH_300  LONG_ASM_CONST(0x0010)
- #define CPU_FTR_MMCRA LONG_ASM_CONST(0x0020)
- #define CPU_FTR_CTRL  LONG_ASM_CONST(0x0040)
- #define CPU_FTR_SMT   LONG_ASM_CONST(0x0080)
- #define CPU_FTR_PAUSE_ZEROLONG_ASM_CONST(0x0100)
- #define CPU_FTR_PURR  LONG_ASM_CONST(0x0200)
- #define CPU_FTR_CELL_TB_BUG   LONG_ASM_CONST(0x0400)
- #define CPU_FTR_SPURR LONG_ASM_CONST(0x0800)
- #define CPU_FTR_DSCR  LONG_ASM_CONST(0x1000)
- #define CPU_FTR_VSX   LONG_ASM_CONST(0x2000)
- #define CPU_FTR_SAO   LONG_ASM_CONST(0x4000)
- #define CPU_FTR_CP_USE_DCBTZ  LONG_ASM_CONST(0x8000)
- #define CPU_FTR_UNALIGNED_LD_STD  LONG_ASM_CONST(0x0001)
- #define CPU_FTR_ASYM_SMT  LONG_ASM_CONST(0x0002)
- #define CPU_FTR_STCX_CHECKS_ADDRESS   LONG_ASM_CONST(0x0004)
- #define CPU_FTR_POPCNTB   
LONG_ASM_CONST(0x0008)
- #define CPU_FTR_POPCNTD   
LONG_ASM_CONST(0x0010)
- #define CPU_FTR_PKEY  LONG_ASM_CONST(0x0020)
- #define CPU_FTR_VMX_COPY  LONG_ASM_CONST(0x0040)
- #define CPU_FTR_TMLONG_ASM_CONST(0x0080)
- #define CPU_FTR_CFAR  LONG_ASM_CONST(0x0100)
- #define   CPU_FTR_HAS_PPR 
LONG_ASM_CONST(0x0200)
- #define CPU_FTR_DAWR  LONG_ASM_CONST(0x0400)
- #define CPU_FTR_DABRX LONG_ASM_CONST(0x0800)
- #define CPU_FTR_PMAO_BUG  LONG_ASM_CONST(0x1000)
- #define CPU_FTR_P9_TLBIE_BUG  LONG_ASM_CONST(0x2000)
- #define CPU_FTR_POWER9_DD1LONG_ASM_CONST(0x4000)
- #define CPU_FTR_POWER9_DD2_1  LONG_ASM_CONST(0x8000)
+ #define CPU_FTR_REAL_LE   
LONG_ASM_CONST(0x1000)
+ #define CPU_FTR_HVMODE
LONG_ASM_CONST(0x2000)
+ #define CPU_FTR_ARCH_201  LONG_ASM_CONST(0x4000)
+ #define CPU_FTR_ARCH_206  LONG_ASM_CONST(0x8000)
+ #define CPU_FTR_ARCH_207S LONG_ASM_CONST(0x0001)
+ #define CPU_FTR_ARCH_300  LONG_ASM_CONST(0x0002)
+ #define CPU_FTR_MMCRA LONG_ASM_CONST(0x0004)
+ #define CPU_FTR_CTRL  LONG_ASM_CONST(0x0008)
+ #define CPU_FTR_SMT   LONG_ASM_CONST(0x0010)
+ #define CPU_FTR_PAUSE_ZEROLONG_ASM_CONST(0x0020)
+ #define CPU_FTR_PURR  LONG_ASM_CONST(0x0040)
+ #define CPU_FTR_CELL_TB_BUG   LONG_ASM_CONST(0x0080)
+ #define CPU_FTR_SPURR LONG_ASM_CONST(0x0100)
+ #define CPU_FTR_DSCR  LONG_ASM_CONST(0x0200)
+ #define CPU_FTR_VSX   LONG_ASM_CONST(0x0400)
+ #define CPU_FTR_SAO   LONG_ASM_CONST(0x0800)
+ #define CPU_FTR_CP_USE_DCBTZ  LONG_ASM_CONST(0x1000)
+ #define CPU_FTR_UNALIGNED_LD_STD  LONG_ASM_CONST(0x2000)
+ #define 

linux-next: manual merge of the powerpc tree with the asm-generic tree

[Stephen Rothwell]

Hi all,

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

  lib/raid6/test/Makefile

between commit:

  fa523d54a7eb ("raid: remove tile specific raid6 implementation")

from the asm-generic tree and commit:

  751ba79cc552 ("lib/raid6/altivec: Add vpermxor implementation for raid6 Q 
syndrome")

from the powerpc 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 lib/raid6/test/Makefile
index fabc477b1417,5050e270c06b..
--- a/lib/raid6/test/Makefile
+++ b/lib/raid6/test/Makefile
@@@ -45,12 -45,17 +45,14 @@@ else ifeq ($(HAS_NEON),yes
  CFLAGS += -DCONFIG_KERNEL_MODE_NEON=1
  else
  HAS_ALTIVEC := $(shell printf '\#include \nvector int 
a;\n' |\
-  gcc -c -x c - >&/dev/null && \
-  rm ./-.o && echo yes)
+  gcc -c -x c - >/dev/null && rm ./-.o && echo yes)
  ifeq ($(HAS_ALTIVEC),yes)
- OBJS += altivec1.o altivec2.o altivec4.o altivec8.o
+ CFLAGS += -I../../../arch/powerpc/include
+ CFLAGS += -DCONFIG_ALTIVEC
+ OBJS += altivec1.o altivec2.o altivec4.o altivec8.o \
+ vpermxor1.o vpermxor2.o vpermxor4.o vpermxor8.o
  endif
  endif
 -ifeq ($(ARCH),tilegx)
 -OBJS += tilegx8.o
 -endif
  
  .c.o:
$(CC) $(CFLAGS) -c -o $@ $<
@@@ -117,7 -137,8 +131,7 @@@ tables.c: mktable
./mktables > tables.c
  
  clean:
-   rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c neon*.c 
tables.c raid6test
+   rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c vpermxor*.c 
neon*.c tables.c raid6test
 -  rm -f tilegx*.c
  
  spotless: clean
rm -f *~


pgpdxxWKwgIrN.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/kernel/setup-common.c
>
> between commit:
>
>   349524bc0da6 ("powerpc: Don't preempt_disable() in show_cpuinfo()")
>
> from the powerpc-fixes tree and commit:
>
>   f5f563012a70 ("powerpc: Make newline in cpuinfo unconditional")
>
> from the powerpc 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.

Nah that guy is a jerk.

Thanks for the report.

cheers

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/setup-common.c

between commit:

  349524bc0da6 ("powerpc: Don't preempt_disable() in show_cpuinfo()")

from the powerpc-fixes tree and commit:

  f5f563012a70 ("powerpc: Make newline in cpuinfo unconditional")

from the powerpc 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/powerpc/kernel/setup-common.c
index 3f33869c6486,24da91768133..
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@@ -346,10 -354,10 +346,7 @@@ static int show_cpuinfo(struct seq_fil
   loops_per_jiffy / (50/HZ),
   (loops_per_jiffy / (5000/HZ)) % 100);
  #endif
- 
- #ifdef CONFIG_SMP
seq_printf(m, "\n");
- #endif
 -
 -  preempt_enable();
 -
/* If this is the last cpu, print the summary */
if (cpumask_next(cpu_id, cpu_online_mask) >= nr_cpu_ids)
show_cpuinfo_summary(m);

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

[Stephen Rothwell]

Hi all,

On Mon, 30 Oct 2017 12:51:33 + Mark Brown  wrote:
>
> Hi all,
> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/kvm/powerpc.c
> 
> between commit:
> 
>   ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM")
> 
> from Linus' tree and commit:
> 
>   2a3d6553cbd7 ("KVM: PPC: Tie KVM_CAP_PPC_HTM to the user-visible TM 
> feature")
> 
> from the powerpc 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.
> 
> diff --cc arch/powerpc/kvm/powerpc.c
> index ee279c7f4802,a3746b98ec11..
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@@ -644,7 -644,8 +644,8 @@@ int kvm_vm_ioctl_check_extension(struc
>   break;
>   #endif
>   case KVM_CAP_PPC_HTM:
> - r = cpu_has_feature(CPU_FTR_TM_COMP) && hv_enabled;
>  -r = is_kvmppc_hv_enabled(kvm) &&
> ++r = hv_enabled &&
> + (cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_HTM_COMP);
>   break;
>   default:
>   r = 0;

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/mm/tlb-radix.c

between commit:

  26e53d5ebe2e ("powerpc/64s/radix: Fix preempt imbalance in TLB flush")

from Linus' tree and commit:

  dffe8449c5dd ("powerpc/64s/radix: Improve preempt handling in TLB code")

from the powerpc tree.

I fixed it up (I effectively dropped the former as it seems to be fixed in
the latter as well) 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

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/mm/tlb-radix.c

between commit:

  26e53d5ebe2e ("powerpc/64s/radix: Fix preempt imbalance in TLB flush")

from the powerpc-fixes tree and commit:

  6773027205ea ("powerpc/mm/radix: Drop unneeded NULL check")

from the powerpc 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/powerpc/mm/tlb-radix.c
index d304028641a2,3a07d7a5e2fe..
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@@ -359,8 -359,7 +359,8 @@@ void radix__flush_tlb_collapsed_pmd(str
unsigned long pid, end;
  
  
-   pid = mm ? mm->context.id : 0;
+   pid = mm->context.id;
 +  preempt_disable();
if (unlikely(pid == MMU_NO_CONTEXT))
goto no_context;
  

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

[Mark Brown]

Hi all,

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

  arch/powerpc/kvm/powerpc.c

between commit:

  ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM")

from Linus' tree and commit:

  2a3d6553cbd7 ("KVM: PPC: Tie KVM_CAP_PPC_HTM to the user-visible TM feature")

from the powerpc 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.

diff --cc arch/powerpc/kvm/powerpc.c
index ee279c7f4802,a3746b98ec11..
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@@ -644,7 -644,8 +644,8 @@@ int kvm_vm_ioctl_check_extension(struc
break;
  #endif
case KVM_CAP_PPC_HTM:
-   r = cpu_has_feature(CPU_FTR_TM_COMP) && hv_enabled;
 -  r = is_kvmppc_hv_enabled(kvm) &&
++  r = hv_enabled &&
+   (cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_HTM_COMP);
break;
default:
r = 0;


signature.asc
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

FIXME: Add owner of second tree to To:
   Add author(s)/SOB of conflicting commits.

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

  arch/powerpc/kernel/asm-offsets.c

between commit:

  f2574030b0e3 ("powerpc: Revert the initial stack protector support")

from Linus' tree and commit:

  454656155110 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")

from the powerpc 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/powerpc/kernel/asm-offsets.c
index 195a9fc8f81c,b6709021fee5..
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@@ -88,39 -91,42 +91,39 @@@ int main(void
  #endif /* CONFIG_PPC64 */
  
  #ifdef CONFIG_LIVEPATCH
-   DEFINE(TI_livepatch_sp, offsetof(struct thread_info, livepatch_sp));
+   OFFSET(TI_livepatch_sp, thread_info, livepatch_sp);
  #endif
  
-   DEFINE(KSP, offsetof(struct thread_struct, ksp));
-   DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
 -#ifdef CONFIG_CC_STACKPROTECTOR
 -  DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary));
 -#endif
+   OFFSET(KSP, thread_struct, ksp);
+   OFFSET(PT_REGS, thread_struct, regs);
  #ifdef CONFIG_BOOKE
-   DEFINE(THREAD_NORMSAVES, offsetof(struct thread_struct, normsave[0]));
+   OFFSET(THREAD_NORMSAVES, thread_struct, normsave[0]);
  #endif
-   DEFINE(THREAD_FPEXC_MODE, offsetof(struct thread_struct, fpexc_mode));
-   DEFINE(THREAD_FPSTATE, offsetof(struct thread_struct, fp_state));
-   DEFINE(THREAD_FPSAVEAREA, offsetof(struct thread_struct, fp_save_area));
-   DEFINE(FPSTATE_FPSCR, offsetof(struct thread_fp_state, fpscr));
-   DEFINE(THREAD_LOAD_FP, offsetof(struct thread_struct, load_fp));
+   OFFSET(THREAD_FPEXC_MODE, thread_struct, fpexc_mode);
+   OFFSET(THREAD_FPSTATE, thread_struct, fp_state);
+   OFFSET(THREAD_FPSAVEAREA, thread_struct, fp_save_area);
+   OFFSET(FPSTATE_FPSCR, thread_fp_state, fpscr);
+   OFFSET(THREAD_LOAD_FP, thread_struct, load_fp);
  #ifdef CONFIG_ALTIVEC
-   DEFINE(THREAD_VRSTATE, offsetof(struct thread_struct, vr_state));
-   DEFINE(THREAD_VRSAVEAREA, offsetof(struct thread_struct, vr_save_area));
-   DEFINE(THREAD_VRSAVE, offsetof(struct thread_struct, vrsave));
-   DEFINE(THREAD_USED_VR, offsetof(struct thread_struct, used_vr));
-   DEFINE(VRSTATE_VSCR, offsetof(struct thread_vr_state, vscr));
-   DEFINE(THREAD_LOAD_VEC, offsetof(struct thread_struct, load_vec));
+   OFFSET(THREAD_VRSTATE, thread_struct, vr_state);
+   OFFSET(THREAD_VRSAVEAREA, thread_struct, vr_save_area);
+   OFFSET(THREAD_VRSAVE, thread_struct, vrsave);
+   OFFSET(THREAD_USED_VR, thread_struct, used_vr);
+   OFFSET(VRSTATE_VSCR, thread_vr_state, vscr);
+   OFFSET(THREAD_LOAD_VEC, thread_struct, load_vec);
  #endif /* CONFIG_ALTIVEC */
  #ifdef CONFIG_VSX
-   DEFINE(THREAD_USED_VSR, offsetof(struct thread_struct, used_vsr));
+   OFFSET(THREAD_USED_VSR, thread_struct, used_vsr);
  #endif /* CONFIG_VSX */
  #ifdef CONFIG_PPC64
-   DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid));
+   OFFSET(KSP_VSID, thread_struct, ksp_vsid);
  #else /* CONFIG_PPC64 */
-   DEFINE(PGDIR, offsetof(struct thread_struct, pgdir));
+   OFFSET(PGDIR, thread_struct, pgdir);
  #ifdef CONFIG_SPE
-   DEFINE(THREAD_EVR0, offsetof(struct thread_struct, evr[0]));
-   DEFINE(THREAD_ACC, offsetof(struct thread_struct, acc));
-   DEFINE(THREAD_SPEFSCR, offsetof(struct thread_struct, spefscr));
-   DEFINE(THREAD_USED_SPE, offsetof(struct thread_struct, used_spe));
+   OFFSET(THREAD_EVR0, thread_struct, evr[0]);
+   OFFSET(THREAD_ACC, thread_struct, acc);
+   OFFSET(THREAD_SPEFSCR, thread_struct, spefscr);
+   OFFSET(THREAD_USED_SPE, thread_struct, used_spe);
  #endif /* CONFIG_SPE */
  #endif /* CONFIG_PPC64 */
  #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/Kconfig

between commit:

  f2574030b0e3 ("powerpc: Revert the initial stack protector support")

from the powerpc-fixes tree and commit:

  d6c569b99558 ("powerpc/64: Move HAVE_CONTEXT_TRACKING from pseries to common 
Kconfig")

from the powerpc 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/powerpc/Kconfig
index a46d1c0d14d3,33f5b8380a7d..
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -164,9 -164,11 +164,10 @@@ config PP
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE
select HAVE_ARCH_HARDENED_USERCOPY
select HAVE_KERNEL_GZIP
 -  select HAVE_CC_STACKPROTECTOR
+   select HAVE_CONTEXT_TRACKING if PPC64
  
  config GENERIC_CSUM
-   def_bool CPU_LITTLE_ENDIAN
+   def_bool n
  
  config EARLY_PRINTK
bool

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Michael Ellerman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/powerpc/include/asm/asm-prototypes.h
>
> between commit:
>
>   9e5f68842276 ("powerpc: Fix missing CRCs, add more asm-prototypes.h 
> declarations")
>
> from the powerpc-fixes tree and commit:
>
>   82de5797a260 ("powerpc: Remove extraneous header from asm-prototypes.h")
>
> from the powerpc 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.

Thanks. I'm planning to merge fixes into next RSN ... as soon as people
stop finding bugs.

cheers

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/include/asm/asm-prototypes.h

between commit:

  9e5f68842276 ("powerpc: Fix missing CRCs, add more asm-prototypes.h 
declarations")

from the powerpc-fixes tree and commit:

  82de5797a260 ("powerpc: Remove extraneous header from asm-prototypes.h")

from the powerpc 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/powerpc/include/asm/asm-prototypes.h
index e0baba1535e6,dfef1174663e..
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@@ -13,12 -13,6 +13,11 @@@
   */
  
  #include 
- #include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
  #include 
  
  /* SMP */

linux-next: manual merge of the powerpc tree with the kbuild tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got conflicts in:

  arch/powerpc/kernel/misc_32.S
  arch/powerpc/kernel/misc_64.S

between commit:

  9445aa1a3062 ("ppc: move exports to definitions")

from the kbuild tree and commit:

  6f698df10cb2 ("powerpc/kernel: Use kprobe blacklist for asm functions")

from the powerpc 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/powerpc/kernel/misc_32.S
index f5156105c5f3,03756ffdcd71..
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@@ -360,7 -358,8 +360,9 @@@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_
sync/* additional sync needed on g4 */
isync
blr
+ _ASM_NOKPROBE_SYMBOL(flush_icache_range)
 +EXPORT_SYMBOL(flush_icache_range)
+ 
  /*
   * Flush a particular page from the data cache to RAM.
   * Note: this is necessary because the instruction cache does *not*
diff --cc arch/powerpc/kernel/misc_64.S
index 8b526846e72a,5d7e583f1588..
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@@ -110,8 -109,8 +110,9 @@@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_
bdnz2b
isync
blr
-   .previous .text
+ _ASM_NOKPROBE_SYMBOL(flush_icache_range)
 +EXPORT_SYMBOL(flush_icache_range)
+ 
  /*
   * Like above, but only do the D-cache.
   *

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

[Michael Ellerman]

On Wed, 2016-06-29 at 10:54 +0530, Naveen N. Rao wrote:
> On 2016/06/29 10:35AM, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the powerpc tree got a conflict in:
> > 
> >   arch/powerpc/Kconfig
> > 
> > between commit:
> > 
> >   844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")
> 
> Ah, I see that the above commit is not part of powerpc next tree, which 
> explains the conflict.
 
I'll probably merge the fixes branch into next at some point, so then it will
be sorted.

> > I fixed it up (see below - I am not sure this entirely correct) and can

That resolution is fine.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Naveen N. Rao]

On 2016/06/29 10:35AM, Stephen Rothwell wrote:
> Hi all,

Hi Stephen,

> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/Kconfig
> 
> between commit:
> 
>   844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

Ah, I see that the above commit is not part of powerpc next tree, which 
explains the conflict.

> 
> from Linus' tree and commit:
> 
>   156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> 
> from the powerpc tree.
> 
> I fixed it up (see below - I am not sure this entirely correct) 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/powerpc/Kconfig
> index 0a9d439bcda6,ee82f9a09a85..
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -128,7 -128,8 +128,8 @@@ config PP
>   select IRQ_FORCED_THREADING
>   select HAVE_RCU_TABLE_FREE if SMP
>   select HAVE_SYSCALL_TRACEPOINTS
> - select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>  -select HAVE_CBPF_JIT if !PPC64
> ++select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN

'if !PPC64' condition is sufficient, though having the BIG_ENDIAN check 
should be ok too.

Thanks,
Naveen

> + select HAVE_EBPF_JIT if PPC64
>   select HAVE_ARCH_JUMP_LABEL
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_HAS_GCOV_PROFILE_ALL
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/Kconfig

between commit:

  844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

from Linus' tree and commit:

  156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")

from the powerpc tree.

I fixed it up (see below - I am not sure this entirely correct) 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/powerpc/Kconfig
index 0a9d439bcda6,ee82f9a09a85..
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -128,7 -128,8 +128,8 @@@ config PP
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
-   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
 -  select HAVE_CBPF_JIT if !PPC64
++  select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN
+   select HAVE_EBPF_JIT if PPC64
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi all,

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

  arch/powerpc/kernel/prom.c

between commits:

  beff82374b25 ("powerpc: Update cpu_user_features2 in scan_features()")
  4705e02498d6 ("powerpc: Update TM user feature bits in scan_features()")

from Linus' tree and commit:

  5ddd6bb5968e ("powerpc/mm/radix: Use firmware feature to enable Radix MMU")

from the powerpc 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/powerpc/kernel/prom.c
index a15fe1d4e84a,d924cd60fc8e..
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@@ -153,20 -153,20 +154,21 @@@ static struct ibm_pa_feature 
unsigned char   pabit;  /* bit number (big-endian) */
unsigned char   invert; /* if 1, pa bit set => clear feature */
  } ibm_pa_features[] __initdata = {
 -  {0, 0, PPC_FEATURE_HAS_MMU, 0, 0, 0},
 -  {0, 0, PPC_FEATURE_HAS_FPU, 0, 1, 0},
 -  {CPU_FTR_CTRL, 0, 0,0, 3, 0},
 -  {CPU_FTR_NOEXECUTE, 0, 0,   0, 6, 0},
 -  {CPU_FTR_NODSISRALIGN, 0, 0,1, 1, 1},
 -  {0, MMU_FTR_CI_LARGE_PAGE, 0,   1, 2, 0},
 -  {CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
 +  {0, 0, PPC_FEATURE_HAS_MMU, 0,  0, 0, 0},
 +  {0, 0, PPC_FEATURE_HAS_FPU, 0,  0, 1, 0},
 +  {CPU_FTR_CTRL, 0, 0, 0, 0, 3, 0},
 +  {CPU_FTR_NOEXECUTE, 0, 0, 0,0, 6, 0},
 +  {CPU_FTR_NODSISRALIGN, 0, 0, 0, 1, 1, 1},
 +  {0, MMU_FTR_CI_LARGE_PAGE, 0, 0,1, 2, 0},
 +  {CPU_FTR_REAL_LE, 0, PPC_FEATURE_TRUE_LE, 0, 5, 0, 0},
/*
 -   * If the kernel doesn't support TM (ie. 
CONFIG_PPC_TRANSACTIONAL_MEM=n),
 -   * we don't want to turn on CPU_FTR_TM here, so we use CPU_FTR_TM_COMP
 -   * which is 0 if the kernel doesn't support TM.
 +   * If the kernel doesn't support TM (ie CONFIG_PPC_TRANSACTIONAL_MEM=n),
 +   * we don't want to turn on TM here, so we use the *_COMP versions
 +   * which are 0 if the kernel doesn't support TM.
 */
 -  {CPU_FTR_TM_COMP, 0, 0, 22, 0, 0},
 -  {0, MMU_FTR_RADIX, 0,   40, 0, 0},
 +  {CPU_FTR_TM_COMP, 0, 0,
 +   PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
++  {0, MMU_FTR_RADIX, 0, 0,40, 0, 0},
  };
  
  static void __init scan_features(unsigned long node, const unsigned char 
*ftrs,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/include/asm/sections.h between commit b18db0b80867 (KVM
guest: Make pv trampoline code executable) from the  tree and commit
07de8377f748 (powerpc: Fix ABIv2 issue with
dereference_function_descriptor) from the powerpc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/powerpc/include/asm/sections.h
index 521790330672,d1bb96d5a298..
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@@ -39,17 -39,7 +39,18 @@@ static inline int overlaps_kernel_text(
(unsigned long)_stext  end;
  }
  
 +static inline int overlaps_kvm_tmp(unsigned long start, unsigned long end)
 +{
 +#ifdef CONFIG_KVM_GUEST
 +  extern char kvm_tmp[];
 +  return start  (unsigned long)kvm_tmp 
 +  (unsigned long)kvm_tmp[1024 * 1024]  end;
 +#else
 +  return 0;
 +#endif
 +}
 +
+ #if !defined(_CALL_ELF) || _CALL_ELF != 2
  #undef dereference_function_descriptor
  static inline void *dereference_function_descriptor(void *ptr)
  {


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree with the fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/kernel/exceptions-64s.S between commit 0be9d8b61c0c
(powerpc/ppc64: Allow allmodconfig to build (finally !)) from the
fixes tree and commits b1576fec7f4d (powerpc: No need to use dot
symbols when branching to a function) and 354255014a90 (powerpc:
Remove dot symbol usage in exception macros) from the powerpc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/powerpc/kernel/exceptions-64s.S
index 833a68dc4cc8,20f11eb4dff7..
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@@ -891,186 -1025,14 +891,186 @@@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR
std r12,RESULT(r1)
std r11,STACK_FRAME_OVERHEAD-16(r1)
  1:addir3,r1,STACK_FRAME_OVERHEAD
-   bl  .kernel_bad_stack
+   bl  kernel_bad_stack
b   1b
  
 +
 +#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
 +/*
 + * Data area reserved for FWNMI option.
 + * This address (0x7000) is fixed by the RPA.
 + */
 +  .= 0x7000
 +  .globl fwnmi_data_area
 +fwnmi_data_area:
 +
 +  /* pseries and powernv need to keep the whole page from
 +   * 0x7000 to 0x8000 free for use by the firmware
 +   */
 +  . = 0x8000
 +#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
 +
  /*
 - * Here r13 points to the paca, r9 contains the saved CR,
 - * SRR0 and SRR1 are saved in r11 and r12,
 - * r9 - r13 are saved in paca-exgen.
 + * Denorm interrupt assist moved out of line to here, where it remains
 + * close enough to the call site which uses a small conditional branch
   */
 +#ifdef CONFIG_PPC_DENORMALISATION
 +denorm_assist:
 +BEGIN_FTR_SECTION
 +/*
 + * To denormalise we need to move a copy of the register to itself.
 + * For POWER6 do that here for all FP regs.
 + */
 +  mfmsr   r10
 +  ori r10,r10,(MSR_FP|MSR_FE0|MSR_FE1)
 +  xorir10,r10,(MSR_FE0|MSR_FE1)
 +  mtmsrd  r10
 +  sync
 +
 +#define FMR2(n)  fmr (n), (n) ; fmr n+1, n+1
 +#define FMR4(n)  FMR2(n) ; FMR2(n+2)
 +#define FMR8(n)  FMR4(n) ; FMR4(n+4)
 +#define FMR16(n) FMR8(n) ; FMR8(n+8)
 +#define FMR32(n) FMR16(n) ; FMR16(n+16)
 +  FMR32(0)
 +
 +FTR_SECTION_ELSE
 +/*
 + * To denormalise we need to move a copy of the register to itself.
 + * For POWER7 do that here for the first 32 VSX registers only.
 + */
 +  mfmsr   r10
 +  orisr10,r10,MSR_VSX@h
 +  mtmsrd  r10
 +  sync
 +
 +#define XVCPSGNDP2(n) XVCPSGNDP(n,n,n) ; XVCPSGNDP(n+1,n+1,n+1)
 +#define XVCPSGNDP4(n) XVCPSGNDP2(n) ; XVCPSGNDP2(n+2)
 +#define XVCPSGNDP8(n) XVCPSGNDP4(n) ; XVCPSGNDP4(n+4)
 +#define XVCPSGNDP16(n) XVCPSGNDP8(n) ; XVCPSGNDP8(n+8)
 +#define XVCPSGNDP32(n) XVCPSGNDP16(n) ; XVCPSGNDP16(n+16)
 +  XVCPSGNDP32(0)
 +
 +ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
 +
 +BEGIN_FTR_SECTION
 +  b   denorm_done
 +END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
 +/*
 + * To denormalise we need to move a copy of the register to itself.
 + * For POWER8 we need to do that for all 64 VSX registers
 + */
 +  XVCPSGNDP32(32)
 +denorm_done:
 +  mtspr   SPRN_HSRR0,r11
 +  mtcrf   0x80,r9
 +  ld  r9,PACA_EXGEN+EX_R9(r13)
 +  RESTORE_PPR_PACA(PACA_EXGEN, r10)
 +BEGIN_FTR_SECTION
 +  ld  r10,PACA_EXGEN+EX_CFAR(r13)
 +  mtspr   SPRN_CFAR,r10
 +END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
 +  ld  r10,PACA_EXGEN+EX_R10(r13)
 +  ld  r11,PACA_EXGEN+EX_R11(r13)
 +  ld  r12,PACA_EXGEN+EX_R12(r13)
 +  ld  r13,PACA_EXGEN+EX_R13(r13)
 +  HRFID
 +  b   .
 +#endif
 +
 +/*
 + * An interrupt came in while soft-disabled. We set paca-irq_happened, then:
 + * - If it was a decrementer interrupt, we bump the dec to max and and return.
 + * - If it was a doorbell we return immediately since doorbells are edge
 + *   triggered and won't automatically refire.
 + * - else we hard disable and return.
 + * This is called with r10 containing the value to OR to the paca field.
 + *
 + * Warning: This code is reached using a (small) conditional branch from both
 + * the 1st level exception handlers below 0x8000 and the alternate feature
 + * sections of that file which the linker puts right after the text in here.
 + *
 + * For that to work, we thus need this code to be roughly near the middle
 + * so that we can reach it with 32k offsets. Here works... for now.
 + */
 +#define MASKED_INTERRUPT(_H)  \
 +masked_##_H##interrupt:   \
 +  std r11,PACA_EXGEN+EX_R11(r13); \
 +  lbz r11,PACAIRQHAPPENED(r13);   \
 +  or  r11,r11,r10;\
 +  stb r11,PACAIRQHAPPENED(r13);   \
 +  cmpwi   r10,PACA_IRQ_DEC;   \
 +  bne 1f;  

linux-next: manual merge of the powerpc tree with the signal tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/kernel/entry_64.S between commits 40792104b255 (powerpc:
don't mess with r2 in copy_thread() and friends) and 53b50f9483cc
(powerpc: take dereferencing to ret_from_kernel_thread()) from the
signal tree and commit 12660b170253 (powerpc: Fix
MAX_STACK_TRACE_ENTRIES too low warning !) from the powerpc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/powerpc/kernel/entry_64.S
index e9a906c,ad7..000
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@@ -373,7 -373,9 +373,9 @@@ _GLOBAL(ret_from_fork
  _GLOBAL(ret_from_kernel_thread)
bl  .schedule_tail
REST_NVGPRS(r1)
 -  REST_GPR(2,r1)
 +  ld  r14, 0(r14)
+   li  r3,0
+   std r3,0(r1)
mtlrr14
mr  r3,r15
blrl


pgpH8CZwG0sSG.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Paul Mundt]

On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote:
 On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
  On Fri, 2012-03-09 at 00:39 +, Russell King wrote:
  On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
  Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
  I remove it, then I get Kconfig warnings:
 
  warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
  (HAVE_GENERIC_HARDIRQS  HAVE_SPARSE_IRQ)
 
  Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
  
  Nope, Grant patch didn't mention a dependency.
 
 My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
 simple solution was to just make it hidden. It wasn't clear if this was
 desired or not for other arches at the time. There is a mixture of
 settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
 it user selectable for 64-bit.
 
 I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
 a hidden option. It really just needs the okay from SuperH folks.
 
We basically want it always-enabled for 32-bit and it doesn't matter much
about 64-bit. In the future I'll probably fix up the 64-bit stuff to use
it too and then we'll just leave it on all the time, but it's not such a
big deal if it's not visible for enabling on 64-bit at the moment given
that it's probably broken there at the moment.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Rob Herring]

On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
 On Fri, 2012-03-09 at 00:39 +, Russell King wrote:
 On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
 Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
 I remove it, then I get Kconfig warnings:

 warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
 (HAVE_GENERIC_HARDIRQS  HAVE_SPARSE_IRQ)

 Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
 
 Nope, Grant patch didn't mention a dependency.

My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
simple solution was to just make it hidden. It wasn't clear if this was
desired or not for other arches at the time. There is a mixture of
settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
it user selectable for 64-bit.

I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
a hidden option. It really just needs the okay from SuperH folks.

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote:
 On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
  Hi Mikey,
  
  On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling mi...@neuling.org 
  wrote:
  
   Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.  
   
   In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
   selectable, which we don't want anymore since ad5b7f1350c2.
  
  Yes, indeed. I will fix up the merge resolution for tomorrow.
 
 This is my fault. Grant's patch had a collision and I manually fixed it
 up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
 originally took out.

Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
I remove it, then I get Kconfig warnings:

warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies 
(HAVE_GENERIC_HARDIRQS  HAVE_SPARSE_IRQ)

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Russell King]

On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
 Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
 I remove it, then I get Kconfig warnings:
 
 warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
 (HAVE_GENERIC_HARDIRQS  HAVE_SPARSE_IRQ)

Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Fri, 2012-03-09 at 00:39 +, Russell King wrote:
 On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
  Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
  I remove it, then I get Kconfig warnings:
  
  warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
  (HAVE_GENERIC_HARDIRQS  HAVE_SPARSE_IRQ)
 
 Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?

Nope, Grant patch didn't mention a dependency.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/Kconfig between commit 2ed86b16eabe (irq: make SPARSE_IRQ
an optionally hidden option) from the arm tree and commit ad5b7f1350c2
(powerpc: Make SPARSE_IRQ required) from the powerpc tree.

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

diff --cc arch/powerpc/Kconfig
index bf7dbc2,4eecaaa..000
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -133,7 -133,8 +133,8 @@@ config PP
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS  PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
 -  select HAVE_SPARSE_IRQ
 +  select MAY_HAVE_SPARSE_IRQ
+   select SPARSE_IRQ
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL


pgpePVp6jGQtI.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Michael Neuling]

 Today's linux-next merge of the powerpc tree got a conflict in
 arch/powerpc/Kconfig between commit 2ed86b16eabe (irq: make SPARSE_IRQ
 an optionally hidden option) from the arm tree and commit ad5b7f1350c2
 (powerpc: Make SPARSE_IRQ required) from the powerpc tree.
 
 I fixed it up (see below) and can carry the fix as necessary.
 --=20
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 
 diff --cc arch/powerpc/Kconfig
 index bf7dbc2,4eecaaa..000
 --- a/arch/powerpc/Kconfig
 +++ b/arch/powerpc/Kconfig
 @@@ -133,7 -133,8 +133,8 @@@ config PP
   select HAVE_REGS_AND_STACK_ACCESS_API
   select HAVE_HW_BREAKPOINT if PERF_EVENTS  PPC_BOOK3S_64
   select HAVE_GENERIC_HARDIRQS
  -select HAVE_SPARSE_IRQ
  +select MAY_HAVE_SPARSE_IRQ
 + select SPARSE_IRQ

Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.  

In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
selectable, which we don't want anymore since ad5b7f1350c2.

Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi Mikey,

On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling mi...@neuling.org wrote:

 Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.  
 
 In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
 selectable, which we don't want anymore since ad5b7f1350c2.

Yes, indeed. I will fix up the merge resolution for tomorrow.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp5zWZbCEzQx.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Benjamin Herrenschmidt]

On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
 Hi Mikey,
 
 On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling mi...@neuling.org wrote:
 
  Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.  
  
  In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
  selectable, which we don't want anymore since ad5b7f1350c2.
 
 Yes, indeed. I will fix up the merge resolution for tomorrow.

This is my fault. Grant's patch had a collision and I manually fixed it
up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
originally took out.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
include/linux/kvm.h between commit
3cfc3092f40bc37c57ba556cfd8de4218f2135ab (KVM: x86: Add
KVM_GET/SET_VCPU_EVENTS) (and others) from Linus' tree and commit
e15a113700324f7fdcee95589875daed2b98a2fe (powerpc/kvm: Sync guest
visible MMU state) from the powerpc tree.

Just overlapping additions.  I fixed it up (see below) and can carry the
fix for a while.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/kvm.h
index 2d241da,caf6173..000
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@@ -487,15 -436,9 +487,18 @@@ struct kvm_ioeventfd 
  #endif
  #define KVM_CAP_IOEVENTFD 36
  #define KVM_CAP_SET_IDENTITY_MAP_ADDR 37
 +#ifdef __KVM_HAVE_XEN_HVM
 +#define KVM_CAP_XEN_HVM 38
 +#endif
 +#define KVM_CAP_ADJUST_CLOCK 39
 +#define KVM_CAP_INTERNAL_ERROR_DATA 40
 +#ifdef __KVM_HAVE_VCPU_EVENTS
 +#define KVM_CAP_VCPU_EVENTS 41
 +#endif
 +#define KVM_CAP_S390_PSW 42
+ /* KVM upstream has more features, but we synched this number.
+Linux, please remove this comment on rebase. */
+ #define KVM_CAP_PPC_SEGSTATE 43
  
  #ifdef KVM_CAP_IRQ_ROUTING
  
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul, Ben,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/include/asm/dcr-regs.h between commit
6fbc779c03591ee536fef9efb7d7e20f281d0b5c (ibm_newemac: Fix EMAC soft
reset on 460EX/GT) from Linus' tree and commit
fbcc4bacee30cad4e4a13d05492a9ed0c9c3e8c7 (ibm_newemac: MAL support for
PowerPC 405EZ) from the powerpc tree.

Just overlapping additions.  I fixed it up by taking both additions.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/



pgparPraxFavL.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul, Ben,

Today's linux-next merge of the powerpc tree got a conflict in
drivers/net/ibm_newemac/core.h between commit
6fbc779c03591ee536fef9efb7d7e20f281d0b5c (ibm_newemac: Fix EMAC soft
reset on 460EX/GT) from Linus' tree and commit
b68d185ab12b1fc8000432c5d5ab5404d4788b4c (ibm_newemac: Allow the no
flow control EMAC feature to work) from the powerpc tree.

Just overlapping additions.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpW36TSUSHvU.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Steven Rostedt]

On Mon, 14 Jul 2008, Stephen Rothwell wrote:

 Hi Paul, Ben,

 Today's linux-next merge of the powerpc tree got a conflict in
 arch/powerpc/Kconfig between commit
 4e491d14f2506b218d678935c25a7027b79178b1 (ftrace: support for PowerPC)
 from the ftrace tree and commit 3affedc4e1ce837033b6c5e9289d2ce2f5a62d31
 (powerpc/dma: implement new dma_*map*_attrs() interfaces) from the
 powerpc tree.

 The former commit moved the select HAVE_OPROFILE to the bottom of the
 config PPC list (for no reason that I can fathom) while the latter
 added another select.  Simple fixup.  I can carry it.

I heard someone mention that they try to keep the configs in alphabetical
order. I did the move of OPROFILE for just that reason. I should have said
so in the change log. Oh well.

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul, Ben,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/Kconfig between commit
4e491d14f2506b218d678935c25a7027b79178b1 (ftrace: support for PowerPC)
from the ftrace tree and commit 3affedc4e1ce837033b6c5e9289d2ce2f5a62d31
(powerpc/dma: implement new dma_*map*_attrs() interfaces) from the
powerpc tree.

The former commit moved the select HAVE_OPROFILE to the bottom of the
config PPC list (for no reason that I can fathom) while the latter
added another select.  Simple fixup.  I can carry it.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp8VG816Vsbr.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Benjamin Herrenschmidt]

On Fri, 2008-07-11 at 21:01 +0200, Bartlomiej Zolnierkiewicz wrote:
 
 Since I haven't heard back from Ben [1] on ide-pmac/media-bay IRQ issue
 I took another look at ide-pmac patches and I think that it should be
 possible to rework them in such way that consecutive ide patches ( 100)
 won't depend on ide-pmac: media-bay support fixes (take 4) patch.
 
 This would allow us to re-schedule it to 2.6.28 (which is probably what
 we want because 2.6.26 is probably just around the corner and we will be
 pretty busy with 2.6.27 merge window soon).  Ben, what's your opinion?
 
 [1] which doesn't surprise me given his new responsibilities ;)

That and I just moved house... been hectic lately.

I'll give another shot at the IRQ issues early next week, and if it
still doesn't work, we'll postpone.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in
drivers/macintosh/mediabay.c between commit
7ad963b103d3863b1161c59f3e65a435979804ed (ide-pmac: media-bay support
fixes (take 4)) from the ide tree and commit
9a24729d8aeef967eac7af71c6a69edc83d06558 (macintosh/media bay: Convert
semaphore to mutex) from the powerpc tree.

I just applied the up/down - mutex_unlock/mutex_lock change to the ide
tree version.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp3abMpAZUH6.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Daniel Walker]

On Mon, 2008-07-07 at 23:07 +1000, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the powerpc tree got a conflict in
 drivers/macintosh/mediabay.c between commit
 7ad963b103d3863b1161c59f3e65a435979804ed (ide-pmac: media-bay support
 fixes (take 4)) from the ide tree and commit
 9a24729d8aeef967eac7af71c6a69edc83d06558 (macintosh/media bay: Convert
 semaphore to mutex) from the powerpc tree.
 
 I just applied the up/down - mutex_unlock/mutex_lock change to the ide
 tree version.


It doesn't look like the IDE patches change the locking at all, so the
semaphore to mutex change should still be safe every with the IDE
changes.

From an organizational prospective, I think it makes sense for the IDE
changes to go on top of the powerpc.git mediabay changes .. Since the
most current mediabay driver is in the powerpc.git AFAIK.

Daniel

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Jean Delvare]

On Thu, 3 Jul 2008 23:54:26 -0600, Grant Likely wrote:
 On Thu, Jul 3, 2008 at 9:24 AM, Grant Likely [EMAIL PROTECTED] wrote:
  On Thu, Jul 03, 2008 at 08:22:18AM -0400, Jon Smirl wrote:
  Testing was good when the patch was initially posted in January. In
  the last six months the initial patch set has been sliced and diced
  into a bunch of different pieces but the contents of this patch are
  essentially unchanged.
 
  I don't care which tree it uses to get to mainline, I'd just like to
  see it get merged.
 
  Me too, but it is used by some of the mpc8xxx platforms too, so I'd like
  to see an ack from one of those users also.
 
 Okay, I've tested it on my board.  All looks good to me.  I'd prefer
 to hear back from one of the Freescale folks, but on a second reading
 I think it is pretty safe.  I'll make sure any merge conflicts are
 resolved.
 
 Jean, is it okay with you to drop it from your tree and merge it through mine?

Sure, no problem. It's done now, the patch is yours.

-- 
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Grant Likely]

On Thu, Jul 03, 2008 at 08:22:18AM -0400, Jon Smirl wrote:
 Testing was good when the patch was initially posted in January. In
 the last six months the initial patch set has been sliced and diced
 into a bunch of different pieces but the contents of this patch are
 essentially unchanged.
 
 I don't care which tree it uses to get to mainline, I'd just like to
 see it get merged.

Me too, but it is used by some of the mpc8xxx platforms too, so I'd like
to see an ack from one of those users also.

Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Grant Likely]

On Thu, Jul 3, 2008 at 9:24 AM, Grant Likely [EMAIL PROTECTED] wrote:
 On Thu, Jul 03, 2008 at 08:22:18AM -0400, Jon Smirl wrote:
 Testing was good when the patch was initially posted in January. In
 the last six months the initial patch set has been sliced and diced
 into a bunch of different pieces but the contents of this patch are
 essentially unchanged.

 I don't care which tree it uses to get to mainline, I'd just like to
 see it get merged.

 Me too, but it is used by some of the mpc8xxx platforms too, so I'd like
 to see an ack from one of those users also.

Okay, I've tested it on my board.  All looks good to me.  I'd prefer
to hear back from one of the Freescale folks, but on a second reading
I think it is pretty safe.  I'll make sure any merge conflicts are
resolved.

Jean, is it okay with you to drop it from your tree and merge it through mine?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/sysdev/fsl_soc.c between commit
4eac6a8b17ce5ebe66eb94b6a0b43aa3a2bf7ea6 (i2c-mpc: Convert to an
of_platform driver) from the i2c tree and commits
22fb7d9be593181e2f779cf7a8421703a6be713b ([POWERPC] fsl: Add warning for
unrecognized I2C nodes in the device tree),
64f9b5ee17ee7974d7cc58d75221432d86960ba3 ([POWERPC] fsl: Add CS4270 i2c
data to fsl_soc.c) and e026892c85571e12f11abffde5a90bcc704d663e
([POWERPC] fsl: Update fsl_soc to use cell-index property of I2C nodes)
from the powerpc tree.

The changes from the powerpc tree modify code that the i2c tree removes.
I used the i2c tree's version, but someone should check the result.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpT6hcrQgpEm.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree

[Grant Likely]

On Thu, Jul 03, 2008 at 01:39:05PM +1000, Stephen Rothwell wrote:
 Hi Paul,
 
 Today's linux-next merge of the powerpc tree got a conflict in
 arch/powerpc/sysdev/fsl_soc.c between commit
 4eac6a8b17ce5ebe66eb94b6a0b43aa3a2bf7ea6 (i2c-mpc: Convert to an
 of_platform driver) from the i2c tree and commits

It probably would have been better for this patch to go in via the
PowerPC tree.  It only touches powerpc-specific i2c code, not any i2c
core code.  There are quite a few MPC ports which use this driver,
I'd be happier to see it dropped from the i2c tree and merged in via
either Kumar or myself.

I'd also like to see some acks from people who have tested this patch
before it goes in.  (I'm just as guilty here; I'll apply it and test it
to my tree tomorrow).

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the powerpc tree got a conflict in
drivers/macintosh/mediabay.c between commit
3fdba626506365e3aaf49140632120cd9156c2e8 (ide-pmac: media-bay support
fixes (take 3)) from the ide tree and commit
9a24729d8aeef967eac7af71c6a69edc83d06558 (macintosh/media bay: Convert
semaphore to mutex) from the powerpc tree.

I used the version from the ide tree but with the down/up -
mutex_lock/mutex_unlock changes applied.  It may be worth a check to make
sure I got it right.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpzjvbx89bEb.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev