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

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/fpsimd.c

between commit:

  096622104e14 ("arm64: fpsimd: Prevent registers leaking across exec")

from Linus' tree and commit:

  cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq kernel-mode NEON")

from the arm64 tree.

I fixed it up (I just used the latter version) 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

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

[Stephen Rothwell]

Hi all,

On Thu, 24 Aug 2017 09:22:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/fpsimd.c
> 
> between commit:
> 
>   096622104e14 ("arm64: fpsimd: Prevent registers leaking across exec")
> 
> from Linus' tree and commit:
> 
>   cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq kernel-mode NEON")
> 
> from the arm64 tree.
> 
> I fixed it up (I just used the latter version) 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.

Just a reminder that the above conflict still exists.
-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  68a63a412d18 ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y")

from Linus' tree and commit:

  baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")

from the arm64 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 c5ccca26a408,de052d935832..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -184,6 -186,10 +186,8 @@@ config ARM6
  	select HAVE_DEBUG_KMEMLEAK
  	select HAVE_DMA_CONTIGUOUS
  	select HAVE_DYNAMIC_FTRACE
 -	select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
 -		if $(cc-option,-fpatchable-function-entry=2)
+ 	select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
+ 		if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG)
  	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
  		if DYNAMIC_FTRACE_WITH_ARGS
  	select HAVE_EFFICIENT_UNALIGNED_ACCESS

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

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

[Catalin Marinas]

On Wed, Jan 25, 2023 at 08:36:47AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/Kconfig
> 
> between commit:
> 
>   68a63a412d18 ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y")
> 
> from Linus' tree and commit:
> 
>   baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")
> 
> from the arm64 tree.
[...]
> diff --cc arch/arm64/Kconfig
> index c5ccca26a408,de052d935832..000000000000
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -184,6 -186,10 +186,8 @@@ config ARM6
>   	select HAVE_DEBUG_KMEMLEAK
>   	select HAVE_DMA_CONTIGUOUS
>   	select HAVE_DYNAMIC_FTRACE
>  -	select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
>  -		if $(cc-option,-fpatchable-function-entry=2)
> + 	select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
> + 		if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG)
>   	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
>   		if DYNAMIC_FTRACE_WITH_ARGS
>   	select HAVE_EFFICIENT_UNALIGNED_ACCESS

Thanks Stephen. It looks fine.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/cpufeature.c

between commit:

  228a26b91228 ("arm64: Use the clearbhb instruction in mitigations")

from Linus' tree and commit:

  def8c222f054 ("arm64: Add support of PAuth QARMA3 architected algorithm")

from the arm64 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/cpufeature.c
index d33687673f6b,32aa0eb3ed68..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -231,7 -226,10 +231,11 @@@ static const struct arm64_ftr_bits ftr_
  };
  
  static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
 +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
+ 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ 		       FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
+ 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
+ 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 0),
  	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
  	ARM64_FTR_END,
  };

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

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

[Will Deacon]

On Wed, Mar 09, 2022 at 09:42:35AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commit:
> 
>   228a26b91228 ("arm64: Use the clearbhb instruction in mitigations")
> 
> from Linus' tree and commit:
> 
>   def8c222f054 ("arm64: Add support of PAuth QARMA3 architected algorithm")
> 
> from the arm64 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/cpufeature.c
> index d33687673f6b,32aa0eb3ed68..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -231,7 -226,10 +231,11 @@@ static const struct arm64_ftr_bits ftr_
>   };
>   
>   static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
>  +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
> + 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> + 		       FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
> + 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> + 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 0),
>   	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
>   	ARM64_FTR_END,
>   };

This (and https://lore.kernel.org/r/20220309093832.01585172@canb.auug.org.au)
are due to the surprise spectre mitigations which landed yesterday. Now
that's all public, I'll merge those changes into our for-next/core branch
and these conflicts should all disappear.

Thanks,

Will

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/sysreg.h

between commit:

  228a26b91228 ("arm64: Use the clearbhb instruction in mitigations")

from Linus' tree and commit:

  def8c222f054 ("arm64: Add support of PAuth QARMA3 architected algorithm")

from the arm64 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/sysreg.h
index 932d45b17877,2023a0e6c6d6..000000000000
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@@ -773,7 -773,8 +773,9 @@@
  #define ID_AA64ISAR1_GPI_IMP_DEF		0x1
  
  /* id_aa64isar2 */
 +#define ID_AA64ISAR2_CLEARBHB_SHIFT	28
+ #define ID_AA64ISAR2_APA3_SHIFT		12
+ #define ID_AA64ISAR2_GPA3_SHIFT		8
  #define ID_AA64ISAR2_RPRES_SHIFT	4
  #define ID_AA64ISAR2_WFXT_SHIFT		0
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/stacktrace.h
  arch/arm64/kernel/stacktrace.c

between commit:

  cd9bc2c92588 ("arm64: Recover kretprobe modified return address in stacktrace")

from Linus' tree and commit:

  552e196d88e5 ("arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR")

from the arm64 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/stacktrace.h
index a4e046ef4568,9a319eca5cab..000000000000
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@@ -57,12 -53,6 +54,9 @@@ struct stackframe 
  	DECLARE_BITMAP(stacks_done, __NR_STACK_TYPES);
  	unsigned long prev_fp;
  	enum stack_type prev_type;
- #ifdef CONFIG_FUNCTION_GRAPH_TRACER
- 	int graph;
- #endif
 +#ifdef CONFIG_KRETPROBES
 +	struct llist_node *kr_cur;
 +#endif
  };
  
  extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
diff --cc arch/arm64/kernel/stacktrace.c
index c30624fff6ac,13ea4e4a4d27..000000000000
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@@ -38,12 -38,6 +38,9 @@@ void start_backtrace(struct stackframe 
  {
  	frame->fp = fp;
  	frame->pc = pc;
- #ifdef CONFIG_FUNCTION_GRAPH_TRACER
- 	frame->graph = 0;
- #endif
 +#ifdef CONFIG_KRETPROBES
 +	frame->kr_cur = NULL;
 +#endif
  
  	/*
  	 * Prime the first unwind.
@@@ -126,19 -122,14 +125,18 @@@ int notrace unwind_frame(struct task_st
  		 * to hook a function return.
  		 * So replace it to an original value.
  		 */
- 		ret_stack = ftrace_graph_get_ret_stack(tsk, frame->graph++);
- 		if (WARN_ON_ONCE(!ret_stack))
+ 		orig_pc = ftrace_graph_ret_addr(tsk, NULL, frame->pc,
+ 						(void *)frame->fp);
+ 		if (WARN_ON_ONCE(frame->pc == orig_pc))
  			return -EINVAL;
- 		frame->pc = ret_stack->ret;
+ 		frame->pc = orig_pc;
  	}
  #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
 +#ifdef CONFIG_KRETPROBES
 +	if (is_kretprobe_trampoline(frame->pc))
 +		frame->pc = kretprobe_find_ret_addr(tsk, (void *)frame->fp, &frame->kr_cur);
 +#endif
  
- 	frame->pc = ptrauth_strip_insn_pac(frame->pc);
- 
  	return 0;
  }
  NOKPROBE_SYMBOL(unwind_frame);

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

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

