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

2020-05-22 Thread Stephen Rothwell
Hi all,

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

  kernel/Makefile

between commit:

  d08b9f0ca660 ("scs: Add support for Clang's Shadow Call Stack (SCS)")

from the arm64 tree and commit:

  dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")

from the tip 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/Makefile
index c332eb9d4841,5d935b63f812..
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -103,7 -107,7 +107,8 @@@ obj-$(CONFIG_TRACEPOINTS) += trace
  obj-$(CONFIG_IRQ_WORK) += irq_work.o
  obj-$(CONFIG_CPU_PM) += cpu_pm.o
  obj-$(CONFIG_BPF) += bpf/
 +obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o
+ obj-$(CONFIG_KCSAN) += kcsan/
  
  obj-$(CONFIG_PERF_EVENTS) += events/
  


pgpOHFCgl4aac.pgp
Description: OpenPGP digital signature


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

2019-04-14 Thread Stephen Rothwell
Hi all,

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

  mm/kasan/Makefile

between commit:

  e2092740b723 ("kasan: Makefile: Replace -pg with CC_FLAGS_FTRACE")

from the arm64 tree and commit:

  57b78a62e7f2 ("x86/uaccess, kasan: Fix KASAN vs SMAP")

from the tip 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 mm/kasan/Makefile
index f06ee820d356,613dfe681e9f..
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@@ -5,9 -6,10 +6,10 @@@ UBSAN_SANITIZE_generic_report.o := 
  UBSAN_SANITIZE_tags.o := n
  KCOV_INSTRUMENT := n
  
 -CFLAGS_REMOVE_common.o = -pg
 -CFLAGS_REMOVE_generic.o = -pg
 -CFLAGS_REMOVE_generic_report.o = -pg
 -CFLAGS_REMOVE_tags.o = -pg
 +CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE)
 +CFLAGS_REMOVE_generic.o = $(CC_FLAGS_FTRACE)
++CFLAGS_REMOVE_generic_report.o = $(CC_FLAGS_FTRACE)
 +CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
  
  # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
  # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533


pgpAbjFkbU_bG.pgp
Description: OpenPGP digital signature


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

2019-04-14 Thread Stephen Rothwell
Hi all,

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

  arch/s390/include/asm/Kbuild

between commit:

  fdcd06a8ab77 ("arch: Use asm-generic header for asm/mmiowb.h")

from the arm64 tree and commit:

  46ad0840b158 ("locking/rwsem: Remove arch specific rwsem files")

from the tip 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/s390/include/asm/Kbuild
index bdc4f06a04c5,d5fadefea33c..
--- a/arch/s390/include/asm/Kbuild
+++ b/arch/s390/include/asm/Kbuild
@@@ -20,8 -20,6 +20,7 @@@ generic-y += local.
  generic-y += local64.h
  generic-y += mcs_spinlock.h
  generic-y += mm-arch-hooks.h
 +generic-y += mmiowb.h
- generic-y += rwsem.h
  generic-y += trace_clock.h
  generic-y += unaligned.h
  generic-y += word-at-a-time.h


pgpSgACLcj9JN.pgp
Description: OpenPGP digital signature


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

2017-11-13 Thread Stephen Rothwell
Hi all,

