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

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

[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 Rothwell                    sfr@canb.auug.org.au

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

[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 <suzuki.poulose@arm.com>

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 Rothwell                    sfr@canb.auug.org.au
> 

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

[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

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

[Stephen Rothwell]

Hi Catalin,

On Thu, 22 Oct 2015 16:32:01 +0100 Catalin Marinas <catalin.marinas@arm.com> 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 Rothwell                    sfr@canb.auug.org.au

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

[broonie]

Hi all,

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

  arch/arm64/kernel/perf_callchain.c

between commit:

  ed876d35a1dc7 ("arm64: Make perf_callchain_kernel() use arch_stack_walk()")

from the arm64 tree and commit:

  1c3430516b073 ("perf: Add wrappers for invoking guest callbacks")

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.

diff --cc arch/arm64/kernel/perf_callchain.c
index e9b7d99f4e3a0,db04a55cee7e0..0000000000000
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@@ -141,7 -147,9 +141,7 @@@ static bool callchain_trace(void *data
  void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
  			   struct pt_regs *regs)
  {
- 	if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
 -	struct stackframe frame;
 -
+ 	if (perf_guest_state()) {
  		/* We don't support guest os callchain now */
  		return;
  	}

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/process.c
  arch/arm64/kernel/signal.c

between commits:

  d2e0d8f9746d ("arm64: move preemption disablement to prctl handlers")
  4d1c2ee2709f ("arm64: entry: move bulk of ret_to_user to C")

from the arm64 tree and commit:

  94f9c00f6460 ("arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores")

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/kernel/process.c
index 8334facd5356,e0e7f4e9b607..000000000000
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@@ -469,22 -469,7 +470,13 @@@ static void erratum_1418040_thread_swit
  	write_sysreg(val, cntkctl_el1);
  }
  
- static void compat_thread_switch(struct task_struct *next)
- {
- 	if (!is_compat_thread(task_thread_info(next)))
- 		return;
- 
- 	if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
- 		set_tsk_thread_flag(next, TIF_NOTIFY_RESUME);
- }
- 
 -static void update_sctlr_el1(u64 sctlr)
 +/*
 + * __switch_to() checks current->thread.sctlr_user as an optimisation. Therefore
 + * this function must be called with preemption disabled and the update to
 + * sctlr_user must be made in the same preemption disabled block so that
 + * __switch_to() does not see the variable update before the SCTLR_EL1 one.
 + */
 +void update_sctlr_el1(u64 sctlr)
  {
  	/*
  	 * EnIA must not be cleared while in the kernel as this is necessary for
diff --cc arch/arm64/kernel/signal.c
index e42743134ae2,22899c86711a..000000000000
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@@ -917,20 -912,8 +917,7 @@@ static void do_signal(struct pt_regs *r
  	restore_saved_sigmask();
  }
  
- static bool cpu_affinity_invalid(struct pt_regs *regs)
- {
- 	if (!compat_user_mode(regs))
- 		return false;
- 
- 	/*
- 	 * We're preemptible, but a reschedule will cause us to check the
- 	 * affinity again.
- 	 */
- 	return !cpumask_test_cpu(raw_smp_processor_id(),
- 				 system_32bit_el0_cpumask());
- }
- 
 -asmlinkage void do_notify_resume(struct pt_regs *regs,
 -				 unsigned long thread_flags)
 +void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags)
  {
  	do {
  		if (thread_flags & _TIF_NEED_RESCHED) {

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

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

[Stephen Rothwell]

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

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..000000000000
--- 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/
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  ab7876a98a21 ("arm64: elf: Enable BTI at exec based on ELF program properties")

from the arm64 tree and commit:

  5e3c6a312a09 ("ARM/arm64: vdso: Use common vdso clock mode storage")

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 fdfdc77c5067,c6c32fb7f546..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -9,8 -9,6 +9,7 @@@ config ARM6
  	select ACPI_MCFG if (ACPI && PCI)
  	select ACPI_SPCR_TABLE if ACPI
  	select ACPI_PPTT if ACPI
 +	select ARCH_BINFMT_ELF_STATE
- 	select ARCH_CLOCKSOURCE_DATA
  	select ARCH_HAS_DEBUG_VIRTUAL
  	select ARCH_HAS_DEVMEM_IS_ALLOWED
  	select ARCH_HAS_DMA_PREP_COHERENT

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

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

[Catalin Marinas]

On Wed, Mar 18, 2020 at 03:27:31PM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/Kconfig
> index fdfdc77c5067,c6c32fb7f546..000000000000
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -9,8 -9,6 +9,7 @@@ config ARM6
>   	select ACPI_MCFG if (ACPI && PCI)
>   	select ACPI_SPCR_TABLE if ACPI
>   	select ACPI_PPTT if ACPI
>  +	select ARCH_BINFMT_ELF_STATE
> - 	select ARCH_CLOCKSOURCE_DATA
>   	select ARCH_HAS_DEBUG_VIRTUAL
>   	select ARCH_HAS_DEVMEM_IS_ALLOWED
>   	select ARCH_HAS_DMA_PREP_COHERENT

It looks fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/arch_topology.h

between commit:

  cd0ed03a8903 ("arm64: use activity monitors for frequency invariance")

from the arm64 tree and commit:

  ad58cc5cc50c ("drivers/base/arch_topology: Add infrastructure to store and update instantaneous thermal pressure")

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/arch_topology.h
index 1ccdddb541a7,88a115e81f27..000000000000
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@@ -33,8 -33,16 +33,18 @@@ unsigned long topology_get_freq_scale(i
  	return per_cpu(freq_scale, cpu);
  }
  
 +bool arch_freq_counters_available(struct cpumask *cpus);
 +
+ DECLARE_PER_CPU(unsigned long, thermal_pressure);
+ 
+ static inline unsigned long topology_get_thermal_pressure(int cpu)
+ {
+ 	return per_cpu(thermal_pressure, cpu);
+ }
+ 
+ void arch_set_thermal_pressure(struct cpumask *cpus,
+ 			       unsigned long th_pressure);
+ 
  struct cpu_topology {
  	int thread_id;
  	int core_id;

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

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

[Stephen Rothwell]

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

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..000000000000
--- 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

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

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

[Stephen Rothwell]

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

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..000000000000
--- 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

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

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

[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..000000000000
--- 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

[Stephen Rothwell]

Hi all,

On Wed, 1 Nov 2017 16:47:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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..000000000000
> --- 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

[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..000000000000
--- 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 <asm/sections.h>
+ #pragma GCC visibility pop
+ 
  #include <linux/efi.h>
  #include <asm/efi.h>
 +#include <asm/memory.h>
- #include <asm/sections.h>
  #include <asm/sysreg.h>
  
  #include "efistub.h"

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

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 13:38:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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..000000000000
> --- 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 <asm/sections.h>
> + #pragma GCC visibility pop
> + 
>   #include <linux/efi.h>
>   #include <asm/efi.h>
>  +#include <asm/memory.h>
> - #include <asm/sections.h>
>   #include <asm/sysreg.h>
>   
>   #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

[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..000000000000
--- 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, &ghes_sea, list) {
 +		if (!ghes_proc(ghes))
 +			ret = 0;
 +	}
 +	rcu_read_unlock();
 +	return ret;
 +}
 +
 +static void ghes_sea_add(struct ghes *ghes)
 +{
 +	mutex_lock(&ghes_list_mutex);
 +	list_add_rcu(&ghes->list, &ghes_sea);
 +	mutex_unlock(&ghes_list_mutex);
 +}
 +
 +static void ghes_sea_remove(struct ghes *ghes)
 +{
 +	mutex_lock(&ghes_list_mutex);
 +	list_del_rcu(&ghes->list);
 +	mutex_unlock(&ghes_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(&ghes_list_mutex);
- 		if (list_empty(&ghes_sci))
- 			register_acpi_hed_notifier(&ghes_notifier_sci);
- 		list_add_rcu(&ghes->list, &ghes_sci);
+ 		if (list_empty(&ghes_hed))
+ 			register_acpi_hed_notifier(&ghes_notifier_hed);
+ 		list_add_rcu(&ghes->list, &ghes_hed);
  		mutex_unlock(&ghes_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(&ghes_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

[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 <sfr@canb.auug.org.au> 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..000000000000
> --- 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, &ghes_sea, list) {
>  +		if (!ghes_proc(ghes))
>  +			ret = 0;
>  +	}
>  +	rcu_read_unlock();
>  +	return ret;
>  +}
>  +
>  +static void ghes_sea_add(struct ghes *ghes)
>  +{
>  +	mutex_lock(&ghes_list_mutex);
>  +	list_add_rcu(&ghes->list, &ghes_sea);
>  +	mutex_unlock(&ghes_list_mutex);
>  +}
>  +
>  +static void ghes_sea_remove(struct ghes *ghes)
>  +{
>  +	mutex_lock(&ghes_list_mutex);
>  +	list_del_rcu(&ghes->list);
>  +	mutex_unlock(&ghes_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(&ghes_list_mutex);
> - 		if (list_empty(&ghes_sci))
> - 			register_acpi_hed_notifier(&ghes_notifier_sci);
> - 		list_add_rcu(&ghes->list, &ghes_sci);
> + 		if (list_empty(&ghes_hed))
> + 			register_acpi_hed_notifier(&ghes_notifier_hed);
> + 		list_add_rcu(&ghes->list, &ghes_hed);
>   		mutex_unlock(&ghes_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(&ghes_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 Rothwell

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

[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..000000000000
--- 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 <asm-generic/bug.h>
  

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

[Arnd Bergmann]

On Fri, Mar 31, 2017 at 5:02 AM, Stephen Rothwell <sfr@canb.auug.org.au> 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..000000000000
> --- 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

[Stephen Rothwell]

Hi Arnd,

On Fri, 31 Mar 2017 11:32:54 +0200 Arnd Bergmann <arnd@arndb.de> 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

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

[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..000000000000
--- 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

[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..000000000000
--- 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 = &gic_data[gic_nr];
+ 	if (WARN_ON(!gic || gic->domain))
+ 		return -EINVAL;
  
 -	gic_check_cpu_features();
 -
  	/* Initialize irq_chip */
- 	if (static_key_true(&supports_deactivate) && gic_nr == 0) {
- 		gic->chip = gic_eoimode1_chip;
+ 	gic->chip = gic_chip;
+ 
+ 	if (static_key_true(&supports_deactivate) && gic == &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 - &gic_data[0]));
  	}
  
  #ifdef CONFIG_SMP

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

[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..000000000000
--- 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(&memmap, md) {
+ 	for_each_efi_memory_desc(md) {
  		paddr = md->phys_addr;
  		npages = md->num_pages;
  

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

[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..000000000000
> --- 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(&memmap, 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

[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..000000000000
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -12,18 -12,34 +12,38 @@@
  #include <linux/efi.h>
  #include <asm/efi.h>
  #include <asm/sections.h>
+ #include <asm/sysreg.h>
  
 +#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

[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..000000000000
--- 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

[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 Rothwell                    sfr@canb.auug.org.au

diff --cc Documentation/arm/uefi.txt
index 7f1bed8872f3,7b3fdfe0f7ba..000000000000
--- 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.
 ---------------------------------------------------------------------------------

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

[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 Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/include/asm/atomic.h
index 5e13ad76a249,1e247ac2601a..000000000000
--- 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))

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

[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 Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/arm64/include/asm/atomic.h
> index 5e13ad76a249,1e247ac2601a..000000000000
> --- 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

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

[Stephen Rothwell]

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

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 Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/mm/mmu.c
index 3a729de96f15,4a829a210bb6..000000000000
--- 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);
  }

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

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

[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

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

[Stephen Rothwell]

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

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 Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/include/asm/thread_info.h
index 9c086c63f911,7b8e3a2a00fb..000000000000
--- 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_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_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

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

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

[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..000000000000
> --- 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_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_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