[Will Deacon]

On Thu, Nov 04, 2021 at 09:32:08AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got conflicts in:
> 
>   arch/arm64/include/asm/stacktrace.h
>   arch/arm64/kernel/stacktrace.c
> 
> between commit:
> 
>   cd9bc2c92588 ("arm64: Recover kretprobe modified return address in stacktrace")
> 
> from Linus' tree and commit:
> 
>   552e196d88e5 ("arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR")
> 
> from the arm64 tree.

D'oh, having realised this conflict last week, I completely forgot about
it when queuing that fix from Mark. I'll just drop it and wait until -rc1.

Cheers,

Will

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/cpucaps.h

between commit:

  20109a859a9b ("arm64: kernel: disable CNP on Carmel")

from Linus' tree and commit:

  18107f8a2df6 ("arm64: Support execute-only permissions with Enhanced PAN")

from the arm64 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/cpucaps.h
index c40f2490cd7b,9e3ec4dd56d8..000000000000
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@@ -66,8 -66,8 +66,9 @@@
  #define ARM64_WORKAROUND_1508412		58
  #define ARM64_HAS_LDAPR				59
  #define ARM64_KVM_PROTECTED_MODE		60
 -#define ARM64_HAS_EPAN				61
 +#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP	61
++#define ARM64_HAS_EPAN				62
  
--#define ARM64_NCAPS				62
++#define ARM64_NCAPS				63
  
  #endif /* __ASM_CPUCAPS_H */

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

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

[Catalin Marinas]

On Mon, Mar 29, 2021 at 09:29:40AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/cpucaps.h
> index c40f2490cd7b,9e3ec4dd56d8..000000000000
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@@ -66,8 -66,8 +66,9 @@@
>   #define ARM64_WORKAROUND_1508412		58
>   #define ARM64_HAS_LDAPR				59
>   #define ARM64_KVM_PROTECTED_MODE		60
>  -#define ARM64_HAS_EPAN				61
>  +#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP	61
> ++#define ARM64_HAS_EPAN				62
>   
> --#define ARM64_NCAPS				62
> ++#define ARM64_NCAPS				63
>   
>   #endif /* __ASM_CPUCAPS_H */

Thanks Stephen, it looks fine.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/vdso/compat_gettimeofday.h

between commit:

  97884ca8c292 ("arm64: Introduce a way to disable the 32bit vdso")

from Linus' tree and commit:

  3503d56cc723 ("arm64/vdso: Add time namespace page")

from the arm64 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/vdso/compat_gettimeofday.h
index 9a625e8947ff,d0cbb04bfc10..000000000000
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@@ -152,12 -153,18 +153,24 @@@ static __always_inline const struct vds
  	return ret;
  }
  
 +static inline bool vdso_clocksource_ok(const struct vdso_data *vd)
 +{
 +	return vd->clock_mode == VDSO_CLOCKMODE_ARCHTIMER;
 +}
 +#define vdso_clocksource_ok	vdso_clocksource_ok
 +
+ #ifdef CONFIG_TIME_NS
+ static __always_inline const struct vdso_data *__arch_get_timens_vdso_data(void)
+ {
+ 	const struct vdso_data *ret;
+ 
+ 	/* See __arch_get_vdso_data(). */
+ 	asm volatile("mov %0, %1" : "=r"(ret) : "r"(_timens_data));
+ 
+ 	return ret;
+ }
+ #endif
+ 
  #endif /* !__ASSEMBLY__ */
  
  #endif /* __ASM_VDSO_GETTIMEOFDAY_H */

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/cpucaps.h
  arch/arm64/kernel/cpu_errata.c

between commits:

  d3ec3a08fa70 ("arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set")
  93916beb7014 ("arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT")
  9405447ef79b ("arm64: Avoid Cavium TX2 erratum 219 when switching TTBR")

from Linus' tree and commit:

  05460849c3b5 ("arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419")

from the arm64 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/cpucaps.h
index ac1dbca3d0cd,f05afaec18cd..000000000000
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@@ -52,9 -52,8 +52,10 @@@
  #define ARM64_HAS_IRQ_PRIO_MASKING		42
  #define ARM64_HAS_DCPODP			43
  #define ARM64_WORKAROUND_1463225		44
 -#define ARM64_WORKAROUND_1542419		45
 +#define ARM64_WORKAROUND_CAVIUM_TX2_219_TVM	45
 +#define ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM	46
++#define ARM64_WORKAROUND_1542419		47
  
- #define ARM64_NCAPS				47
 -#define ARM64_NCAPS				46
++#define ARM64_NCAPS				48
  
  #endif /* __ASM_CPUCAPS_H */
diff --cc arch/arm64/kernel/cpu_errata.c
index 6c3b10a41bd8,bf29b59e096f..000000000000
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@@ -624,30 -618,18 +619,42 @@@ check_branch_predictor(const struct arm
  	return (need_wa > 0);
  }
  
 +static const __maybe_unused struct midr_range tx2_family_cpus[] = {
 +	MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
 +	MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
 +	{},
 +};
 +
 +static bool __maybe_unused
 +needs_tx2_tvm_workaround(const struct arm64_cpu_capabilities *entry,
 +			 int scope)
 +{
 +	int i;
 +
 +	if (!is_affected_midr_range_list(entry, scope) ||
 +	    !is_hyp_mode_available())
 +		return false;
 +
 +	for_each_possible_cpu(i) {
 +		if (MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0) != 0)
 +			return true;
 +	}
 +
 +	return false;
 +}
 +
+ static bool __maybe_unused
+ has_neoverse_n1_erratum_1542419(const struct arm64_cpu_capabilities *entry,
+ 				int scope)
+ {
+ 	u32 midr = read_cpuid_id();
+ 	bool has_dic = read_cpuid_cachetype() & BIT(CTR_DIC_SHIFT);
+ 	const struct midr_range range = MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1);
+ 
+ 	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
+ 	return is_midr_in_range(midr, &range) && has_dic;
+ }
+ 
  #ifdef CONFIG_HARDEN_EL2_VECTORS
  
  static const struct midr_range arm64_harden_el2_vectors[] = {
@@@ -877,18 -859,15 +884,28 @@@ const struct arm64_cpu_capabilities arm
  		.matches = has_cortex_a76_erratum_1463225,
  	},
  #endif
 +#ifdef CONFIG_CAVIUM_TX2_ERRATUM_219
 +	{
 +		.desc = "Cavium ThunderX2 erratum 219 (KVM guest sysreg trapping)",
 +		.capability = ARM64_WORKAROUND_CAVIUM_TX2_219_TVM,
 +		ERRATA_MIDR_RANGE_LIST(tx2_family_cpus),
 +		.matches = needs_tx2_tvm_workaround,
 +	},
 +	{
 +		.desc = "Cavium ThunderX2 erratum 219 (PRFM removal)",
 +		.capability = ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM,
 +		ERRATA_MIDR_RANGE_LIST(tx2_family_cpus),
 +	},