On Wed, 1 Nov 2017 16:47:18 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/Kconfig
> 
> between commit:
> 
>   396a5d4a5c32 ("arm64: Unconditionally support 
> {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}")
> 
> from the arm64 tree and commit:
> 
>   087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over to 
> qrwlocks")
> 
> from the tip 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/arm64/Kconfig
> index 38f8d26208af,6205f521b648..
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -21,8 -21,25 +21,25 @@@ config ARM6
>   select ARCH_HAS_STRICT_KERNEL_RWX
>   select ARCH_HAS_STRICT_MODULE_RWX
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>  -select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
>  +select ARCH_HAVE_NMI_SAFE_CMPXCHG
> + select ARCH_INLINE_READ_LOCK if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_BH if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_IRQSAVE if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_BH if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_IRQRESTORE if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_BH if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_IRQSAVE if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_BH if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE if !PREEMPT
>   select ARCH_USE_CMPXCHG_LOCKREF
> + select ARCH_USE_QUEUED_RWLOCKS
>   select ARCH_SUPPORTS_MEMORY_FAILURE
>   select ARCH_SUPPORTS_ATOMIC_RMW
>   select ARCH_SUPPORTS_NUMA_BALANCING

Just a reminder that this conflict still exists (but is now between the
arm64 and Linus' trees - since part of the tip tree has been merged).

-- 
Cheers,
Stephen Rothwell


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

2017-11-13 Thread Stephen Rothwell
Hi all,

On Wed, 1 Nov 2017 16:47:18 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/Kconfig
> 
> between commit:
> 
>   396a5d4a5c32 ("arm64: Unconditionally support 
> {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}")
> 
> from the arm64 tree and commit:
> 
>   087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over to 
> qrwlocks")
> 
> from the tip 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/arm64/Kconfig
> index 38f8d26208af,6205f521b648..
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -21,8 -21,25 +21,25 @@@ config ARM6
>   select ARCH_HAS_STRICT_KERNEL_RWX
>   select ARCH_HAS_STRICT_MODULE_RWX
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>  -select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
>  +select ARCH_HAVE_NMI_SAFE_CMPXCHG
> + select ARCH_INLINE_READ_LOCK if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_BH if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_READ_LOCK_IRQSAVE if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_BH if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_READ_UNLOCK_IRQRESTORE if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_BH if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_WRITE_LOCK_IRQSAVE if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_BH if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_IRQ if !PREEMPT
> + select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE if !PREEMPT
>   select ARCH_USE_CMPXCHG_LOCKREF
> + select ARCH_USE_QUEUED_RWLOCKS
>   select ARCH_SUPPORTS_MEMORY_FAILURE
>   select ARCH_SUPPORTS_ATOMIC_RMW
>   select ARCH_SUPPORTS_NUMA_BALANCING

Just a reminder that this conflict still exists (but is now between the
arm64 and Linus' trees - since part of the tip tree has been merged).

-- 
Cheers,
Stephen Rothwell


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

2017-10-31 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/Kconfig

between commit:

  396a5d4a5c32 ("arm64: Unconditionally support {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}")

from the arm64 tree and commit:

  087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over to 
qrwlocks")

from the tip 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/arm64/Kconfig
index 38f8d26208af,6205f521b648..
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -21,8 -21,25 +21,25 @@@ config ARM6
select ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_HAS_STRICT_MODULE_RWX
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 -  select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
 +  select ARCH_HAVE_NMI_SAFE_CMPXCHG
+   select ARCH_INLINE_READ_LOCK if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_BH if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_IRQSAVE if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_BH if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_IRQRESTORE if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_BH if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_IRQSAVE if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_BH if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE if !PREEMPT
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_USE_QUEUED_RWLOCKS
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_NUMA_BALANCING


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

2017-10-31 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/Kconfig

between commit:

  396a5d4a5c32 ("arm64: Unconditionally support {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}")

from the arm64 tree and commit:

  087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over to 
qrwlocks")

from the tip 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/arm64/Kconfig
index 38f8d26208af,6205f521b648..
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -21,8 -21,25 +21,25 @@@ config ARM6
select ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_HAS_STRICT_MODULE_RWX
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 -  select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
 +  select ARCH_HAVE_NMI_SAFE_CMPXCHG
+   select ARCH_INLINE_READ_LOCK if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_BH if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_READ_LOCK_IRQSAVE if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_BH if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_READ_UNLOCK_IRQRESTORE if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_BH if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_WRITE_LOCK_IRQSAVE if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_BH if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_IRQ if !PREEMPT
+   select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE if !PREEMPT
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_USE_QUEUED_RWLOCKS
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_NUMA_BALANCING


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

2017-09-03 Thread Stephen Rothwell
Hi all,

On Tue, 22 Aug 2017 13:38:02 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/firmware/efi/libstub/arm64-stub.c
> 
> between commit:
> 
>   170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")
> 
> from the arm64 tree and commit:
> 
>   0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
> markers")
> 
> from the tip 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/firmware/efi/libstub/arm64-stub.c
> index af6ae95a5e34,f7a6970e9abc..
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@@ -9,10 -9,17 +9,18 @@@
>* published by the Free Software Foundation.
>*
>*/
> + 
> + /*
> +  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
> +  * references to the section markers, override their visibility as 'hidden'
> +  */
> + #pragma GCC visibility push(hidden)
> + #include 
> + #pragma GCC visibility pop
> + 
>   #include 
>   #include 
>  +#include 
> - #include 
>   #include 
>   
>   #include "efistub.h"

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell


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

2017-09-03 Thread Stephen Rothwell
Hi all,

On Tue, 22 Aug 2017 13:38:02 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/firmware/efi/libstub/arm64-stub.c
> 
> between commit:
> 
>   170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")
> 
> from the arm64 tree and commit:
> 
>   0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
> markers")
> 
> from the tip 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/firmware/efi/libstub/arm64-stub.c
> index af6ae95a5e34,f7a6970e9abc..
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@@ -9,10 -9,17 +9,18 @@@
>* published by the Free Software Foundation.
>*
>*/
> + 
> + /*
> +  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
> +  * references to the section markers, override their visibility as 'hidden'
> +  */
> + #pragma GCC visibility push(hidden)
> + #include 
> + #pragma GCC visibility pop
> + 
>   #include 
>   #include 
>  +#include 
> - #include 
>   #include 
>   
>   #include "efistub.h"

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell


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

2017-08-21 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")

from the arm64 tree and commit:

  0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
markers")

from the tip 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/firmware/efi/libstub/arm64-stub.c
index af6ae95a5e34,f7a6970e9abc..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -9,10 -9,17 +9,18 @@@
   * published by the Free Software Foundation.
   *
   */
+ 
+ /*
+  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+  * references to the section markers, override their visibility as 'hidden'
+  */
+ #pragma GCC visibility push(hidden)
+ #include 
+ #pragma GCC visibility pop
+ 
  #include 
  #include 
 +#include 
- #include 
  #include 
  
  #include "efistub.h"


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

2017-08-21 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")

from the arm64 tree and commit:

  0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
markers")

from the tip 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/firmware/efi/libstub/arm64-stub.c
index af6ae95a5e34,f7a6970e9abc..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -9,10 -9,17 +9,18 @@@
   * published by the Free Software Foundation.
   *
   */
+ 
+ /*
+  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+  * references to the section markers, override their visibility as 'hidden'
+  */
+ #pragma GCC visibility push(hidden)
+ #include 
+ #pragma GCC visibility pop
+ 
  #include 
  #include 
 +#include 
- #include 
  #include 
  
  #include "efistub.h"


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

2017-07-02 Thread Stephen Rothwell
Hi all,

With the merge window opening, just a reminder that this conflict still exists.

On Fri, 16 Jun 2017 13:25:03 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/acpi/apei/ghes.c
> 
> between commit:
> 
>   d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8")
> 
> from the arm64 tree and commit:
> 
>   7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")
> 
> from the tip 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/acpi/apei/ghes.c
> index dfdb33f09f0a,d2c8a9286fa8..
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@@ -810,59 -718,10 +810,59 @@@ static int ghes_notify_hed(struct notif
>   return ret;
>   }
>   
> - static struct notifier_block ghes_notifier_sci = {
> - .notifier_call = ghes_notify_sci,
> + static struct notifier_block ghes_notifier_hed = {
> + .notifier_call = ghes_notify_hed,
>   };
>   
>  +#ifdef CONFIG_ACPI_APEI_SEA
>  +static LIST_HEAD(ghes_sea);
>  +
>  +/*
>  + * Return 0 only if one of the SEA error sources successfully reported an 
> error
>  + * record sent from the firmware.
>  + */
>  +int ghes_notify_sea(void)
>  +{
>  +struct ghes *ghes;
>  +int ret = -ENOENT;
>  +
>  +rcu_read_lock();
>  +list_for_each_entry_rcu(ghes, _sea, list) {
>  +if (!ghes_proc(ghes))
>  +ret = 0;
>  +}
>  +rcu_read_unlock();
>  +return ret;
>  +}
>  +
>  +static void ghes_sea_add(struct ghes *ghes)
>  +{
>  +mutex_lock(_list_mutex);
>  +list_add_rcu(>list, _sea);
>  +mutex_unlock(_list_mutex);
>  +}
>  +
>  +static void ghes_sea_remove(struct ghes *ghes)
>  +{
>  +mutex_lock(_list_mutex);
>  +list_del_rcu(>list);
>  +mutex_unlock(_list_mutex);
>  +synchronize_rcu();
>  +}
>  +#else /* CONFIG_ACPI_APEI_SEA */
>  +static inline void ghes_sea_add(struct ghes *ghes)
>  +{
>  +pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
> supported\n",
>  +   ghes->generic->header.source_id);
>  +}
>  +
>  +static inline void ghes_sea_remove(struct ghes *ghes)
>  +{
>  +pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
> supported\n",
>  +   ghes->generic->header.source_id);
>  +}
>  +#endif /* CONFIG_ACPI_APEI_SEA */
>  +
>   #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>   /*
>* printk is not safe in NMI context.  So in NMI handler, we allocate
> @@@ -1096,15 -966,10 +1096,18 @@@ static int ghes_probe(struct platform_d
>   case ACPI_HEST_NOTIFY_POLLED:
>   case ACPI_HEST_NOTIFY_EXTERNAL:
>   case ACPI_HEST_NOTIFY_SCI:
> + case ACPI_HEST_NOTIFY_GSIV:
> + case ACPI_HEST_NOTIFY_GPIO:
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
>  +pr_warn(GHES_PFX "Generic hardware error source: %d 
> notified via SEA is not supported\n",
>  +generic->header.source_id);
>  +rc = -ENOTSUPP;
>  +goto err;
>  +}
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
>   pr_warn(GHES_PFX "Generic hardware error source: %d 
> notified via NMI interrupt is not supported!\n",
> @@@ -1162,16 -1027,17 +1165,20 @@@
>   goto err_edac_unreg;
>   }
>   break;
> + 
>   case ACPI_HEST_NOTIFY_SCI:
> + case ACPI_HEST_NOTIFY_GSIV:
> + case ACPI_HEST_NOTIFY_GPIO:
>   mutex_lock(_list_mutex);
> - if (list_empty(_sci))
> - register_acpi_hed_notifier(_notifier_sci);
> - list_add_rcu(>list, _sci);
> + if (list_empty(_hed))
> + register_acpi_hed_notifier(_notifier_hed);
> + list_add_rcu(>list, _hed);
>   mutex_unlock(_list_mutex);
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +ghes_sea_add(ghes);
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   ghes_nmi_add(ghes);
>   break;
> @@@ -1218,9 -1084,7 +1228,10 @@@ static int ghes_remove(struct platform_
>   mutex_unlock(_list_mutex);
>   synchronize_rcu();
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +ghes_sea_remove(ghes);
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   ghes_nmi_remove(ghes);
>   break;


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

2017-07-02 Thread Stephen Rothwell
Hi all,

With the merge window opening, just a reminder that this conflict still exists.

On Fri, 16 Jun 2017 13:25:03 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/acpi/apei/ghes.c
> 
> between commit:
> 
>   d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8")
> 
> from the arm64 tree and commit:
> 
>   7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")
> 
> from the tip 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/acpi/apei/ghes.c
> index dfdb33f09f0a,d2c8a9286fa8..
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@@ -810,59 -718,10 +810,59 @@@ static int ghes_notify_hed(struct notif
>   return ret;
>   }
>   
> - static struct notifier_block ghes_notifier_sci = {
> - .notifier_call = ghes_notify_sci,
> + static struct notifier_block ghes_notifier_hed = {
> + .notifier_call = ghes_notify_hed,
>   };
>   
>  +#ifdef CONFIG_ACPI_APEI_SEA
>  +static LIST_HEAD(ghes_sea);
>  +
>  +/*
>  + * Return 0 only if one of the SEA error sources successfully reported an 
> error
>  + * record sent from the firmware.
>  + */
>  +int ghes_notify_sea(void)
>  +{
>  +struct ghes *ghes;
>  +int ret = -ENOENT;
>  +
>  +rcu_read_lock();
>  +list_for_each_entry_rcu(ghes, _sea, list) {
>  +if (!ghes_proc(ghes))
>  +ret = 0;
>  +}
>  +rcu_read_unlock();
>  +return ret;
>  +}
>  +
>  +static void ghes_sea_add(struct ghes *ghes)
>  +{
>  +mutex_lock(_list_mutex);
>  +list_add_rcu(>list, _sea);
>  +mutex_unlock(_list_mutex);
>  +}
>  +
>  +static void ghes_sea_remove(struct ghes *ghes)
>  +{
>  +mutex_lock(_list_mutex);
>  +list_del_rcu(>list);
>  +mutex_unlock(_list_mutex);
>  +synchronize_rcu();
>  +}
>  +#else /* CONFIG_ACPI_APEI_SEA */
>  +static inline void ghes_sea_add(struct ghes *ghes)
>  +{
>  +pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
> supported\n",
>  +   ghes->generic->header.source_id);
>  +}
>  +
>  +static inline void ghes_sea_remove(struct ghes *ghes)
>  +{
>  +pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
> supported\n",
>  +   ghes->generic->header.source_id);
>  +}
>  +#endif /* CONFIG_ACPI_APEI_SEA */
>  +
>   #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>   /*
>* printk is not safe in NMI context.  So in NMI handler, we allocate
> @@@ -1096,15 -966,10 +1096,18 @@@ static int ghes_probe(struct platform_d
>   case ACPI_HEST_NOTIFY_POLLED:
>   case ACPI_HEST_NOTIFY_EXTERNAL:
>   case ACPI_HEST_NOTIFY_SCI:
> + case ACPI_HEST_NOTIFY_GSIV:
> + case ACPI_HEST_NOTIFY_GPIO:
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
>  +pr_warn(GHES_PFX "Generic hardware error source: %d 
> notified via SEA is not supported\n",
>  +generic->header.source_id);
>  +rc = -ENOTSUPP;
>  +goto err;
>  +}
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
>   pr_warn(GHES_PFX "Generic hardware error source: %d 
> notified via NMI interrupt is not supported!\n",
> @@@ -1162,16 -1027,17 +1165,20 @@@
>   goto err_edac_unreg;
>   }
>   break;
> + 
>   case ACPI_HEST_NOTIFY_SCI:
> + case ACPI_HEST_NOTIFY_GSIV:
> + case ACPI_HEST_NOTIFY_GPIO:
>   mutex_lock(_list_mutex);
> - if (list_empty(_sci))
> - register_acpi_hed_notifier(_notifier_sci);
> - list_add_rcu(>list, _sci);
> + if (list_empty(_hed))
> + register_acpi_hed_notifier(_notifier_hed);
> + list_add_rcu(>list, _hed);
>   mutex_unlock(_list_mutex);
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +ghes_sea_add(ghes);
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   ghes_nmi_add(ghes);
>   break;
> @@@ -1218,9 -1084,7 +1228,10 @@@ static int ghes_remove(struct platform_
>   mutex_unlock(_list_mutex);
>   synchronize_rcu();
>   break;
>  +case ACPI_HEST_NOTIFY_SEA:
>  +ghes_sea_remove(ghes);
>  +break;
> + 
>   case ACPI_HEST_NOTIFY_NMI:
>   ghes_nmi_remove(ghes);
>   break;

-- 
Cheers,
Stephen 

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

2017-06-15 Thread Stephen Rothwell
Hi all,

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

  drivers/acpi/apei/ghes.c

between commit:

  d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8")

from the arm64 tree and commit:

  7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")

from the tip 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/acpi/apei/ghes.c
index dfdb33f09f0a,d2c8a9286fa8..
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@@ -810,59 -718,10 +810,59 @@@ static int ghes_notify_hed(struct notif
return ret;
  }
  
- static struct notifier_block ghes_notifier_sci = {
-   .notifier_call = ghes_notify_sci,
+ static struct notifier_block ghes_notifier_hed = {
+   .notifier_call = ghes_notify_hed,
  };
  
 +#ifdef CONFIG_ACPI_APEI_SEA
 +static LIST_HEAD(ghes_sea);
 +
 +/*
 + * Return 0 only if one of the SEA error sources successfully reported an 
error
 + * record sent from the firmware.
 + */
 +int ghes_notify_sea(void)
 +{
 +  struct ghes *ghes;
 +  int ret = -ENOENT;
 +
 +  rcu_read_lock();
 +  list_for_each_entry_rcu(ghes, _sea, list) {
 +  if (!ghes_proc(ghes))
 +  ret = 0;
 +  }
 +  rcu_read_unlock();
 +  return ret;
 +}
 +
 +static void ghes_sea_add(struct ghes *ghes)
 +{
 +  mutex_lock(_list_mutex);
 +  list_add_rcu(>list, _sea);
 +  mutex_unlock(_list_mutex);
 +}
 +
 +static void ghes_sea_remove(struct ghes *ghes)
 +{
 +  mutex_lock(_list_mutex);
 +  list_del_rcu(>list);
 +  mutex_unlock(_list_mutex);
 +  synchronize_rcu();
 +}
 +#else /* CONFIG_ACPI_APEI_SEA */
 +static inline void ghes_sea_add(struct ghes *ghes)
 +{
 +  pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
supported\n",
 + ghes->generic->header.source_id);
 +}
 +
 +static inline void ghes_sea_remove(struct ghes *ghes)
 +{
 +  pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
supported\n",
 + ghes->generic->header.source_id);
 +}
 +#endif /* CONFIG_ACPI_APEI_SEA */
 +
  #ifdef CONFIG_HAVE_ACPI_APEI_NMI
  /*
   * printk is not safe in NMI context.  So in NMI handler, we allocate
@@@ -1096,15 -966,10 +1096,18 @@@ static int ghes_probe(struct platform_d
case ACPI_HEST_NOTIFY_POLLED:
case ACPI_HEST_NOTIFY_EXTERNAL:
case ACPI_HEST_NOTIFY_SCI:
+   case ACPI_HEST_NOTIFY_GSIV:
+   case ACPI_HEST_NOTIFY_GPIO:
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
 +  pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via SEA is not supported\n",
 +  generic->header.source_id);
 +  rc = -ENOTSUPP;
 +  goto err;
 +  }
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via NMI interrupt is not supported!\n",
@@@ -1162,16 -1027,17 +1165,20 @@@
goto err_edac_unreg;
}
break;
+ 
case ACPI_HEST_NOTIFY_SCI:
+   case ACPI_HEST_NOTIFY_GSIV:
+   case ACPI_HEST_NOTIFY_GPIO:
mutex_lock(_list_mutex);
-   if (list_empty(_sci))
-   register_acpi_hed_notifier(_notifier_sci);
-   list_add_rcu(>list, _sci);
+   if (list_empty(_hed))
+   register_acpi_hed_notifier(_notifier_hed);
+   list_add_rcu(>list, _hed);
mutex_unlock(_list_mutex);
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  ghes_sea_add(ghes);
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@@ -1218,9 -1084,7 +1228,10 @@@ static int ghes_remove(struct platform_
mutex_unlock(_list_mutex);
synchronize_rcu();
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  ghes_sea_remove(ghes);
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;


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

2017-06-15 Thread Stephen Rothwell
Hi all,

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

  drivers/acpi/apei/ghes.c

between commit:

  d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8")

from the arm64 tree and commit:

  7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")

from the tip 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/acpi/apei/ghes.c
index dfdb33f09f0a,d2c8a9286fa8..
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@@ -810,59 -718,10 +810,59 @@@ static int ghes_notify_hed(struct notif
return ret;
  }
  
- static struct notifier_block ghes_notifier_sci = {
-   .notifier_call = ghes_notify_sci,
+ static struct notifier_block ghes_notifier_hed = {
+   .notifier_call = ghes_notify_hed,
  };
  
 +#ifdef CONFIG_ACPI_APEI_SEA
 +static LIST_HEAD(ghes_sea);
 +
 +/*
 + * Return 0 only if one of the SEA error sources successfully reported an 
error
 + * record sent from the firmware.
 + */
 +int ghes_notify_sea(void)
 +{
 +  struct ghes *ghes;
 +  int ret = -ENOENT;
 +
 +  rcu_read_lock();
 +  list_for_each_entry_rcu(ghes, _sea, list) {
 +  if (!ghes_proc(ghes))
 +  ret = 0;
 +  }
 +  rcu_read_unlock();
 +  return ret;
 +}
 +
 +static void ghes_sea_add(struct ghes *ghes)
 +{
 +  mutex_lock(_list_mutex);
 +  list_add_rcu(>list, _sea);
 +  mutex_unlock(_list_mutex);
 +}
 +
 +static void ghes_sea_remove(struct ghes *ghes)
 +{
 +  mutex_lock(_list_mutex);
 +  list_del_rcu(>list);
 +  mutex_unlock(_list_mutex);
 +  synchronize_rcu();
 +}
 +#else /* CONFIG_ACPI_APEI_SEA */
 +static inline void ghes_sea_add(struct ghes *ghes)
 +{
 +  pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
supported\n",
 + ghes->generic->header.source_id);
 +}
 +
 +static inline void ghes_sea_remove(struct ghes *ghes)
 +{
 +  pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
supported\n",
 + ghes->generic->header.source_id);
 +}
 +#endif /* CONFIG_ACPI_APEI_SEA */
 +
  #ifdef CONFIG_HAVE_ACPI_APEI_NMI
  /*
   * printk is not safe in NMI context.  So in NMI handler, we allocate
@@@ -1096,15 -966,10 +1096,18 @@@ static int ghes_probe(struct platform_d
case ACPI_HEST_NOTIFY_POLLED:
case ACPI_HEST_NOTIFY_EXTERNAL:
case ACPI_HEST_NOTIFY_SCI:
+   case ACPI_HEST_NOTIFY_GSIV:
+   case ACPI_HEST_NOTIFY_GPIO:
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
 +  pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via SEA is not supported\n",
 +  generic->header.source_id);
 +  rc = -ENOTSUPP;
 +  goto err;
 +  }
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via NMI interrupt is not supported!\n",
@@@ -1162,16 -1027,17 +1165,20 @@@
goto err_edac_unreg;
}
break;
+ 
case ACPI_HEST_NOTIFY_SCI:
+   case ACPI_HEST_NOTIFY_GSIV:
+   case ACPI_HEST_NOTIFY_GPIO:
mutex_lock(_list_mutex);
-   if (list_empty(_sci))
-   register_acpi_hed_notifier(_notifier_sci);
-   list_add_rcu(>list, _sci);
+   if (list_empty(_hed))
+   register_acpi_hed_notifier(_notifier_hed);
+   list_add_rcu(>list, _hed);
mutex_unlock(_list_mutex);
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  ghes_sea_add(ghes);
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@@ -1218,9 -1084,7 +1228,10 @@@ static int ghes_remove(struct platform_
mutex_unlock(_list_mutex);
synchronize_rcu();
break;
 +  case ACPI_HEST_NOTIFY_SEA:
 +  ghes_sea_remove(ghes);
 +  break;
+ 
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;


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

2017-03-31 Thread Stephen Rothwell
Hi Arnd,

On Fri, 31 Mar 2017 11:32:54 +0200 Arnd Bergmann  wrote:
>
> Mark Brown's build bot now reports this build failure:
> 
> arm64-defconfig
> ../arch/arm64/include/asm/bug.h:62:29: error: implicit declaration of
> function '_BUG_FLAGS' [-Werror=implicit-function-declaration]
> 
> I think the last line needs s/_BUG_FLAGS/__BUG_FLAGS/
> aside from that, the merge looks right to me, but I wonder if
> there is a way to prevent the conflict from showing up later
> for Linus.

Yeah, I have fixed that for Monday.  I just presume that Linus will not
be half blind when he fixes it up. :-)

Or someone could remember to mention it to him. ;-)
-- 
Cheers,
Stephen Rothwell


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

2017-03-31 Thread Stephen Rothwell
Hi Arnd,

On Fri, 31 Mar 2017 11:32:54 +0200 Arnd Bergmann  wrote:
>
> Mark Brown's build bot now reports this build failure:
> 
> arm64-defconfig
> ../arch/arm64/include/asm/bug.h:62:29: error: implicit declaration of
> function '_BUG_FLAGS' [-Werror=implicit-function-declaration]
> 
> I think the last line needs s/_BUG_FLAGS/__BUG_FLAGS/
> aside from that, the merge looks right to me, but I wonder if
> there is a way to prevent the conflict from showing up later
> for Linus.

Yeah, I have fixed that for Monday.  I just presume that Linus will not
be half blind when he fixes it up. :-)

Or someone could remember to mention it to him. ;-)
-- 
Cheers,
Stephen Rothwell


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

2017-03-31 Thread Arnd Bergmann
On Fri, Mar 31, 2017 at 5:02 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
>   arch/arm64/include/asm/bug.h
>
> between commit:
>
>   f13d52cb3fad ("arm64: define BUG() instruction without CONFIG_BUG")
>
> from the arm64 tree and commit:
>
>   19d436268dde ("debug: Add _ONCE() logic to report_bug()")
>
> from the tip 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/arm64/include/asm/bug.h
> index 0bfe1df12b19,a9be1072933c..
> --- a/arch/arm64/include/asm/bug.h
> +++ b/arch/arm64/include/asm/bug.h
> @@@ -42,27 -45,19 +42,26 @@@
>   _BUGVERBOSE_LOCATION(__FILE__, __LINE__)  \
> ".short " #flags "\n\t" \
> ".popsection\n" \
>  -  \
>  -  "1: brk %[imm]" \
>  -  :: [imm] "i" (BUG_BRK_IMM)  \
>  -)
>  +  "1: "
>  +#else
>  +#define __BUG_ENTRY(flags) ""
>  +#endif
>  +
>  +#define __BUG_FLAGS(flags)\
>  +  asm volatile (  \
>  +  __BUG_ENTRY(flags)  \
>  +  "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
>  +  );
>
>  -#define BUG() do {\
>  -  _BUG_FLAGS(0);  \
>  -  unreachable();  \
>  +
>  +#define BUG() do {\
>  +  __BUG_FLAGS(0); \
>  +  unreachable();  \
>   } while (0)
>
> - #define __WARN_TAINT(taint)   \
> -   __BUG_FLAGS(BUGFLAG_TAINT(taint))
> + #define __WARN_FLAGS(flags) _BUG_FLAGS(BUGFLAG_WARNING|(flags))
>
>  -#endif /* ! CONFIG_GENERIC_BUG */
>  +#define HAVE_ARCH_BUG

Mark Brown's build bot now reports this build failure:

arm64-defconfig
../arch/arm64/include/asm/bug.h:62:29: error: implicit declaration of
function '_BUG_FLAGS' [-Werror=implicit-function-declaration]

I think the last line needs s/_BUG_FLAGS/__BUG_FLAGS/
aside from that, the merge looks right to me, but I wonder if
there is a way to prevent the conflict from showing up later
for Linus.

  Arnd


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

2017-03-31 Thread Arnd Bergmann
On Fri, Mar 31, 2017 at 5:02 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
>   arch/arm64/include/asm/bug.h
>
> between commit:
>
>   f13d52cb3fad ("arm64: define BUG() instruction without CONFIG_BUG")
>
> from the arm64 tree and commit:
>
>   19d436268dde ("debug: Add _ONCE() logic to report_bug()")
>
> from the tip 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/arm64/include/asm/bug.h
> index 0bfe1df12b19,a9be1072933c..
> --- a/arch/arm64/include/asm/bug.h
> +++ b/arch/arm64/include/asm/bug.h
> @@@ -42,27 -45,19 +42,26 @@@
>   _BUGVERBOSE_LOCATION(__FILE__, __LINE__)  \
> ".short " #flags "\n\t" \
> ".popsection\n" \
>  -  \
>  -  "1: brk %[imm]" \
>  -  :: [imm] "i" (BUG_BRK_IMM)  \
>  -)
>  +  "1: "
>  +#else
>  +#define __BUG_ENTRY(flags) ""
>  +#endif
>  +
>  +#define __BUG_FLAGS(flags)\
>  +  asm volatile (  \
>  +  __BUG_ENTRY(flags)  \
>  +  "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
>  +  );
>
>  -#define BUG() do {\
>  -  _BUG_FLAGS(0);  \
>  -  unreachable();  \
>  +
>  +#define BUG() do {\
>  +  __BUG_FLAGS(0); \
>  +  unreachable();  \
>   } while (0)
>
> - #define __WARN_TAINT(taint)   \
> -   __BUG_FLAGS(BUGFLAG_TAINT(taint))
> + #define __WARN_FLAGS(flags) _BUG_FLAGS(BUGFLAG_WARNING|(flags))
>
>  -#endif /* ! CONFIG_GENERIC_BUG */
>  +#define HAVE_ARCH_BUG