++#endif
+ #ifdef CONFIG_ARM64_ERRATUM_1542419
+ 	{
+ 		/* we depend on the firmware portion for correctness */
+ 		.desc = "ARM erratum 1542419 (kernel portion)",
+ 		.capability = ARM64_WORKAROUND_1542419,
+ 		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
+ 		.matches = has_neoverse_n1_erratum_1542419,
+ 		.cpu_enable = cpu_enable_trap_ctr_access,
+ 	},
  #endif
  	{
  	}

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

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

[Catalin Marinas]

Hi Stephen,

On Mon, Oct 28, 2019 at 08:39:14AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got conflicts in:
> 
>   arch/arm64/include/asm/cpucaps.h
>   arch/arm64/kernel/cpu_errata.c
> 
> between commits:
> 
>   d3ec3a08fa70 ("arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set")
>   93916beb7014 ("arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT")
>   9405447ef79b ("arm64: Avoid Cavium TX2 erratum 219 when switching TTBR")
> 
> from Linus' tree and commit:
> 
>   05460849c3b5 ("arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419")
> 
> from the arm64 tree.

Thanks for this. The conflict resolution is correct.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  mm/vmalloc.c

between commit:

  8e41f8726dcf ("mm/vmalloc: Fix calculation of direct map addr range")

from Linus' tree and commit:

  4739d53fcd1d ("arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP")

from the arm64 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/vmalloc.c
index 4c9e150e5ad3,6bd7b515995c..000000000000
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@@ -2123,22 -2123,11 +2123,11 @@@ static inline void set_area_direct_map(
  /* Handle removing and resetting vm mappings related to the vm_struct. */
  static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
  {
 -	unsigned long addr = (unsigned long)area->addr;
  	unsigned long start = ULONG_MAX, end = 0;
  	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
 +	int flush_dmap = 0;
  	int i;
  
- 	/*
- 	 * The below block can be removed when all architectures that have
- 	 * direct map permissions also have set_direct_map_() implementations.
- 	 * This is concerned with resetting the direct map any an vm alias with
- 	 * execute permissions, without leaving a RW+X window.
- 	 */
- 	if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
- 		set_memory_nx((unsigned long)area->addr, area->nr_pages);
- 		set_memory_rw((unsigned long)area->addr, area->nr_pages);
- 	}
- 
  	remove_vm_area(area->addr);
  
  	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */

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

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/arm64/silicon-errata.txt
  arch/arm64/Kconfig

between commit:

  ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")

from Linus' tree and commit:

  a457b0f7f50d ("arm64: Add configuration/documentation for Cortex-A76 erratum 1165522")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/arm64/silicon-errata.txt
index 8f9577621144,04f0bc4690c6..000000000000
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@@ -57,7 -57,7 +57,8 @@@ stable kernels
  | ARM            | Cortex-A73      | #858921         | ARM64_ERRATUM_858921        |
  | ARM            | Cortex-A55      | #1024718        | ARM64_ERRATUM_1024718       |
  | ARM            | Cortex-A76      | #1188873        | ARM64_ERRATUM_1188873       |
+ | ARM            | Cortex-A76      | #1165522        | ARM64_ERRATUM_1165522       |
 +| ARM            | Cortex-A76      | #1286807        | ARM64_ERRATUM_1286807       |
  | ARM            | MMU-500         | #841119,#826419 | N/A                         |
  |                |                 |                 |                             |
  | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375        |
diff --cc arch/arm64/Kconfig
index 0d9a45f948c2,4dbef530cf58..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -478,24 -504,18 +485,36 @@@ config ARM64_ERRATUM_118887
  
  	  If unsure, say Y.
  
+ config ARM64_ERRATUM_1165522
+ 	bool "Cortex-A76: Speculative AT instruction using out-of-context translation regime could cause subsequent request to generate an incorrect translation"
+ 	default y
+ 	help
+ 	  This option adds work arounds for ARM Cortex-A76 erratum 1165522
+ 
+ 	  Affected Cortex-A76 cores (r0p0, r1p0, r2p0) could end-up with
+ 	  corrupted TLBs by speculating an AT instruction during a guest
+ 	  context switch.
+ 
+ 	  If unsure, say Y.
+ 
 +config ARM64_ERRATUM_1286807
 +	bool "Cortex-A76: Modification of the translation table for a virtual address might lead to read-after-read ordering violation"
 +	default y
 +	select ARM64_WORKAROUND_REPEAT_TLBI
 +	help
 +	  This option adds workaround for ARM Cortex-A76 erratum 1286807
 +
 +	  On the affected Cortex-A76 cores (r0p0 to r3p0), if a virtual
 +	  address for a cacheable mapping of a location is being
 +	  accessed by a core while another core is remapping the virtual
 +	  address to a new physical page using the recommended
 +	  break-before-make sequence, then under very rare circumstances
 +	  TLBI+DSB completes before a read using the translation being
 +	  invalidated has been observed by other observers. The
 +	  workaround repeats the TLBI+DSB operation.
 +
 +	  If unsure, say Y.
 +
  config CAVIUM_ERRATUM_22375
  	bool "Cavium erratum 22375, 24313"
  	default y

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

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

[Catalin Marinas]

On Tue, Dec 11, 2018 at 08:52:57AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got conflicts in:
> 
>   Documentation/arm64/silicon-errata.txt
>   arch/arm64/Kconfig
> 
> between commit:
> 
>   ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")
> 
> from Linus' tree and commit:
> 
>   a457b0f7f50d ("arm64: Add configuration/documentation for Cortex-A76 erratum 1165522")
> 
> from the arm64 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.

It looks fine. Thanks Stephen.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/cpu_errata.c

between commit:

  ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")

from Linus' tree and commit:

  c9460dcb06ee ("arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE")

from the arm64 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/cpu_errata.c
index 6ad715d67df8,bb44635026f8..000000000000
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@@ -570,21 -570,43 +570,57 @@@ static const struct midr_range arm64_ha
  
  #endif
  
 +#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
 +
 +static const struct midr_range arm64_repeat_tlbi_cpus[] = {
 +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
 +	MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0, 0, 0, 0),
 +#endif
 +#ifdef CONFIG_ARM64_ERRATUM_1286807
 +	MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 0),
 +#endif
 +	{},
 +};
 +
 +#endif
 +
- const struct arm64_cpu_capabilities arm64_errata[] = {
+ #ifdef CONFIG_CAVIUM_ERRATUM_27456
+ static const struct midr_range cavium_erratum_27456_cpus[] = {
+ 	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
+ 	MIDR_RANGE(MIDR_THUNDERX, 0, 0, 1, 1),
+ 	/* Cavium ThunderX, T81 pass 1.0 */
+ 	MIDR_REV(MIDR_THUNDERX_81XX, 0, 0),
+ 	{},
+ };
+ #endif
+ 
+ #ifdef CONFIG_CAVIUM_ERRATUM_30115
+ static const struct midr_range cavium_erratum_30115_cpus[] = {
+ 	/* Cavium ThunderX, T88 pass 1.x - 2.2 */
+ 	MIDR_RANGE(MIDR_THUNDERX, 0, 0, 1, 2),
+ 	/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+ 	MIDR_REV_RANGE(MIDR_THUNDERX_81XX, 0, 0, 2),
+ 	/* Cavium ThunderX, T83 pass 1.0 */
+ 	MIDR_REV(MIDR_THUNDERX_83XX, 0, 0),
+ 	{},
+ };
+ #endif
+ 
+ #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+ static const struct arm64_cpu_capabilities qcom_erratum_1003_list[] = {
+ 	{
+ 		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
+ 	},
+ 	{
+ 		.midr_range.model = MIDR_QCOM_KRYO,
+ 		.matches = is_kryo_midr,
+ 	},
+ 	{},
+ };
+ #endif
+ 
+ #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
+ static const struct midr_range workaround_clean_cache[] = {
  #if	defined(CONFIG_ARM64_ERRATUM_826319) || \
  	defined(CONFIG_ARM64_ERRATUM_827319) || \
  	defined(CONFIG_ARM64_ERRATUM_824069)
@@@ -697,23 -698,17 +712,17 @@@ const struct arm64_cpu_capabilities arm
  	},
  #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
  	{
- 		.desc = "Qualcomm Technologies Falkor erratum 1003",
+ 		.desc = "Qualcomm Technologies Falkor/Kryo erratum 1003",
  		.capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
- 		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
- 	},
- 	{
- 		.desc = "Qualcomm Technologies Kryo erratum 1003",
- 		.capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
- 		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
- 		.midr_range.model = MIDR_QCOM_KRYO,
- 		.matches = is_kryo_midr,
+ 		.matches = multi_entry_cap_matches,
+ 		.match_list = qcom_erratum_1003_list,
  	},
  #endif
 -#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
 +#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
  	{
 -		.desc = "Qualcomm Technologies Falkor erratum 1009",
 +		.desc = "Qualcomm erratum 1009, ARM erratum 1286807",
  		.capability = ARM64_WORKAROUND_REPEAT_TLBI,
 -		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
 +		ERRATA_MIDR_RANGE_LIST(arm64_repeat_tlbi_cpus),
  	},
  #endif
  #ifdef CONFIG_ARM64_ERRATUM_858921

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

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

[Will Deacon]

On Fri, Dec 07, 2018 at 09:18:47AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/cpu_errata.c
> 
> between commit:
> 
>   ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")
> 
> from Linus' tree and commit:
> 
>   c9460dcb06ee ("arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE")
> 
> from the arm64 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks, Stephen, this looks correct to me. Suzuki -- can you please confirm?

Will

> diff --cc arch/arm64/kernel/cpu_errata.c
> index 6ad715d67df8,bb44635026f8..000000000000
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@@ -570,21 -570,43 +570,57 @@@ static const struct midr_range arm64_ha
>   
>   #endif
>   
>  +#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
>  +
>  +static const struct midr_range arm64_repeat_tlbi_cpus[] = {
>  +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
>  +	MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0, 0, 0, 0),
>  +#endif
>  +#ifdef CONFIG_ARM64_ERRATUM_1286807
>  +	MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 0),
>  +#endif
>  +	{},
>  +};
>  +
>  +#endif
>  +
> - const struct arm64_cpu_capabilities arm64_errata[] = {
> + #ifdef CONFIG_CAVIUM_ERRATUM_27456
> + static const struct midr_range cavium_erratum_27456_cpus[] = {
> + 	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
> + 	MIDR_RANGE(MIDR_THUNDERX, 0, 0, 1, 1),
> + 	/* Cavium ThunderX, T81 pass 1.0 */
> + 	MIDR_REV(MIDR_THUNDERX_81XX, 0, 0),
> + 	{},
> + };
> + #endif
> + 
> + #ifdef CONFIG_CAVIUM_ERRATUM_30115
> + static const struct midr_range cavium_erratum_30115_cpus[] = {
> + 	/* Cavium ThunderX, T88 pass 1.x - 2.2 */
> + 	MIDR_RANGE(MIDR_THUNDERX, 0, 0, 1, 2),
> + 	/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
> + 	MIDR_REV_RANGE(MIDR_THUNDERX_81XX, 0, 0, 2),
> + 	/* Cavium ThunderX, T83 pass 1.0 */
> + 	MIDR_REV(MIDR_THUNDERX_83XX, 0, 0),
> + 	{},
> + };
> + #endif
> + 
> + #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> + static const struct arm64_cpu_capabilities qcom_erratum_1003_list[] = {
> + 	{
> + 		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
> + 	},
> + 	{
> + 		.midr_range.model = MIDR_QCOM_KRYO,
> + 		.matches = is_kryo_midr,
> + 	},
> + 	{},
> + };
> + #endif
> + 
> + #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
> + static const struct midr_range workaround_clean_cache[] = {
>   #if	defined(CONFIG_ARM64_ERRATUM_826319) || \
>   	defined(CONFIG_ARM64_ERRATUM_827319) || \
>   	defined(CONFIG_ARM64_ERRATUM_824069)
> @@@ -697,23 -698,17 +712,17 @@@ const struct arm64_cpu_capabilities arm
>   	},
>   #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
>   	{
> - 		.desc = "Qualcomm Technologies Falkor erratum 1003",
> + 		.desc = "Qualcomm Technologies Falkor/Kryo erratum 1003",
>   		.capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
> - 		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
> - 	},
> - 	{
> - 		.desc = "Qualcomm Technologies Kryo erratum 1003",
> - 		.capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
> - 		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
> - 		.midr_range.model = MIDR_QCOM_KRYO,
> - 		.matches = is_kryo_midr,
> + 		.matches = multi_entry_cap_matches,
> + 		.match_list = qcom_erratum_1003_list,
>   	},
>   #endif
>  -#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
>  +#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
>   	{
>  -		.desc = "Qualcomm Technologies Falkor erratum 1009",
>  +		.desc = "Qualcomm erratum 1009, ARM erratum 1286807",
>   		.capability = ARM64_WORKAROUND_REPEAT_TLBI,
>  -		ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0),
>  +		ERRATA_MIDR_RANGE_LIST(arm64_repeat_tlbi_cpus),
>   	},
>   #endif
>   #ifdef CONFIG_ARM64_ERRATUM_858921

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

[Suzuki K Poulose]

Will, Stephen

On 07/12/2018 12:16, Will Deacon wrote:
> On Fri, Dec 07, 2018 at 09:18:47AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the arm64 tree got a conflict in:
>>
>>    arch/arm64/kernel/cpu_errata.c
>>
>> between commit:
>>
>>    ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")
>>
>> from Linus' tree and commit:
>>
>>    c9460dcb06ee ("arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE")
>>
>> from the arm64 tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
> 
> Thanks, Stephen, this looks correct to me. Suzuki -- can you please confirm?
> 


Yes, it looks correct to me did a boot test.

Thanks Stephen!

Cheers
Suzuki

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Makefile

between commits:

  38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
  2893af07e507 ("arm64: add endianness option to LDFLAGS instead of LD")
  96f95a17c1cf ("Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"")

from Linus' tree and commit:

  c931d34ea085 ("arm64: build with baremetal linker target instead of Linux when available")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Will Deacon]

Hi Stephen,