Mark Brown's build bot now reports this build failure:

arm64-defconfig
../arch/arm64/include/asm/bug.h:62:29: error: implicit declaration of
function '_BUG_FLAGS' [-Werror=implicit-function-declaration]

I think the last line needs s/_BUG_FLAGS/__BUG_FLAGS/
aside from that, the merge looks right to me, but I wonder if
there is a way to prevent the conflict from showing up later
for Linus.

  Arnd


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

2017-03-30 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/include/asm/bug.h

between commit:

  f13d52cb3fad ("arm64: define BUG() instruction without CONFIG_BUG")

from the arm64 tree and commit:

  19d436268dde ("debug: Add _ONCE() logic to report_bug()")

from the tip 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/arm64/include/asm/bug.h
index 0bfe1df12b19,a9be1072933c..
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@@ -42,27 -45,19 +42,26 @@@
  _BUGVERBOSE_LOCATION(__FILE__, __LINE__)  \
".short " #flags "\n\t" \
".popsection\n" \
 -  \
 -  "1: brk %[imm]" \
 -  :: [imm] "i" (BUG_BRK_IMM)  \
 -)
 +  "1: "
 +#else
 +#define __BUG_ENTRY(flags) ""
 +#endif
 +
 +#define __BUG_FLAGS(flags)\
 +  asm volatile (  \
 +  __BUG_ENTRY(flags)  \
 +  "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
 +  );
  
 -#define BUG() do {\
 -  _BUG_FLAGS(0);  \
 -  unreachable();  \
 +
 +#define BUG() do {\
 +  __BUG_FLAGS(0); \
 +  unreachable();  \
  } while (0)
  