On Tue, Jul 24, 2018 at 08:50:15AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/Makefile
> 
> between commits:
> 
>   38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
>   2893af07e507 ("arm64: add endianness option to LDFLAGS instead of LD")
>   96f95a17c1cf ("Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"")
> 
> from Linus' tree and commit:
> 
>   c931d34ea085 ("arm64: build with baremetal linker target instead of Linux when available")
> 
> from the arm64 tree.
> 
> I fixed it up (I just used the latter version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Thanks; that is the correct resolution.

Will

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/fpsimd.c

between commit:

  a45448313706 ("arm64: fpsimd: Fix copying of FP state from signal frame into task struct")

from Linus' tree and commit:

  0abdeff598a6 ("arm64: fpsimd: Fix state leakage when migrating after sigreturn")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/cpufeature.c

between commit:

  3fab39997a98 ("arm64/sve: Report SVE to userspace via CPUID only if supported")

from Linus' tree and commit:

  64c02720ea35 ("arm64: cpufeature: Detect CPU RAS Extentions")

from the arm64 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/cpufeature.c
index a73a5928f09b,5612d6f46331..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -145,8 -146,10 +146,11 @@@ static const struct arm64_ftr_bits ftr_
  };
  
  static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
+ 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
+ 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
 -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
 +	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
 +				   FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
+ 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_RAS_SHIFT, 4, 0),
  	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
  	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
  	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/include/asm/cputype.h

between commit:

  c622cc013cec ("arm64: Define cputype macros for Falkor CPU")

from Linus' tree and commit:

  bb48711800e6 ("arm64: cpu_errata: Add Kryo to Falkor 1003 errata")

from the arm64 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/cputype.h
index cbf08d7cbf30,2f8d39ed9c2e..000000000000
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@@ -91,7 -94,7 +94,8 @@@
  #define BRCM_CPU_PART_VULCAN		0x516
  
  #define QCOM_CPU_PART_FALKOR_V1		0x800
+ #define QCOM_CPU_PART_KRYO		0x200
 +#define QCOM_CPU_PART_FALKOR		0xC00
  
  #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
  #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
@@@ -99,8 -104,10 +105,11 @@@
  #define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
  #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
  #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
+ #define MIDR_CAVIUM_THUNDERX2 MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX2)
+ #define MIDR_BRCM_VULCAN MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN)
  #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
+ #define MIDR_QCOM_KRYO MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_KRYO)
 +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
  
  #ifndef __ASSEMBLY__
  

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

[Catalin Marinas]

On Mon, Jan 15, 2018 at 08:32:14AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/cputype.h
> index cbf08d7cbf30,2f8d39ed9c2e..000000000000
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@@ -91,7 -94,7 +94,8 @@@
>   #define BRCM_CPU_PART_VULCAN		0x516
>   
>   #define QCOM_CPU_PART_FALKOR_V1		0x800
> + #define QCOM_CPU_PART_KRYO		0x200
>  +#define QCOM_CPU_PART_FALKOR		0xC00
>   
>   #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
>   #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
> @@@ -99,8 -104,10 +105,11 @@@
>   #define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
>   #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
>   #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
> + #define MIDR_CAVIUM_THUNDERX2 MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX2)
> + #define MIDR_BRCM_VULCAN MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN)
>   #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
> + #define MIDR_QCOM_KRYO MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_KRYO)
>  +#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)

It looks fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/cpufeature.c

between commit:

  3fab39997a98 ("arm64/sve: Report SVE to userspace via CPUID only if supported")

from Linus' tree and commits:

  179a56f6f9fb ("arm64: Take into account ID_AA64PFR0_EL1.CSV3")
  0f15adbb2861 ("arm64: Add skeleton to harden the branch predictor against aliasing attacks")

from the arm64 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/cpufeature.c
index a73a5928f09b,da6722db50b0..000000000000
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@@ -145,8 -146,9 +146,10 @@@ static const struct arm64_ftr_bits ftr_
  };
  
  static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
+ 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
+ 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
 -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
 +	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
 +				   FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
  	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
  	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
  	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),

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

[Catalin Marinas]

On Fri, Jan 12, 2018 at 08:23:59AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/kernel/cpufeature.c
> index a73a5928f09b,da6722db50b0..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -145,8 -146,9 +146,10 @@@ static const struct arm64_ftr_bits ftr_
>   };
>   
>   static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> + 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> + 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
>  -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
>  +	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
>  +				   FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
>   	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
>   	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
>   	S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),

It looks fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

Hi Catalin,

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

  drivers/acpi/arm64/iort.c

between commit:

  37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")

from Linus' tree and commit:

  896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")

from the arm64 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/arm64/iort.c
index de56394dd161,7dc964f4d8f1..000000000000
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
  	struct acpi_table_iort *iort;
  	struct fwnode_handle *fwnode;
  	int i, ret;
 +	bool acs_enabled = false;
+ 	const struct iort_dev_config *ops;
  
  	/*
  	 * iort_table and iort both point to the start of IORT table, but
@@@ -1235,12 -1346,8 +1378,11 @@@
  			return;
  		}
  
 +		if (!acs_enabled)
 +			acs_enabled = iort_enable_acs(iort_node);
 +
- 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
- 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
- 
+ 		ops = iort_get_dev_cfg(iort_node);
+ 		if (ops) {
  			fwnode = acpi_alloc_fwnode_static();
  			if (!fwnode)
  				return;

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

[Stephen Rothwell]

Hi all,

On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   drivers/acpi/arm64/iort.c
> 
> between commit:
> 
>   37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
> 
> from Linus' tree and commit:
> 
>   896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> 
> from the arm64 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/arm64/iort.c
> index de56394dd161,7dc964f4d8f1..000000000000
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
>   	struct acpi_table_iort *iort;
>   	struct fwnode_handle *fwnode;
>   	int i, ret;
>  +	bool acs_enabled = false;
> + 	const struct iort_dev_config *ops;
>   
>   	/*
>   	 * iort_table and iort both point to the start of IORT table, but
> @@@ -1235,12 -1346,8 +1378,11 @@@
>   			return;
>   		}
>   
>  +		if (!acs_enabled)
>  +			acs_enabled = iort_enable_acs(iort_node);
>  +
> - 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> - 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> - 
> + 		ops = iort_get_dev_cfg(iort_node);
> + 		if (ops) {
>   			fwnode = acpi_alloc_fwnode_static();
>   			if (!fwnode)
>   				return;

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

[Catalin Marinas]

Hi Stephen,

On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote:
> On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Today's linux-next merge of the arm64 tree got a conflict in:
> > 
> >   drivers/acpi/arm64/iort.c
> > 
> > between commit:
> > 
> >   37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
> > 
> > from Linus' tree and commit:
> > 
> >   896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> > 
> > from the arm64 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 drivers/acpi/arm64/iort.c
> > index de56394dd161,7dc964f4d8f1..000000000000
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
> >   	struct acpi_table_iort *iort;
> >   	struct fwnode_handle *fwnode;
> >   	int i, ret;
> >  +	bool acs_enabled = false;
> > + 	const struct iort_dev_config *ops;
> >   
> >   	/*
> >   	 * iort_table and iort both point to the start of IORT table, but
> > @@@ -1235,12 -1346,8 +1378,11 @@@
> >   			return;
> >   		}
> >   
> >  +		if (!acs_enabled)
> >  +			acs_enabled = iort_enable_acs(iort_node);
> >  +
> > - 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> > - 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> > - 
> > + 		ops = iort_get_dev_cfg(iort_node);
> > + 		if (ops) {
> >   			fwnode = acpi_alloc_fwnode_static();
> >   			if (!fwnode)
> >   				return;
> 
> Just a reminder that this conflict still exists.

Thanks for the reminder. Will (cc'ed) is handling this merging window
and AFAIK the pull request will go with this conflict unsolved (to avoid
a back merge from a newer Linus tree commit).

-- 
Catalin

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

[Lorenzo Pieralisi]

On Mon, Nov 13, 2017 at 09:15:08AM +0000, Catalin Marinas wrote:
> Hi Stephen,
> 
> On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote:
> > On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Today's linux-next merge of the arm64 tree got a conflict in:
> > > 
> > >   drivers/acpi/arm64/iort.c
> > > 
> > > between commit:
> > > 
> > >   37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
> > > 
> > > from Linus' tree and commit:
> > > 
> > >   896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> > > 
> > > from the arm64 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 drivers/acpi/arm64/iort.c
> > > index de56394dd161,7dc964f4d8f1..000000000000
> > > --- a/drivers/acpi/arm64/iort.c
> > > +++ b/drivers/acpi/arm64/iort.c
> > > @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
> > >   	struct acpi_table_iort *iort;
> > >   	struct fwnode_handle *fwnode;
> > >   	int i, ret;
> > >  +	bool acs_enabled = false;
> > > + 	const struct iort_dev_config *ops;
> > >   
> > >   	/*
> > >   	 * iort_table and iort both point to the start of IORT table, but
> > > @@@ -1235,12 -1346,8 +1378,11 @@@
> > >   			return;
> > >   		}
> > >   
> > >  +		if (!acs_enabled)
> > >  +			acs_enabled = iort_enable_acs(iort_node);
> > >  +
> > > - 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> > > - 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> > > - 
> > > + 		ops = iort_get_dev_cfg(iort_node);
> > > + 		if (ops) {
> > >   			fwnode = acpi_alloc_fwnode_static();
> > >   			if (!fwnode)
> > >   				return;
> > 
> > Just a reminder that this conflict still exists.
> 
> Thanks for the reminder. Will (cc'ed) is handling this merging window
> and AFAIK the pull request will go with this conflict unsolved (to avoid
> a back merge from a newer Linus tree commit).

Indeed, that's the planned course of action, thanks for the heads-up.

Lorenzo

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

[Mark Brown]

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

Hi Catalin,

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

  drivers/acpi/arm64/iort.c

between commit:

  37f6b42e9c296 ("ACPI/IORT: Fix PCI ACS enablement")

from Linus' tree and commit:

  896dd2c324842 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")

from the arm64 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 drivers/acpi/arm64/iort.c
index de56394dd161,7dc964f4d8f1..000000000000
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
  	struct acpi_table_iort *iort;
  	struct fwnode_handle *fwnode;
  	int i, ret;
 +	bool acs_enabled = false;
+ 	const struct iort_dev_config *ops;
  
  	/*
  	 * iort_table and iort both point to the start of IORT table, but
@@@ -1235,12 -1346,8 +1378,11 @@@
  			return;
  		}
  
 +		if (!acs_enabled)
 +			acs_enabled = iort_enable_acs(iort_node);
 +
- 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
- 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
- 
+ 		ops = iort_get_dev_cfg(iort_node);
+ 		if (ops) {
  			fwnode = acpi_alloc_fwnode_static();
  			if (!fwnode)
  				return;

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

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

[Lorenzo Pieralisi]

[+Will]

On Thu, Oct 19, 2017 at 12:28:33PM +0100, Mark Brown wrote:
> Hi Catalin,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   drivers/acpi/arm64/iort.c
> 
> between commit:
> 
>   37f6b42e9c296 ("ACPI/IORT: Fix PCI ACS enablement")
> 
> from Linus' tree and commit:
> 
>   896dd2c324842 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> 
> from the arm64 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 drivers/acpi/arm64/iort.c
> index de56394dd161,7dc964f4d8f1..000000000000
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
>   	struct acpi_table_iort *iort;
>   	struct fwnode_handle *fwnode;
>   	int i, ret;
>  +	bool acs_enabled = false;
> + 	const struct iort_dev_config *ops;
>   
>   	/*
>   	 * iort_table and iort both point to the start of IORT table, but
> @@@ -1235,12 -1346,8 +1378,11 @@@
>   			return;
>   		}
>   
>  +		if (!acs_enabled)
>  +			acs_enabled = iort_enable_acs(iort_node);
>  +
> - 		if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> - 			(iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> - 
> + 		ops = iort_get_dev_cfg(iort_node);
> + 		if (ops) {
>   			fwnode = acpi_alloc_fwnode_static();
>   			if (!fwnode)
>   				return;

Hi Mark,

it is expected and that's the right conflict resolution:

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

Thank you,
Lorenzo

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/include/asm/cpufeature.h

between commit:

  272d01bd790f ("arm64: Fix circular include of asm/lse.h through linux/jump_label.h")

from Linus' tree and commits:

  a4023f682739 ("arm64: Add hypervisor safe helper for checking constant capabilities")
  82e0191a1aa1 ("arm64: Support systems without FP/ASIMD")

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

I also added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Nov 2016 10:30:40 +1100
Subject: [PATCH] arm64: merge fix for code movement to cpucaps.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm64/include/asm/cpucaps.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 87b446535185..4174f09678c4 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -34,7 +34,8 @@
 #define ARM64_HAS_32BIT_EL0			13
 #define ARM64_HYP_OFFSET_LOW			14
 #define ARM64_MISMATCHED_CACHE_LINE_SIZE	15
+#define ARM64_HAS_NO_FPSIMD			16
 
-#define ARM64_NCAPS				16
+#define ARM64_NCAPS				17
 
 #endif /* __ASM_CPUCAPS_H */
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cpufeature.h
index 0bc0b1de90c4,0ef718b67c54..000000000000
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -9,9 -9,6 +9,7 @@@
  #ifndef __ASM_CPUFEATURE_H
  #define __ASM_CPUFEATURE_H
  
- #include <linux/jump_label.h>
- 
 +#include <asm/cpucaps.h>
  #include <asm/hwcap.h>
  #include <asm/sysreg.h>
  
@@@ -25,8 -22,34 +23,10 @@@
  #define MAX_CPU_FEATURES	(8 * sizeof(elf_hwcap))
  #define cpu_feature(x)		ilog2(HWCAP_ ## x)
  
 -#define ARM64_WORKAROUND_CLEAN_CACHE		0
 -#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE	1
 -#define ARM64_WORKAROUND_845719			2
 -#define ARM64_HAS_SYSREG_GIC_CPUIF		3
 -#define ARM64_HAS_PAN				4
 -#define ARM64_HAS_LSE_ATOMICS			5
 -#define ARM64_WORKAROUND_CAVIUM_23154		6
 -#define ARM64_WORKAROUND_834220			7
 -#define ARM64_HAS_NO_HW_PREFETCH		8
 -#define ARM64_HAS_UAO				9
 -#define ARM64_ALT_PAN_NOT_UAO			10
 -#define ARM64_HAS_VIRT_HOST_EXTN		11
 -#define ARM64_WORKAROUND_CAVIUM_27456		12
 -#define ARM64_HAS_32BIT_EL0			13
 -#define ARM64_HYP_OFFSET_LOW			14
 -#define ARM64_MISMATCHED_CACHE_LINE_SIZE	15
 -/*
 - * The macro below will be moved to asm/cpucaps.h together with the
 - * ARM64_NCAPS update.
 - */
 -#define ARM64_HAS_NO_FPSIMD			16
 -
 -#define ARM64_NCAPS				17
 -
  #ifndef __ASSEMBLY__
  