- #define __WARN_TAINT(taint)   \
-   __BUG_FLAGS(BUGFLAG_TAINT(taint))
+ #define __WARN_FLAGS(flags) _BUG_FLAGS(BUGFLAG_WARNING|(flags))
  
 -#endif /* ! CONFIG_GENERIC_BUG */
 +#define HAVE_ARCH_BUG
  
  #include 
  


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

2017-03-30 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/include/asm/bug.h

between commit:

  f13d52cb3fad ("arm64: define BUG() instruction without CONFIG_BUG")

from the arm64 tree and commit:

  19d436268dde ("debug: Add _ONCE() logic to report_bug()")

from the tip 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/arm64/include/asm/bug.h
index 0bfe1df12b19,a9be1072933c..
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@@ -42,27 -45,19 +42,26 @@@
  _BUGVERBOSE_LOCATION(__FILE__, __LINE__)  \
".short " #flags "\n\t" \
".popsection\n" \
 -  \
 -  "1: brk %[imm]" \
 -  :: [imm] "i" (BUG_BRK_IMM)  \
 -)
 +  "1: "
 +#else
 +#define __BUG_ENTRY(flags) ""
 +#endif
 +
 +#define __BUG_FLAGS(flags)\
 +  asm volatile (  \
 +  __BUG_ENTRY(flags)  \
 +  "brk %[imm]" :: [imm] "i" (BUG_BRK_IMM) \
 +  );
  
 -#define BUG() do {\
 -  _BUG_FLAGS(0);  \
 -  unreachable();  \
 +
 +#define BUG() do {\
 +  __BUG_FLAGS(0); \
 +  unreachable();  \
  } while (0)
  
- #define __WARN_TAINT(taint)   \
-   __BUG_FLAGS(BUGFLAG_TAINT(taint))
+ #define __WARN_FLAGS(flags) _BUG_FLAGS(BUGFLAG_WARNING|(flags))
  
 -#endif /* ! CONFIG_GENERIC_BUG */
 +#define HAVE_ARCH_BUG
  
  #include 
  


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

2016-09-11 Thread Stephen Rothwell
Hi all,

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

  include/linux/jump_label.h

between commit:

  ef0da55a84a3 ("jump_labels: Allow array initialisers")

from the arm64 tree and commit:

  b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE 
macros")

from the tip 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 include/linux/jump_label.h
index a534c7f15a61,595fb46213fc..
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@@ -272,16 -273,9 +275,19 @@@ struct static_key_false 
  #define DEFINE_STATIC_KEY_FALSE(name) \
struct static_key_false name = STATIC_KEY_FALSE_INIT
  
+ #define DECLARE_STATIC_KEY_FALSE(name)\
+   extern struct static_key_false name
+ 
 +#define DEFINE_STATIC_KEY_ARRAY_TRUE(name, count) \
 +  struct static_key_true name[count] = {  \
 +  [0 ... (count) - 1] = STATIC_KEY_TRUE_INIT, \
 +  }
 +
 +#define DEFINE_STATIC_KEY_ARRAY_FALSE(name, count)\
 +  struct static_key_false name[count] = { \
 +  [0 ... (count) - 1] = STATIC_KEY_FALSE_INIT,\
 +  }
 +
  extern bool wrong_branch_error(void);
  
  #define static_key_enabled(x) 
\


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

2016-09-11 Thread Stephen Rothwell
Hi all,

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

  include/linux/jump_label.h

between commit:

  ef0da55a84a3 ("jump_labels: Allow array initialisers")

from the arm64 tree and commit:

  b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE 
macros")

from the tip 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 include/linux/jump_label.h
index a534c7f15a61,595fb46213fc..
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@@ -272,16 -273,9 +275,19 @@@ struct static_key_false 
  #define DEFINE_STATIC_KEY_FALSE(name) \
struct static_key_false name = STATIC_KEY_FALSE_INIT
  
+ #define DECLARE_STATIC_KEY_FALSE(name)\
+   extern struct static_key_false name
+ 
 +#define DEFINE_STATIC_KEY_ARRAY_TRUE(name, count) \
 +  struct static_key_true name[count] = {  \
 +  [0 ... (count) - 1] = STATIC_KEY_TRUE_INIT, \
 +  }
 +
 +#define DEFINE_STATIC_KEY_ARRAY_FALSE(name, count)\
 +  struct static_key_false name[count] = { \
 +  [0 ... (count) - 1] = STATIC_KEY_FALSE_INIT,\
 +  }
 +
  extern bool wrong_branch_error(void);
  
  #define static_key_enabled(x) 
\


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

2016-05-11 Thread Stephen Rothwell
Hi all,

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

  drivers/irqchip/irq-gic.c

between commit:

  25fc11aead38 ("irqchip/gic: Restore CPU interface checking")

from the arm64 tree and commit:

  dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")
  f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters")

from the tip 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/irqchip/irq-gic.c
index 095bb5b5c3f2,113e2d02c812..
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@@ -489,8 -486,9 +486,10 @@@ static int gic_cpu_init(struct gic_chip
/*
 * Get what the GIC says our CPU mask is.
 */
-   BUG_ON(cpu >= NR_GIC_CPU_IF);
+   if (WARN_ON(cpu >= NR_GIC_CPU_IF))
+   return -EINVAL;
+ 
 +  gic_check_cpu_features();
cpu_mask = gic_get_cpumask(gic);
gic_cpu_map[cpu] = cpu_mask;
  
@@@ -1012,24 -1029,28 +1030,26 @@@ static const struct irq_domain_ops gic_
.unmap = gic_irq_domain_unmap,
  };
  