+ #include <linux/bug.h>
+ #include <linux/jump_label.h>
  #include <linux/kernel.h>
  
  /* CPU feature register tracking */

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

[Catalin Marinas]

Hi Stephen,

On Tue, Nov 22, 2016 at 10:34:58AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/include/asm/cpufeature.h
> 
> between commit:
> 
>   272d01bd790f ("arm64: Fix circular include of asm/lse.h through linux/jump_label.h")
> 
> from Linus' tree and commits:
> 
>   a4023f682739 ("arm64: Add hypervisor safe helper for checking constant capabilities")
>   82e0191a1aa1 ("arm64: Support systems without FP/ASIMD")
> 
> from the arm64 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.

The merge resolution and additional patch look fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

Hi Catalin,

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

  drivers/perf/arm_pmu.c

between commit:

  63fb0a9516b2 ("drivers/perf: arm_pmu: Fix NULL pointer dereference during probe")

from Linus' tree and commit:

  282b87963556 ("drivers/perf: arm_pmu: Always consider IRQ0 as an error")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/head.S

between commit:

  fd363bd417dd ("arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE")

from Linus' tree and commit:

  3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/mm/fault.c

between commit:

  e19a6ee2460b ("arm64: kernel: Save and restore UAO and addr_limit on exception entry")

from Linus' tree and commit:

  541ec870ef31 ("arm64: kill ESR_LNX_EXEC")

from the arm64 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/mm/fault.c
index b1166d1e5955,fc5a34a72c6d..000000000000
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@@ -279,9 -282,8 +282,9 @@@ static int __kprobes do_page_fault(unsi
  		mm_flags |= FAULT_FLAG_WRITE;
  	}
  