- static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
-  void __iomem *dist_base, void __iomem *cpu_base,
-  u32 percpu_offset, struct fwnode_handle *handle)
+ static int __init __gic_init_bases(struct gic_chip_data *gic, int irq_start,
+  struct fwnode_handle *handle)
  {
irq_hw_number_t hwirq_base;
-   struct gic_chip_data *gic;
-   int gic_irqs, irq_base, i;
- 
-   BUG_ON(gic_nr >= CONFIG_ARM_GIC_MAX_NR);
+   int gic_irqs, irq_base, i, ret;
  
-   gic = _data[gic_nr];
+   if (WARN_ON(!gic || gic->domain))
+   return -EINVAL;
  
 -  gic_check_cpu_features();
 -
/* Initialize irq_chip */
-   if (static_key_true(_deactivate) && gic_nr == 0) {
-   gic->chip = gic_eoimode1_chip;
+   gic->chip = gic_chip;
+ 
+   if (static_key_true(_deactivate) && gic == _data[0]) {
+   gic->chip.irq_mask = gic_eoimode1_mask_irq;
+   gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
+   gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity;
+   gic->chip.name = kasprintf(GFP_KERNEL, "GICv2");
} else {
-   gic->chip = gic_chip;
-   gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d", gic_nr);
+   gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d",
+  (int)(gic - _data[0]));
}
  
  #ifdef CONFIG_SMP


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

2016-05-11 Thread Stephen Rothwell
Hi all,

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

  drivers/irqchip/irq-gic.c

between commit:

  25fc11aead38 ("irqchip/gic: Restore CPU interface checking")

from the arm64 tree and commit:

  dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")
  f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters")

from the tip 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/irqchip/irq-gic.c
index 095bb5b5c3f2,113e2d02c812..
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@@ -489,8 -486,9 +486,10 @@@ static int gic_cpu_init(struct gic_chip
/*
 * Get what the GIC says our CPU mask is.
 */
-   BUG_ON(cpu >= NR_GIC_CPU_IF);
+   if (WARN_ON(cpu >= NR_GIC_CPU_IF))
+   return -EINVAL;
+ 
 +  gic_check_cpu_features();
cpu_mask = gic_get_cpumask(gic);
gic_cpu_map[cpu] = cpu_mask;
  
@@@ -1012,24 -1029,28 +1030,26 @@@ static const struct irq_domain_ops gic_
.unmap = gic_irq_domain_unmap,
  };
  
- static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
-  void __iomem *dist_base, void __iomem *cpu_base,
-  u32 percpu_offset, struct fwnode_handle *handle)
+ static int __init __gic_init_bases(struct gic_chip_data *gic, int irq_start,
+  struct fwnode_handle *handle)
  {
irq_hw_number_t hwirq_base;
-   struct gic_chip_data *gic;
-   int gic_irqs, irq_base, i;
- 
-   BUG_ON(gic_nr >= CONFIG_ARM_GIC_MAX_NR);
+   int gic_irqs, irq_base, i, ret;
  
-   gic = _data[gic_nr];
+   if (WARN_ON(!gic || gic->domain))
+   return -EINVAL;
  
 -  gic_check_cpu_features();
 -
/* Initialize irq_chip */
-   if (static_key_true(_deactivate) && gic_nr == 0) {
-   gic->chip = gic_eoimode1_chip;
+   gic->chip = gic_chip;
+ 
+   if (static_key_true(_deactivate) && gic == _data[0]) {
+   gic->chip.irq_mask = gic_eoimode1_mask_irq;
+   gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
+   gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity;
+   gic->chip.name = kasprintf(GFP_KERNEL, "GICv2");
} else {
-   gic->chip = gic_chip;
-   gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d", gic_nr);
+   gic->chip.name = kasprintf(GFP_KERNEL, "GIC-%d",
+  (int)(gic - _data[0]));
}
  
  #ifdef CONFIG_SMP


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

2016-04-29 Thread Matt Fleming
On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/firmware/efi/arm-init.c
> 
> between commits:
> 
>   500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing 
> them")
>   7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")
> 
> from the arm64 tree and commits:
> 
>   78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
>   884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")
> 
> from the tip tree.
 
[...]

> diff --cc drivers/firmware/efi/arm-init.c
> index fac567c3b66a,ef90f0c4b70a..
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
>   if (efi_enabled(EFI_DBG))
>   pr_info("Processing EFI memory map:\n");
>   
>  +/*
>  + * Discard memblocks discovered so far: if there are any at this
>  + * point, they originate from memory nodes in the DT, and UEFI
>  + * uses its own memory map instead.
>  + */
>  +memblock_dump_all();
>  +memblock_remove(0, (phys_addr_t)ULLONG_MAX);
>  +
> - for_each_efi_memory_desc(, md) {
> + for_each_efi_memory_desc(md) {
>   paddr = md->phys_addr;
>   npages = md->num_pages;
>   

This looks fine, thanks Stephen.


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

2016-04-29 Thread Matt Fleming
On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/firmware/efi/arm-init.c
> 
> between commits:
> 
>   500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing 
> them")
>   7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")
> 
> from the arm64 tree and commits:
> 
>   78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
>   884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")
> 
> from the tip tree.
 
[...]

> diff --cc drivers/firmware/efi/arm-init.c
> index fac567c3b66a,ef90f0c4b70a..
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
>   if (efi_enabled(EFI_DBG))
>   pr_info("Processing EFI memory map:\n");
>   
>  +/*
>  + * Discard memblocks discovered so far: if there are any at this
>  + * point, they originate from memory nodes in the DT, and UEFI
>  + * uses its own memory map instead.
>  + */
>  +memblock_dump_all();
>  +memblock_remove(0, (phys_addr_t)ULLONG_MAX);
>  +
> - for_each_efi_memory_desc(, md) {
> + for_each_efi_memory_desc(md) {
>   paddr = md->phys_addr;
>   npages = md->num_pages;
>   

This looks fine, thanks Stephen.


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

2016-04-28 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/arm-init.c

between commits:

  500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing 
them")
  7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")

from the arm64 tree and commits:

  78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
  884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")

from the tip 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/firmware/efi/arm-init.c
index fac567c3b66a,ef90f0c4b70a..
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
if (efi_enabled(EFI_DBG))
pr_info("Processing EFI memory map:\n");
  
 +  /*
 +   * Discard memblocks discovered so far: if there are any at this
 +   * point, they originate from memory nodes in the DT, and UEFI
 +   * uses its own memory map instead.
 +   */
 +  memblock_dump_all();
 +  memblock_remove(0, (phys_addr_t)ULLONG_MAX);
 +
-   for_each_efi_memory_desc(, md) {
+   for_each_efi_memory_desc(md) {
paddr = md->phys_addr;
npages = md->num_pages;
  


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

2016-04-28 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/arm-init.c

between commits:

  500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing 
them")
  7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")

from the arm64 tree and commits:

  78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
  884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")

from the tip 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/firmware/efi/arm-init.c
index fac567c3b66a,ef90f0c4b70a..
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
if (efi_enabled(EFI_DBG))
pr_info("Processing EFI memory map:\n");
  
 +  /*
 +   * Discard memblocks discovered so far: if there are any at this
 +   * point, they originate from memory nodes in the DT, and UEFI
 +   * uses its own memory map instead.
 +   */
 +  memblock_dump_all();
 +  memblock_remove(0, (phys_addr_t)ULLONG_MAX);
 +
-   for_each_efi_memory_desc(, md) {
+   for_each_efi_memory_desc(md) {
paddr = md->phys_addr;
npages = md->num_pages;
  


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

2016-02-25 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/efistub.h

between commits:

  e4fbf4767440 ("efi: stub: implement efi_get_random_bytes() based on 
EFI_RNG_PROTOCOL")
  2ddbfc81eac8 ("efi: stub: add implementation of efi_random_alloc()")

from the arm64 tree and commit:

  b9d6769b5678 ("efi/arm*: Perform hardware compatibility check")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/efistub.h
index 5ed3d3f38166,981c6035ce09..
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@@ -43,11 -53,6 +53,13 @@@ void efi_get_virtmap(efi_memory_desc_t 
 unsigned long desc_size, efi_memory_desc_t *runtime_map,
 int *count);
  
 +efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
 +unsigned long size, u8 *out);
 +
 +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
 +unsigned long size, unsigned long align,
 +unsigned long *addr, unsigned long random_seed);
 +
+ efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+ 
  #endif


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

2016-02-25 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  2b5fe07a78a0 ("arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR 
randomness")

from the arm64 tree and commit:

  42b55734030c ("efi/arm64: Check for h/w support before booting a >4 KB 
granular kernel")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/arm64-stub.c
index e0e6b74fef8f,047fc343665a..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -12,18 -12,34 +12,38 @@@
  #include 
  #include 
  #include 
+ #include 
  
 +#include "efistub.h"
 +
 +extern bool __nokaslr;
 +
- efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
-   unsigned long *image_addr,
-   unsigned long *image_size,
-   unsigned long *reserve_addr,
-   unsigned long *reserve_size,
-   unsigned long dram_base,
-   efi_loaded_image_t *image)
+ efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+ {
+   u64 tg;
+ 
+   /* UEFI mandates support for 4 KB granularity, no need to check */
+   if (IS_ENABLED(CONFIG_ARM64_4K_PAGES))
+   return EFI_SUCCESS;
+ 
+   tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf;
+   if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+   if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
+   pr_efi_err(sys_table_arg, "This 64 KB granular kernel 
is not supported by your CPU\n");
+   else
+   pr_efi_err(sys_table_arg, "This 16 KB granular kernel 
is not supported by your CPU\n");
+   return EFI_UNSUPPORTED;
+   }
+   return EFI_SUCCESS;
+ }
+ 
+ efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
+unsigned long *image_addr,
+unsigned long *image_size,
+unsigned long *reserve_addr,
+unsigned long *reserve_size,
+unsigned long dram_base,
+efi_loaded_image_t *image)
  {
efi_status_t status;
unsigned long kernel_size, kernel_memsize = 0;


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

2016-02-25 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/efistub.h

between commits:

  e4fbf4767440 ("efi: stub: implement efi_get_random_bytes() based on 
EFI_RNG_PROTOCOL")
  2ddbfc81eac8 ("efi: stub: add implementation of efi_random_alloc()")

from the arm64 tree and commit:

  b9d6769b5678 ("efi/arm*: Perform hardware compatibility check")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/efistub.h
index 5ed3d3f38166,981c6035ce09..
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@@ -43,11 -53,6 +53,13 @@@ void efi_get_virtmap(efi_memory_desc_t 
 unsigned long desc_size, efi_memory_desc_t *runtime_map,
 int *count);
  
 +efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
 +unsigned long size, u8 *out);
 +
 +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
 +unsigned long size, unsigned long align,
 +unsigned long *addr, unsigned long random_seed);
 +
+ efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+ 
  #endif


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

2016-02-25 Thread Stephen Rothwell
Hi all,

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

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  2b5fe07a78a0 ("arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR 
randomness")

from the arm64 tree and commit:

  42b55734030c ("efi/arm64: Check for h/w support before booting a >4 KB 
granular kernel")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/arm64-stub.c
index e0e6b74fef8f,047fc343665a..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -12,18 -12,34 +12,38 @@@
  #include 
  #include 
  #include 
+ #include 
  
 +#include "efistub.h"
 +
 +extern bool __nokaslr;
 +
- efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
-   unsigned long *image_addr,
-   unsigned long *image_size,
-   unsigned long *reserve_addr,
-   unsigned long *reserve_size,
-   unsigned long dram_base,
-   efi_loaded_image_t *image)
+ efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+ {
+   u64 tg;
+ 
+   /* UEFI mandates support for 4 KB granularity, no need to check */
+   if (IS_ENABLED(CONFIG_ARM64_4K_PAGES))
+   return EFI_SUCCESS;
+ 
+   tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf;
+   if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+   if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
+   pr_efi_err(sys_table_arg, "This 64 KB granular kernel 
is not supported by your CPU\n");
+   else
+   pr_efi_err(sys_table_arg, "This 16 KB granular kernel 
is not supported by your CPU\n");
+   return EFI_UNSUPPORTED;
+   }
+   return EFI_SUCCESS;
+ }
+ 
+ efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
+unsigned long *image_addr,
+unsigned long *image_size,
+unsigned long *reserve_addr,
+unsigned long *reserve_size,
+unsigned long dram_base,
+efi_loaded_image_t *image)
  {
efi_status_t status;
unsigned long kernel_size, kernel_memsize = 0;


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

2015-10-31 Thread Stephen Rothwell
Hi Catalin,

On Thu, 22 Oct 2015 16:32:01 +0100 Catalin Marinas  
wrote:
>
> On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> > On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:  
> > > Today's linux-next merge of the tip tree got a conflict in:
> > > 
> > >   arch/arm64/kernel/cpufeature.c
> > > 
> > > between commit:
> > > 
> > >   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> > > 
> > > from the arm64 tree and commit:
> > > 
> > >   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before 
> > > enabling ARM64_HAS_SYSREG_GIC_CPUIF")
> > > 
> > > from the tip tree.
> > > 
> > > I fixed it up (I have no idea here, so I just used the arm64 tree version)
> > > and can carry the fix as necessary (no action is required).  
> > 
> > We need the following patch applied to fix the conflict correctly
> > on top of the -next tree.  
> 
> Or, if it's easier, the combined diff resolution for the conflicting
> code:
> 
> 8<
> diff --cc arch/arm64/kernel/cpufeature.c
> index d0d607452e1d,305f30dc9e63..ec552cf9e12d
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> 
> [...]
> 
>   
> + static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
> *entry)
> + {
> + bool has_sre;
> + 
>  -if (!has_id_aa64pfr0_feature(entry))
> ++if (!has_cpuid_feature(entry))
> + return false;
> + 
> + has_sre = gic_enable_sre();
> + if (!has_sre)
> + pr_warn_once("%s present but disabled by higher exception 
> level\n",
> +  entry->desc);
> + 
> + return has_sre;
> + }
> + 
>   static const struct arm64_cpu_capabilities arm64_features[] = {
>   {
>   .desc = "GIC system register CPU interface",
>   .capability = ARM64_HAS_SYSREG_GIC_CPUIF,
> - .matches = has_cpuid_feature,
> + .matches = has_useable_gicv3_cpuif,
>  -.field_pos = 24,
>  +.sys_reg = SYS_ID_AA64PFR0_EL1,
>  +.field_pos = ID_AA64PFR0_GIC_SHIFT,
>   .min_field_value = 1,
>   },
>   #ifdef CONFIG_ARM64_PAN

OK, I have updated my merge resolution.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-31 Thread Stephen Rothwell
Hi Catalin,

On Thu, 22 Oct 2015 16:32:01 +0100 Catalin Marinas  
wrote:
>
> On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> > On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:  
> > > Today's linux-next merge of the tip tree got a conflict in:
> > > 
> > >   arch/arm64/kernel/cpufeature.c
> > > 
> > > between commit:
> > > 
> > >   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> > > 
> > > from the arm64 tree and commit:
> > > 
> > >   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before 
> > > enabling ARM64_HAS_SYSREG_GIC_CPUIF")
> > > 
> > > from the tip tree.
> > > 
> > > I fixed it up (I have no idea here, so I just used the arm64 tree version)
> > > and can carry the fix as necessary (no action is required).  
> > 
> > We need the following patch applied to fix the conflict correctly
> > on top of the -next tree.  
> 
> Or, if it's easier, the combined diff resolution for the conflicting
> code:
> 
> 8<
> diff --cc arch/arm64/kernel/cpufeature.c
> index d0d607452e1d,305f30dc9e63..ec552cf9e12d
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> 
> [...]
> 
>   
> + static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
> *entry)
> + {
> + bool has_sre;
> + 
>  -if (!has_id_aa64pfr0_feature(entry))
> ++if (!has_cpuid_feature(entry))
> + return false;
> + 
> + has_sre = gic_enable_sre();
> + if (!has_sre)
> + pr_warn_once("%s present but disabled by higher exception 
> level\n",
> +  entry->desc);
> + 
> + return has_sre;
> + }
> + 
>   static const struct arm64_cpu_capabilities arm64_features[] = {
>   {
>   .desc = "GIC system register CPU interface",
>   .capability = ARM64_HAS_SYSREG_GIC_CPUIF,
> - .matches = has_cpuid_feature,
> + .matches = has_useable_gicv3_cpuif,
>  -.field_pos = 24,
>  +.sys_reg = SYS_ID_AA64PFR0_EL1,
>  +.field_pos = ID_AA64PFR0_GIC_SHIFT,
>   .min_field_value = 1,
>   },
>   #ifdef CONFIG_ARM64_PAN

OK, I have updated my merge resolution.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-22 Thread Catalin Marinas
On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   arch/arm64/kernel/cpufeature.c
> > 
> > between commit:
> > 
> >   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> > 
> > from the arm64 tree and commit:
> > 
> >   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
> > ARM64_HAS_SYSREG_GIC_CPUIF")
> > 
> > from the tip tree.
> > 
> > I fixed it up (I have no idea here, so I just used the arm64 tree version)
> > and can carry the fix as necessary (no action is required).
> 
> We need the following patch applied to fix the conflict correctly
> on top of the -next tree.

Or, if it's easier, the combined diff resolution for the conflicting
code:

8<
diff --cc arch/arm64/kernel/cpufeature.c
index d0d607452e1d,305f30dc9e63..ec552cf9e12d
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

[...]

  
+ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
*entry)
+ {
+   bool has_sre;
+ 
 -  if (!has_id_aa64pfr0_feature(entry))
++  if (!has_cpuid_feature(entry))
+   return false;
+ 
+   has_sre = gic_enable_sre();
+   if (!has_sre)
+   pr_warn_once("%s present but disabled by higher exception 
level\n",
+entry->desc);
+ 
+   return has_sre;
+ }
+ 
  static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
-   .matches = has_cpuid_feature,
+   .matches = has_useable_gicv3_cpuif,
 -  .field_pos = 24,
 +  .sys_reg = SYS_ID_AA64PFR0_EL1,
 +  .field_pos = ID_AA64PFR0_GIC_SHIFT,
.min_field_value = 1,
},
  #ifdef CONFIG_ARM64_PAN
8<

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-22 Thread Suzuki K. Poulose
On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commit:
> 
>   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> 
> from the arm64 tree and commit:
> 
>   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
> ARM64_HAS_SYSREG_GIC_CPUIF")
> 
> from the tip tree.
> 
> I fixed it up (I have no idea here, so I just used the arm64 tree version)
> and can carry the fix as necessary (no action is required).

Stephen,

We need the following patch applied to fix the conflict correctly
on top of the -next tree.

>8
linux-next: arm64/cpufeatures: Resolve merg conflict

This patch fixes the merge conflict in linux-next with arm64 tree
and the tip.

  arch/arm64/kernel/cpufeature.c
between commit:
  da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
from the arm64 tree and commit:
  963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling
ARM64_HAS_SYSREG_GIC_CPUIF")
from the tip tree.

Signed-off-by: Suzuki K. Poulose 

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d413959..a1aea90 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -597,11 +597,25 @@ has_cpuid_feature(const struct arm64_cpu_capabilities 
*entry)
return feature_matches(val, entry);
 }
 
+static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
+{
+   bool has_sre;
+
+   if (!has_cpuid_feature(entry))
+   return false;
+   has_sre = gic_enable_sre();
+   if (!has_sre)
+   pr_warn_once("%s present but disabled by higher exception 
level\n",
+   entry->desc);
+
+   return has_sre;
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
-   .matches = has_cpuid_feature,
+   .matches = has_useable_gicv3_cpuif,
.sys_reg = SYS_ID_AA64PFR0_EL1,
.field_pos = ID_AA64PFR0_GIC_SHIFT,
.min_field_value = 1,

8<-

Thanks
Suzuki


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-22 Thread Suzuki K. Poulose
On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commit:
> 
>   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> 
> from the arm64 tree and commit:
> 
>   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
> ARM64_HAS_SYSREG_GIC_CPUIF")
> 
> from the tip tree.
> 
> I fixed it up (I have no idea here, so I just used the arm64 tree version)
> and can carry the fix as necessary (no action is required).

Stephen,

We need the following patch applied to fix the conflict correctly
on top of the -next tree.

>8
linux-next: arm64/cpufeatures: Resolve merg conflict

This patch fixes the merge conflict in linux-next with arm64 tree
and the tip.

  arch/arm64/kernel/cpufeature.c
between commit:
  da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
from the arm64 tree and commit:
  963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling
ARM64_HAS_SYSREG_GIC_CPUIF")
from the tip tree.

Signed-off-by: Suzuki K. Poulose 

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d413959..a1aea90 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -597,11 +597,25 @@ has_cpuid_feature(const struct arm64_cpu_capabilities 
*entry)
return feature_matches(val, entry);
 }
 
+static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
+{
+   bool has_sre;
+
+   if (!has_cpuid_feature(entry))
+   return false;
+   has_sre = gic_enable_sre();
+   if (!has_sre)
+   pr_warn_once("%s present but disabled by higher exception 
level\n",
+   entry->desc);
+
+   return has_sre;
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
-   .matches = has_cpuid_feature,
+   .matches = has_useable_gicv3_cpuif,
.sys_reg = SYS_ID_AA64PFR0_EL1,
.field_pos = ID_AA64PFR0_GIC_SHIFT,
.min_field_value = 1,

8<-

Thanks
Suzuki


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-22 Thread Catalin Marinas
On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   arch/arm64/kernel/cpufeature.c
> > 
> > between commit:
> > 
> >   da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")
> > 
> > from the arm64 tree and commit:
> > 
> >   963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
> > ARM64_HAS_SYSREG_GIC_CPUIF")
> > 
> > from the tip tree.
> > 
> > I fixed it up (I have no idea here, so I just used the arm64 tree version)
> > and can carry the fix as necessary (no action is required).
> 
> We need the following patch applied to fix the conflict correctly
> on top of the -next tree.

Or, if it's easier, the combined diff resolution for the conflicting
code:

8<
diff --cc arch/arm64/kernel/cpufeature.c
index d0d607452e1d,305f30dc9e63..ec552cf9e12d
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

[...]

  
+ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
*entry)
+ {
+   bool has_sre;
+ 
 -  if (!has_id_aa64pfr0_feature(entry))
++  if (!has_cpuid_feature(entry))
+   return false;
+ 
+   has_sre = gic_enable_sre();
+   if (!has_sre)
+   pr_warn_once("%s present but disabled by higher exception 
level\n",
+entry->desc);
+ 
+   return has_sre;
+ }
+ 
  static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
-   .matches = has_cpuid_feature,
+   .matches = has_useable_gicv3_cpuif,
 -  .field_pos = 24,
 +  .sys_reg = SYS_ID_AA64PFR0_EL1,
 +  .field_pos = ID_AA64PFR0_GIC_SHIFT,
.min_field_value = 1,
},
  #ifdef CONFIG_ARM64_PAN
8<

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-21 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/kernel/cpufeature.c

between commit:

  da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")

from the arm64 tree and commit:

  963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
ARM64_HAS_SYSREG_GIC_CPUIF")

from the tip tree.

I fixed it up (I have no idea here, so I just used the arm64 tree version)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-21 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/kernel/cpufeature.c

between commit:

  da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")

from the arm64 tree and commit:

  963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
ARM64_HAS_SYSREG_GIC_CPUIF")

from the tip tree.

I fixed it up (I have no idea here, so I just used the arm64 tree version)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-14 Thread Stephen Rothwell
Hi all,

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

  Documentation/arm/uefi.txt

between commit:

  d4dddfdbbc75 ("arm64/efi: remove /chosen/linux, uefi-stub-kern-ver DT 
property")

from the arm64 tree and commit:

  c9494dc81875 ("arm64: Use core efi=debug instead of uefi_debug command line 
parameter")

from the tip 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 Documentation/arm/uefi.txt
index 7f1bed8872f3,7b3fdfe0f7ba..
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@@ -58,5 -58,5 +58,3 @@@ linux,uefi-mmap-desc-size | 32-bit | Si
  

  linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
  

- 
- For verbose debug messages, specify 'uefi_debug' on the kernel command line.
 -linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
 
-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-14 Thread Stephen Rothwell
Hi all,

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

  Documentation/arm/uefi.txt

between commit:

  d4dddfdbbc75 ("arm64/efi: remove /chosen/linux, uefi-stub-kern-ver DT 
property")

from the arm64 tree and commit:

  c9494dc81875 ("arm64: Use core efi=debug instead of uefi_debug command line 
parameter")

from the tip 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 Documentation/arm/uefi.txt
index 7f1bed8872f3,7b3fdfe0f7ba..
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@@ -58,5 -58,5 +58,3 @@@ linux,uefi-mmap-desc-size | 32-bit | Si
  

  linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
  

- 
- For verbose debug messages, specify 'uefi_debug' on the kernel command line.
 -linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
 
-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-13 Thread Will Deacon
On Tue, Oct 13, 2015 at 01:10:48PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/include/asm/atomic.h
> 
> between commit:
> 
>   305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} 
> atomics")
> 
> from the arm64 tree and commit:
> 
>   62e8a3258bda ("atomic, arch: Audit atomic_{read,set}()")
> 
> from the tip 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/arm64/include/asm/atomic.h
> index 5e13ad76a249,1e247ac2601a..
> --- a/arch/arm64/include/asm/atomic.h
> +++ b/arch/arm64/include/asm/atomic.h
> @@@ -54,39 -54,8 +54,39 @@@
>   #define ATOMIC_INIT(i)  { (i) }
>   
>   #define atomic_read(v)  READ_ONCE((v)->counter)
> - #define atomic_set(v, i)(((v)->counter) = (i))
> + #define atomic_set(v, i)WRITE_ONCE(((v)->counter), (i))

This is the correct fixup, and matches what I'm carrying locally.

Thanks, Stephen.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-13 Thread Will Deacon
On Tue, Oct 13, 2015 at 01:10:48PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/include/asm/atomic.h
> 
> between commit:
> 
>   305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} 
> atomics")
> 
> from the arm64 tree and commit:
> 
>   62e8a3258bda ("atomic, arch: Audit atomic_{read,set}()")
> 
> from the tip 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/arm64/include/asm/atomic.h
> index 5e13ad76a249,1e247ac2601a..
> --- a/arch/arm64/include/asm/atomic.h
> +++ b/arch/arm64/include/asm/atomic.h
> @@@ -54,39 -54,8 +54,39 @@@
>   #define ATOMIC_INIT(i)  { (i) }
>   
>   #define atomic_read(v)  READ_ONCE((v)->counter)
> - #define atomic_set(v, i)(((v)->counter) = (i))
> + #define atomic_set(v, i)WRITE_ONCE(((v)->counter), (i))

This is the correct fixup, and matches what I'm carrying locally.

Thanks, Stephen.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-12 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/include/asm/atomic.h

between commit:

  305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} 
atomics")

from the arm64 tree and commit:

  62e8a3258bda ("atomic, arch: Audit atomic_{read,set}()")

from the tip 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/arm64/include/asm/atomic.h
index 5e13ad76a249,1e247ac2601a..
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@@ -54,39 -54,8 +54,39 @@@
  #define ATOMIC_INIT(i){ (i) }
  
  #define atomic_read(v)READ_ONCE((v)->counter)
- #define atomic_set(v, i)  (((v)->counter) = (i))
+ #define atomic_set(v, i)  WRITE_ONCE(((v)->counter), (i))
 +
 +#define atomic_add_return_relaxed atomic_add_return_relaxed
 +#define atomic_add_return_acquire atomic_add_return_acquire
 +#define atomic_add_return_release atomic_add_return_release
 +#define atomic_add_return atomic_add_return
 +
 +#define atomic_inc_return_relaxed(v)  atomic_add_return_relaxed(1, (v))
 +#define atomic_inc_return_acquire(v)  atomic_add_return_acquire(1, (v))
 +#define atomic_inc_return_release(v)  atomic_add_return_release(1, (v))
 +#define atomic_inc_return(v)  atomic_add_return(1, (v))
 +
 +#define atomic_sub_return_relaxed atomic_sub_return_relaxed
 +#define atomic_sub_return_acquire atomic_sub_return_acquire
 +#define atomic_sub_return_release atomic_sub_return_release
 +#define atomic_sub_return atomic_sub_return
 +
 +#define atomic_dec_return_relaxed(v)  atomic_sub_return_relaxed(1, (v))
 +#define atomic_dec_return_acquire(v)  atomic_sub_return_acquire(1, (v))
 +#define atomic_dec_return_release(v)  atomic_sub_return_release(1, (v))
 +#define atomic_dec_return(v)  atomic_sub_return(1, (v))
 +
 +#define atomic_xchg_relaxed(v, new)   xchg_relaxed(&((v)->counter), (new))
 +#define atomic_xchg_acquire(v, new)   xchg_acquire(&((v)->counter), (new))
 +#define atomic_xchg_release(v, new)   xchg_release(&((v)->counter), (new))
  #define atomic_xchg(v, new)   xchg(&((v)->counter), (new))
 +
 +#define atomic_cmpxchg_relaxed(v, old, new)   \
 +  cmpxchg_relaxed(&((v)->counter), (old), (new))
 +#define atomic_cmpxchg_acquire(v, old, new)   \
 +  cmpxchg_acquire(&((v)->counter), (old), (new))
 +#define atomic_cmpxchg_release(v, old, new)   \
 +  cmpxchg_release(&((v)->counter), (old), (new))
  #define atomic_cmpxchg(v, old, new)   cmpxchg(&((v)->counter), (old), (new))
  
  #define atomic_inc(v) atomic_add(1, (v))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-10-12 Thread Stephen Rothwell
Hi all,

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

  arch/arm64/include/asm/atomic.h

between commit:

  305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} 
atomics")

from the arm64 tree and commit:

  62e8a3258bda ("atomic, arch: Audit atomic_{read,set}()")

from the tip 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/arm64/include/asm/atomic.h
index 5e13ad76a249,1e247ac2601a..
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@@ -54,39 -54,8 +54,39 @@@
  #define ATOMIC_INIT(i){ (i) }
  
  #define atomic_read(v)READ_ONCE((v)->counter)
- #define atomic_set(v, i)  (((v)->counter) = (i))
+ #define atomic_set(v, i)  WRITE_ONCE(((v)->counter), (i))
 +
 +#define atomic_add_return_relaxed atomic_add_return_relaxed
 +#define atomic_add_return_acquire atomic_add_return_acquire
 +#define atomic_add_return_release atomic_add_return_release
 +#define atomic_add_return atomic_add_return
 +
 +#define atomic_inc_return_relaxed(v)  atomic_add_return_relaxed(1, (v))
 +#define atomic_inc_return_acquire(v)  atomic_add_return_acquire(1, (v))
 +#define atomic_inc_return_release(v)  atomic_add_return_release(1, (v))
 +#define atomic_inc_return(v)  atomic_add_return(1, (v))
 +
 +#define atomic_sub_return_relaxed atomic_sub_return_relaxed
 +#define atomic_sub_return_acquire atomic_sub_return_acquire
 +#define atomic_sub_return_release atomic_sub_return_release
 +#define atomic_sub_return atomic_sub_return
 +
 +#define atomic_dec_return_relaxed(v)  atomic_sub_return_relaxed(1, (v))
 +#define atomic_dec_return_acquire(v)  atomic_sub_return_acquire(1, (v))
 +#define atomic_dec_return_release(v)  atomic_sub_return_release(1, (v))
 +#define atomic_dec_return(v)  atomic_sub_return(1, (v))
 +
 +#define atomic_xchg_relaxed(v, new)   xchg_relaxed(&((v)->counter), (new))
 +#define atomic_xchg_acquire(v, new)   xchg_acquire(&((v)->counter), (new))
 +#define atomic_xchg_release(v, new)   xchg_release(&((v)->counter), (new))
  #define atomic_xchg(v, new)   xchg(&((v)->counter), (new))
 +
 +#define atomic_cmpxchg_relaxed(v, old, new)   \
 +  cmpxchg_relaxed(&((v)->counter), (old), (new))
 +#define atomic_cmpxchg_acquire(v, old, new)   \
 +  cmpxchg_acquire(&((v)->counter), (old), (new))
 +#define atomic_cmpxchg_release(v, old, new)   \
 +  cmpxchg_release(&((v)->counter), (old), (new))
  #define atomic_cmpxchg(v, old, new)   cmpxchg(&((v)->counter), (old), (new))
  
  #define atomic_inc(v) atomic_add(1, (v))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-05-23 Thread Catalin Marinas
On Fri, May 23, 2014 at 07:44:02AM +0100, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in
> arch/arm64/mm/mmu.c between commit a501e32430d4 ("arm64: Clean up the
> default pgprot setting") and 206a2a73a62d ("arm64: mm: Create gigabyte
> kernel logical mappings where possible") from the arm64 tree and commit
> d7ecbddf4cae ("arm64: Add function to create identity mappings") from
> the tip tree.
> 
> I fixed it up (maybe - see below - this may not be complete) and can
> carry the fix as necessary (no action is required).

Thanks for fixing it up, it is correct.

(but I now have to go after the arm64 EFI_STUB guys as it breaks non-EFI
booting).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-05-23 Thread Catalin Marinas
On Fri, May 23, 2014 at 07:28:44AM +0100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/thread_info.h
> index 9c086c63f911,7b8e3a2a00fb..
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@@ -103,12 -99,7 +102,11 @@@ static inline struct thread_info *curre
>   #define TIF_SIGPENDING  0
>   #define TIF_NEED_RESCHED1
>   #define TIF_NOTIFY_RESUME   2   /* callback before returning to user */
>  +#define TIF_FOREIGN_FPSTATE 3   /* CPU's FP state is not current's */
>   #define TIF_SYSCALL_TRACE   8
>  +#define TIF_SYSCALL_AUDIT   9
>  +#define TIF_SYSCALL_TRACEPOINT  10
>  +#define TIF_SECCOMP 11
> - #define TIF_POLLING_NRFLAG  16
>   #define TIF_MEMDIE  18  /* is terminating due to OOM killer */
>   #define TIF_FREEZE  19
>   #define TIF_RESTORE_SIGMASK 20

It looks fine, thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-05-23 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/arm64/mm/mmu.c between commit a501e32430d4 ("arm64: Clean up the
default pgprot setting") and 206a2a73a62d ("arm64: mm: Create gigabyte
kernel logical mappings where possible") from the arm64 tree and commit
d7ecbddf4cae ("arm64: Add function to create identity mappings") from
the tip tree.

I fixed it up (maybe - see below - this may not be complete) and can
carry the fix as necessary (no action is required).

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

diff --cc arch/arm64/mm/mmu.c
index 3a729de96f15,4a829a210bb6..
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -158,6 -192,17 +160,17 @@@ static void __init alloc_init_pmd(pud_
  {
pmd_t *pmd;
unsigned long next;
+   pmdval_t prot_sect;
+   pgprot_t prot_pte;
+ 
+   if (map_io) {
+   prot_sect = PMD_TYPE_SECT | PMD_SECT_AF |
+   PMD_ATTRINDX(MT_DEVICE_nGnRE);
+   prot_pte = __pgprot(PROT_DEVICE_nGnRE);
+   } else {
 -  prot_sect = prot_sect_kernel;
++  prot_sect = PROT_SECT_NORMAL_EXEC;
+   prot_pte = PAGE_KERNEL_EXEC;
+   }
  
/*
 * Check for initial section mappings in the pgd/pud and remove them.
@@@ -195,30 -242,7 +210,30 @@@ static void __init alloc_init_pud(pgd_
  
do {
next = pud_addr_end(addr, end);
 -  alloc_init_pmd(pud, addr, next, phys, map_io);
 +
 +  /*
 +   * For 4K granule only, attempt to put down a 1GB block
 +   */
 +  if ((PAGE_SHIFT == 12) &&
 +  ((addr | next | phys) & ~PUD_MASK) == 0) {
 +  pud_t old_pud = *pud;
 +  set_pud(pud, __pud(phys | PROT_SECT_NORMAL_EXEC));
 +
 +  /*
 +   * If we have an old value for a pud, it will
 +   * be pointing to a pmd table that we no longer
 +   * need (from swapper_pg_dir).
 +   *
 +   * Look up the old pmd table and free it.
 +   */
 +  if (!pud_none(old_pud)) {
 +  phys_addr_t table = __pa(pmd_offset(_pud, 
0));
 +  memblock_free(table, PAGE_SIZE);
 +  flush_tlb_all();
 +  }
 +  } else {
-   alloc_init_pmd(pud, addr, next, phys);
++  alloc_init_pmd(pud, addr, next, phys, map_io);
 +  }
phys += next - addr;
} while (pud++, addr = next, addr != end);
  }


signature.asc
Description: PGP signature


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

2014-05-23 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/arm64/include/asm/thread_info.h between commit 449f81a4da4d
("arm64: make a single hook to syscall_trace() for all syscall
features") from the arm64 tree and commit 842514849a61 ("arm64: Remove
TIF_POLLING_NRFLAG") from the tip 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/arm64/include/asm/thread_info.h
index 9c086c63f911,7b8e3a2a00fb..
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@@ -103,12 -99,7 +102,11 @@@ static inline struct thread_info *curre
  #define TIF_SIGPENDING0
  #define TIF_NEED_RESCHED  1
  #define TIF_NOTIFY_RESUME 2   /* callback before returning to user */
 +#define TIF_FOREIGN_FPSTATE   3   /* CPU's FP state is not current's */
  #define TIF_SYSCALL_TRACE 8
 +#define TIF_SYSCALL_AUDIT 9
 +#define TIF_SYSCALL_TRACEPOINT10
 +#define TIF_SECCOMP   11
- #define TIF_POLLING_NRFLAG16
  #define TIF_MEMDIE18  /* is terminating due to OOM killer */
  #define TIF_FREEZE19
  #define TIF_RESTORE_SIGMASK   20


signature.asc
Description: PGP signature


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

2014-05-23 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/arm64/include/asm/thread_info.h between commit 449f81a4da4d
(arm64: make a single hook to syscall_trace() for all syscall
features) from the arm64 tree and commit 842514849a61 (arm64: Remove
TIF_POLLING_NRFLAG) from the tip 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/arm64/include/asm/thread_info.h
index 9c086c63f911,7b8e3a2a00fb..
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@@ -103,12 -99,7 +102,11 @@@ static inline struct thread_info *curre
  #define TIF_SIGPENDING0
  #define TIF_NEED_RESCHED  1
  #define TIF_NOTIFY_RESUME 2   /* callback before returning to user */
 +#define TIF_FOREIGN_FPSTATE   3   /* CPU's FP state is not current's */
  #define TIF_SYSCALL_TRACE 8
 +#define TIF_SYSCALL_AUDIT 9
 +#define TIF_SYSCALL_TRACEPOINT10
 +#define TIF_SECCOMP   11
- #define TIF_POLLING_NRFLAG16
  #define TIF_MEMDIE18  /* is terminating due to OOM killer */
  #define TIF_FREEZE19
  #define TIF_RESTORE_SIGMASK   20


signature.asc
Description: PGP signature


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

2014-05-23 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/arm64/mm/mmu.c between commit a501e32430d4 (arm64: Clean up the
default pgprot setting) and 206a2a73a62d (arm64: mm: Create gigabyte
kernel logical mappings where possible) from the arm64 tree and commit
d7ecbddf4cae (arm64: Add function to create identity mappings) from
the tip tree.

I fixed it up (maybe - see below - this may not be complete) and can
carry the fix as necessary (no action is required).

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

diff --cc arch/arm64/mm/mmu.c
index 3a729de96f15,4a829a210bb6..
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -158,6 -192,17 +160,17 @@@ static void __init alloc_init_pmd(pud_
  {
pmd_t *pmd;
unsigned long next;
+   pmdval_t prot_sect;
+   pgprot_t prot_pte;
+ 
+   if (map_io) {
+   prot_sect = PMD_TYPE_SECT | PMD_SECT_AF |
+   PMD_ATTRINDX(MT_DEVICE_nGnRE);
+   prot_pte = __pgprot(PROT_DEVICE_nGnRE);
+   } else {
 -  prot_sect = prot_sect_kernel;
++  prot_sect = PROT_SECT_NORMAL_EXEC;
+   prot_pte = PAGE_KERNEL_EXEC;
+   }
  
/*
 * Check for initial section mappings in the pgd/pud and remove them.
@@@ -195,30 -242,7 +210,30 @@@ static void __init alloc_init_pud(pgd_
  
do {
next = pud_addr_end(addr, end);
 -  alloc_init_pmd(pud, addr, next, phys, map_io);
 +
 +  /*
 +   * For 4K granule only, attempt to put down a 1GB block
 +   */
 +  if ((PAGE_SHIFT == 12) 
 +  ((addr | next | phys)  ~PUD_MASK) == 0) {
 +  pud_t old_pud = *pud;
 +  set_pud(pud, __pud(phys | PROT_SECT_NORMAL_EXEC));
 +
 +  /*
 +   * If we have an old value for a pud, it will
 +   * be pointing to a pmd table that we no longer
 +   * need (from swapper_pg_dir).
 +   *
 +   * Look up the old pmd table and free it.
 +   */
 +  if (!pud_none(old_pud)) {
 +  phys_addr_t table = __pa(pmd_offset(old_pud, 
0));
 +  memblock_free(table, PAGE_SIZE);
 +  flush_tlb_all();
 +  }
 +  } else {
-   alloc_init_pmd(pud, addr, next, phys);
++  alloc_init_pmd(pud, addr, next, phys, map_io);
 +  }
phys += next - addr;
} while (pud++, addr = next, addr != end);
  }


signature.asc
Description: PGP signature


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

2014-05-23 Thread Catalin Marinas
On Fri, May 23, 2014 at 07:28:44AM +0100, Stephen Rothwell wrote:
 diff --cc arch/arm64/include/asm/thread_info.h
 index 9c086c63f911,7b8e3a2a00fb..
 --- a/arch/arm64/include/asm/thread_info.h
 +++ b/arch/arm64/include/asm/thread_info.h
 @@@ -103,12 -99,7 +102,11 @@@ static inline struct thread_info *curre
   #define TIF_SIGPENDING  0
   #define TIF_NEED_RESCHED1
   #define TIF_NOTIFY_RESUME   2   /* callback before returning to user */
  +#define TIF_FOREIGN_FPSTATE 3   /* CPU's FP state is not current's */
   #define TIF_SYSCALL_TRACE   8
  +#define TIF_SYSCALL_AUDIT   9
  +#define TIF_SYSCALL_TRACEPOINT  10
  +#define TIF_SECCOMP 11
 - #define TIF_POLLING_NRFLAG  16
   #define TIF_MEMDIE  18  /* is terminating due to OOM killer */
   #define TIF_FREEZE  19
   #define TIF_RESTORE_SIGMASK 20

It looks fine, thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-05-23 Thread Catalin Marinas
On Fri, May 23, 2014 at 07:44:02AM +0100, Stephen Rothwell wrote:
 Today's linux-next merge of the tip tree got a conflict in
 arch/arm64/mm/mmu.c between commit a501e32430d4 (arm64: Clean up the
 default pgprot setting) and 206a2a73a62d (arm64: mm: Create gigabyte
 kernel logical mappings where possible) from the arm64 tree and commit
 d7ecbddf4cae (arm64: Add function to create identity mappings) from
 the tip tree.
 
 I fixed it up (maybe - see below - this may not be complete) and can
 carry the fix as necessary (no action is required).

Thanks for fixing it up, it is correct.

(but I now have to go after the arm64 EFI_STUB guys as it breaks non-EFI
booting).

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/