- 	if (permission_fault(esr) && (addr < USER_DS)) {
+ 	if (is_permission_fault(esr) && (addr < USER_DS)) {
 -		if (get_fs() == KERNEL_DS)
 +		/* regs->orig_addr_limit may be 0 if we entered from EL0 */
 +		if (regs->orig_addr_limit == KERNEL_DS)
  			die("Accessing user space memory with fs=KERNEL_DS", regs, esr);
  
  		if (!search_exception_tables(regs->pc))

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm/kvm/arm.c

between commit:

  06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")

from Linus' tree and commit:

  67f691976662 ("arm64: kvm: allows kvm cpu hotplug")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/kvm/arm.c
index dded1b763c16,1687e1450c3a..000000000000
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@@ -1198,8 -1226,6 +1233,7 @@@ static void teardown_hyp_mode(void
  	free_hyp_pgds();
  	for_each_possible_cpu(cpu)
  		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
- 	unregister_cpu_notifier(&hyp_init_cpu_nb);
 +	hyp_cpu_pm_exit();
  }
  
  static int init_vhe_mode(void)

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

[Will Deacon]

On Fri, Apr 29, 2016 at 09:59:58AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm/kvm/arm.c
> 
> between commit:
> 
>   06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
> 
> from Linus' tree and commit:
> 
>   67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
> 
> from the arm64 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm/kvm/arm.c
> index dded1b763c16,1687e1450c3a..000000000000
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@@ -1198,8 -1226,6 +1233,7 @@@ static void teardown_hyp_mode(void
>   	free_hyp_pgds();
>   	for_each_possible_cpu(cpu)
>   		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> - 	unregister_cpu_notifier(&hyp_init_cpu_nb);
>  +	hyp_cpu_pm_exit();
>   }
>   
>   static int init_vhe_mode(void)

Thanks Stephen, this looks good to me.

Will

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/mm/init.c

between commit:

  dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region")

from Linus' tree and commit:

  f09f1bacfe2b ("arm64: Split pr_notice("Virtual kernel memory layout...") into multiple pr_cont()")

from the arm64 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/mm/init.c
index 61a38eaf0895,d09603d0e5e9..000000000000
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@@ -362,42 -362,38 +362,38 @@@ void __init mem_init(void
  #define MLG(b, t) b, t, ((t) - (b)) >> 30
  #define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
  
- 	pr_notice("Virtual kernel memory layout:\n"
+ 	pr_notice("Virtual kernel memory layout:\n");
  #ifdef CONFIG_KASAN
- 		  "    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n"
+ 	pr_cont("    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n",
+ 		MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
  #endif
- 		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
- 		  "    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n"
- 		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
- 		  "    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
- 		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
- 		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+ 	pr_cont("    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+ 		MLM(MODULES_VADDR, MODULES_END));
+ 	pr_cont("    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n",
+ 		MLG(VMALLOC_START, VMALLOC_END));
+ 	pr_cont("      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+ 		"    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+ 		"      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+ 		"      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
+ 		MLK_ROUNDUP(_text, __start_rodata),
+ 		MLK_ROUNDUP(__start_rodata, _etext),
+ 		MLK_ROUNDUP(__init_begin, __init_end),
+ 		MLK_ROUNDUP(_sdata, _edata));
  #ifdef CONFIG_SPARSEMEM_VMEMMAP
- 		  "    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n"
- 		  "              0x%16lx - 0x%16lx   (%6ld MB actual)\n"
+ 	pr_cont("    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n"
+ 		"              0x%16lx - 0x%16lx   (%6ld MB actual)\n",
 -		MLG((unsigned long)vmemmap,
 -		    (unsigned long)vmemmap + VMEMMAP_SIZE),
++		MLG(VMEMMAP_START,
++		    VMEMMAP_START + VMEMMAP_SIZE),
+ 		MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
+ 		    (unsigned long)virt_to_page(high_memory)));
  #endif
- 		  "    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n"
- 		  "    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n"
- 		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
- #ifdef CONFIG_KASAN
- 		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
- #endif
- 		  MLM(MODULES_VADDR, MODULES_END),
- 		  MLG(VMALLOC_START, VMALLOC_END),
- 		  MLK_ROUNDUP(_text, __start_rodata),
- 		  MLK_ROUNDUP(__start_rodata, _etext),
- 		  MLK_ROUNDUP(__init_begin, __init_end),
- 		  MLK_ROUNDUP(_sdata, _edata),
- #ifdef CONFIG_SPARSEMEM_VMEMMAP
- 		  MLG(VMEMMAP_START,
- 		      VMEMMAP_START + VMEMMAP_SIZE),
- 		  MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
- 		      (unsigned long)virt_to_page(high_memory)),
- #endif
- 		  MLK(FIXADDR_START, FIXADDR_TOP),
- 		  MLM(PCI_IO_START, PCI_IO_END),
- 		  MLM(__phys_to_virt(memblock_start_of_DRAM()),
- 		      (unsigned long)high_memory));
+ 	pr_cont("    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n",
+ 		MLK(FIXADDR_START, FIXADDR_TOP));
+ 	pr_cont("    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+ 		MLM(PCI_IO_START, PCI_IO_END));
+ 	pr_cont("    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+ 		MLM(__phys_to_virt(memblock_start_of_DRAM()),
+ 		    (unsigned long)high_memory));
  
  #undef MLK
  #undef MLM

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

[Catalin Marinas]

On Tue, Mar 22, 2016 at 10:15:49AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/mm/init.c
> 
> between commit:
> 
>   dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region")
> 
> from Linus' tree and commit:
> 
>   f09f1bacfe2b ("arm64: Split pr_notice("Virtual kernel memory layout...") into multiple pr_cont()")
> 
> from the arm64 tree.

The fix looks fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/mm/init.c

between commit:

  dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region")

from Linus' tree and commit:

  c031a4213c11 ("arm64: kaslr: randomize the linear region")

from the arm64 tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/init.c
index 7802f216a67a,8c3d7dd91c25..000000000000
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@@ -317,11 -382,16 +382,16 @@@ void __init mem_init(void
  #ifdef CONFIG_KASAN
  		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
  #endif
+ 		  MLM(MODULES_VADDR, MODULES_END),
  		  MLG(VMALLOC_START, VMALLOC_END),
+ 		  MLK_ROUNDUP(_text, __start_rodata),
+ 		  MLK_ROUNDUP(__start_rodata, _etext),
+ 		  MLK_ROUNDUP(__init_begin, __init_end),
+ 		  MLK_ROUNDUP(_sdata, _edata),
  #ifdef CONFIG_SPARSEMEM_VMEMMAP
 -		  MLG((unsigned long)vmemmap,
 -		      (unsigned long)vmemmap + VMEMMAP_SIZE),
 +		  MLG(VMEMMAP_START,
 +		      VMEMMAP_START + VMEMMAP_SIZE),
- 		  MLM((unsigned long)virt_to_page(PAGE_OFFSET),
+ 		  MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
  		      (unsigned long)virt_to_page(high_memory)),
  #endif
  		  MLK(FIXADDR_START, FIXADDR_TOP),

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

[Stephen Rothwell]

Hi Catalin,

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

  arch/arm64/kernel/suspend.c

between commit:

  e13d918a19a7 ("arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap")

from Linus' tree and commit:

  8e63d3887669 ("arm64: flush: use local TLB and I-cache invalidation")

from the arm64 tree.

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

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

diff --cc arch/arm64/kernel/suspend.c
index 44ca4143b013,3c5e4e6dcf68..000000000000
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@@ -80,21 -80,17 +80,21 @@@ int cpu_suspend(unsigned long arg, int 
  	if (ret == 0) {
  		/*
  		 * We are resuming from reset with TTBR0_EL1 set to the
 -		 * idmap to enable the MMU; restore the active_mm mappings in
 -		 * TTBR0_EL1 unless the active_mm == &init_mm, in which case
 -		 * the thread entered cpu_suspend with TTBR0_EL1 set to
 -		 * reserved TTBR0 page tables and should be restored as such.
 +		 * idmap to enable the MMU; set the TTBR0 to the reserved
 +		 * page tables to prevent speculative TLB allocations, flush
 +		 * the local tlb and set the default tcr_el1.t0sz so that
 +		 * the TTBR0 address space set-up is properly restored.
 +		 * If the current active_mm != &init_mm we entered cpu_suspend
 +		 * with mappings in TTBR0 that must be restored, so we switch
 +		 * them back to complete the address space configuration
 +		 * restoration before returning.
  		 */
 -		if (mm == &init_mm)
 -			cpu_set_reserved_ttbr0();
 -		else
 -			cpu_switch_mm(mm->pgd, mm);
 -
 +		cpu_set_reserved_ttbr0();
- 		flush_tlb_all();
+ 		local_flush_tlb_all();
 +		cpu_set_default_tcr_t0sz();
 +
 +		if (mm != &init_mm)
 +			cpu_switch_mm(mm->pgd, mm);
  
  		/*
  		 * Restore per-cpu offset before any kernel

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

[Catalin Marinas]

On Sun, Nov 01, 2015 at 10:53:27AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/suspend.c
> 
> between commit:
> 
>   e13d918a19a7 ("arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap")
> 
> from Linus' tree and commit:
> 
>   8e63d3887669 ("arm64: flush: use local TLB and I-cache invalidation")
> 
> from the arm64 tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

The fix-up is fine. Thanks.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in
arch/arm64/mm/dump.c between commit 284be28565ef ("arm64: dump: Fix
implicit inclusion of definition for PCI_IOBASE") from Linus' tree and
commit 764011ca8247 ("arm64: mm: dump: add missing includes") from the
arm64 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/mm/dump.c
index d54dc9ac4b70,bbc5a29ecaaf..000000000000
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@@ -14,8 -14,9 +14,10 @@@
   * of the License.
   */
  #include <linux/debugfs.h>
+ #include <linux/errno.h>
  #include <linux/fs.h>
+ #include <linux/init.h>
 +#include <linux/io.h>
  #include <linux/mm.h>
  #include <linux/sched.h>
  #include <linux/seq_file.h>

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

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

[Stephen Rothwell]

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

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in
include/uapi/linux/kvm.h between commit 2a8fedd0c142 ("kvm: Add
definition of KVM_REG_MIPS") from Linus' tree and commit 7c8c5e6a9101
("arm64: KVM: system register handling") from the arm64 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 include/uapi/linux/kvm.h
index d88c8ee,aac2764..0000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -783,7 -784,7 +784,8 @@@ struct kvm_dirty_tlb 
  #define KVM_REG_IA64		0x3000000000000000ULL
  #define KVM_REG_ARM		0x4000000000000000ULL
  #define KVM_REG_S390		0x5000000000000000ULL
+ #define KVM_REG_ARM64		0x6000000000000000ULL
 +#define KVM_REG_MIPS		0x7000000000000000ULL
  
  #define KVM_REG_SIZE_SHIFT	52
  #define KVM_REG_SIZE_MASK	0x00f0000000000000ULL

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

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

[Stephen Rothwell]

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

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in
arch/arm64/include/asm/unistd32.h between commit 9d73fc2d641f ("open*(2)
compat fixes (s390, arm64)") from Linus' tree and commit 18a80376ddb0
("arm64: compat for clock_adjtime(2) is miswired") from the arm64 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/unistd32.h
index 656a6f2,e067f9d..0000000
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@@ -392,8 -392,8 +392,8 @@@ __SYSCALL(367, sys_fanotify_init
  __SYSCALL(368, compat_sys_fanotify_mark_wrapper)
  __SYSCALL(369, sys_prlimit64)
  __SYSCALL(370, sys_name_to_handle_at)
 -__SYSCALL(371, sys_open_by_handle_at)
 +__SYSCALL(371, compat_sys_open_by_handle_at)
- __SYSCALL(372, sys_clock_adjtime)
+ __SYSCALL(372, compat_sys_clock_adjtime)
  __SYSCALL(373, sys_syncfs)
  
  #define __NR_compat_syscalls		374

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