Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2019-10-27 21:39 Stephen Rothwell
  2019-10-28  8:39 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2019-10-27 21:39 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Marc Zyngier,
	James Morse

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2019-10-27 21:39 linux-next: manual merge of the arm64 tree with Linus' tree Stephen Rothwell
@ 2019-10-28  8:39 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2019-10-28  8:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Will Deacon, Linux Next Mailing List, Linux Kernel Mailing List,
	Marc Zyngier, James Morse

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2019-06-24 23:31 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2019-06-24 23:31 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Ard Biesheuvel, Rick Edgecombe, Ingo Molnar

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-12-10 21:52 Stephen Rothwell
@ 2018-12-11 10:16 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2018-12-11 10:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Will Deacon, Linux Next Mailing List, Linux Kernel Mailing List,
	Marc Zyngier

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-12-10 21:52 Stephen Rothwell
  2018-12-11 10:16 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2018-12-10 21:52 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Marc Zyngier

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-12-07 12:16 ` Will Deacon
@ 2018-12-07 14:27   ` Suzuki K Poulose
  0 siblings, 0 replies; 39+ messages in thread
From: Suzuki K Poulose @ 2018-12-07 14:27 UTC (permalink / raw)
  To: Will Deacon, Stephen Rothwell
  Cc: Catalin Marinas, Linux Next Mailing List, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-12-06 22:18 Stephen Rothwell
@ 2018-12-07 12:16 ` Will Deacon
  2018-12-07 14:27   ` Suzuki K Poulose
  0 siblings, 1 reply; 39+ messages in thread
From: Will Deacon @ 2018-12-07 12:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Catalin Marinas, Linux Next Mailing List,
	Linux Kernel Mailing List, Suzuki K Poulose

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-12-06 22:18 Stephen Rothwell
  2018-12-07 12:16 ` Will Deacon
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2018-12-06 22:18 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Suzuki K Poulose

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-07-23 22:50 Stephen Rothwell
@ 2018-07-24  9:29 ` Will Deacon
  0 siblings, 0 replies; 39+ messages in thread
From: Will Deacon @ 2018-07-24  9:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Catalin Marinas, Linux-Next Mailing List,
	Linux Kernel Mailing List, Olof Johansson, Paul Kocialkowski,
	Laura Abbott, Greg Hackmann, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-07-23 22:50 Stephen Rothwell
  2018-07-24  9:29 ` Will Deacon
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2018-07-23 22:50 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Olof Johansson, Paul Kocialkowski, Laura Abbott, Greg Hackmann,
	Masahiro Yamada

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-01-16 22:30 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2018-01-16 22:30 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Will Deacon,
	Dave Martin

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-01-16 22:25 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2018-01-16 22:25 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin,
	Will Deacon, Xie XiuQi, James Morse

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),

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-01-14 21:32 Stephen Rothwell
@ 2018-01-14 21:40 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2018-01-14 21:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Shanker Donthineni, Will Deacon, Stephen Boyd

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-01-14 21:32 Stephen Rothwell
  2018-01-14 21:40 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2018-01-14 21:32 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Shanker Donthineni, Will Deacon, Stephen Boyd

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__
  

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2018-01-11 21:23 Stephen Rothwell
@ 2018-01-12 12:25 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2018-01-12 12:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin,
	Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2018-01-11 21:23 Stephen Rothwell
  2018-01-12 12:25 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2018-01-11 21:23 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin,
	Will Deacon

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),

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2017-11-13  9:15   ` Catalin Marinas
@ 2017-11-13 10:38     ` Lorenzo Pieralisi
  0 siblings, 0 replies; 39+ messages in thread
From: Lorenzo Pieralisi @ 2017-11-13 10:38 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2017-11-13  6:09 ` Stephen Rothwell
@ 2017-11-13  9:15   ` Catalin Marinas
  2017-11-13 10:38     ` Lorenzo Pieralisi
  0 siblings, 1 reply; 39+ messages in thread
From: Catalin Marinas @ 2017-11-13  9:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Lorenzo Pieralisi, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2017-10-31 20:57 Stephen Rothwell
@ 2017-11-13  6:09 ` Stephen Rothwell
  2017-11-13  9:15   ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2017-11-13  6:09 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Lorenzo Pieralisi

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2017-10-31 20:57 Stephen Rothwell
  2017-11-13  6:09 ` Stephen Rothwell
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2017-10-31 20:57 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Lorenzo Pieralisi

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;

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2017-10-19 11:28 Mark Brown
@ 2017-10-19 12:50 ` Lorenzo Pieralisi
  0 siblings, 0 replies; 39+ messages in thread
From: Lorenzo Pieralisi @ 2017-10-19 12:50 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Hanjun Guo, Robin Murphy, Nate Watterson,
	linux-arm-kernel, Linux-Next Mailing List,
	Linux Kernel Mailing List, will.deacon

[+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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2017-10-19 11:28 Mark Brown
  2017-10-19 12:50 ` Lorenzo Pieralisi
  0 siblings, 1 reply; 39+ messages in thread
From: Mark Brown @ 2017-10-19 11:28 UTC (permalink / raw)
  To: Catalin Marinas, Lorenzo Pieralisi, Hanjun Guo, Robin Murphy,
	Nate Watterson
  Cc: linux-arm-kernel, Linux-Next Mailing List, Linux Kernel Mailing List

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2017-08-23 23:22 Stephen Rothwell
@ 2017-09-04  5:59 ` Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2017-09-04  5:59 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin,
	Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2017-08-23 23:22 Stephen Rothwell
  2017-09-04  5:59 ` Stephen Rothwell
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2017-08-23 23:22 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Martin,
	Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2016-11-21 23:34 Stephen Rothwell
@ 2016-11-22 13:31 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2016-11-22 13:31 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Will Deacon, Suzuki K Poulose

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-11-21 23:34 Stephen Rothwell
  2016-11-22 13:31 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2016-11-21 23:34 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next, linux-kernel, Will Deacon, Suzuki K Poulose

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 */

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-09-11 23:17 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2016-09-11 23:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, Stefan Wahren, Marc Zyngier, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-09-05  1:27 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2016-09-05  1:27 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, Mark Rutland, Ard Biesheuvel, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-07-11  0:14 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2016-07-11  0:14 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, James Morse, Will Deacon, Mark Rutland

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))

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2016-04-28 23:59 Stephen Rothwell
@ 2016-04-29  8:49 ` Will Deacon
  0 siblings, 0 replies; 39+ messages in thread
From: Will Deacon @ 2016-04-29  8:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Catalin Marinas, linux-next, linux-kernel, Sudeep Holla,
	Christoffer Dall, AKASHI Takahiro, james.morse

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-04-28 23:59 Stephen Rothwell
  2016-04-29  8:49 ` Will Deacon
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2016-04-28 23:59 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, Sudeep Holla, Christoffer Dall,
	AKASHI Takahiro, Will Deacon

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)

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2016-03-21 23:15 Stephen Rothwell
@ 2016-03-23 11:14 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2016-03-23 11:14 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ard Biesheuvel, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-03-21 23:15 Stephen Rothwell
  2016-03-23 11:14 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2016-03-21 23:15 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next, linux-kernel, Ard Biesheuvel, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2016-03-06 23:48 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2016-03-06 23:48 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next, linux-kernel, Ard Biesheuvel, Will Deacon

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),

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: linux-next: manual merge of the arm64 tree with Linus' tree
  2015-10-31 23:53 Stephen Rothwell
@ 2015-11-02 10:39 ` Catalin Marinas
  0 siblings, 0 replies; 39+ messages in thread
From: Catalin Marinas @ 2015-11-02 10:39 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Lorenzo Pieralisi, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2015-10-31 23:53 Stephen Rothwell
  2015-11-02 10:39 ` Catalin Marinas
  0 siblings, 1 reply; 39+ messages in thread
From: Stephen Rothwell @ 2015-10-31 23:53 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next, linux-kernel, Lorenzo Pieralisi, Will Deacon

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2015-01-26 23:45 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2015-01-26 23:45 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, Mark Brown, Will Deacon, Mark Rutland

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2013-06-17  0:37 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2013-06-17  0:37 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-next, linux-kernel, David Daney, Gleb Natapov, Marc Zyngier

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

* linux-next: manual merge of the arm64 tree with Linus' tree
@ 2012-12-05 23:17 Stephen Rothwell
  0 siblings, 0 replies; 39+ messages in thread
From: Stephen Rothwell @ 2012-12-05 23:17 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next, linux-kernel, Al Viro

[-- 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 --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, back to index

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-27 21:39 linux-next: manual merge of the arm64 tree with Linus' tree Stephen Rothwell
2019-10-28  8:39 ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2019-06-24 23:31 Stephen Rothwell
2018-12-10 21:52 Stephen Rothwell
2018-12-11 10:16 ` Catalin Marinas
2018-12-06 22:18 Stephen Rothwell
2018-12-07 12:16 ` Will Deacon
2018-12-07 14:27   ` Suzuki K Poulose
2018-07-23 22:50 Stephen Rothwell
2018-07-24  9:29 ` Will Deacon
2018-01-16 22:30 Stephen Rothwell
2018-01-16 22:25 Stephen Rothwell
2018-01-14 21:32 Stephen Rothwell
2018-01-14 21:40 ` Catalin Marinas
2018-01-11 21:23 Stephen Rothwell
2018-01-12 12:25 ` Catalin Marinas
2017-10-31 20:57 Stephen Rothwell
2017-11-13  6:09 ` Stephen Rothwell
2017-11-13  9:15   ` Catalin Marinas
2017-11-13 10:38     ` Lorenzo Pieralisi
2017-10-19 11:28 Mark Brown
2017-10-19 12:50 ` Lorenzo Pieralisi
2017-08-23 23:22 Stephen Rothwell
2017-09-04  5:59 ` Stephen Rothwell
2016-11-21 23:34 Stephen Rothwell
2016-11-22 13:31 ` Catalin Marinas
2016-09-11 23:17 Stephen Rothwell
2016-09-05  1:27 Stephen Rothwell
2016-07-11  0:14 Stephen Rothwell
2016-04-28 23:59 Stephen Rothwell
2016-04-29  8:49 ` Will Deacon
2016-03-21 23:15 Stephen Rothwell
2016-03-23 11:14 ` Catalin Marinas
2016-03-06 23:48 Stephen Rothwell
2015-10-31 23:53 Stephen Rothwell
2015-11-02 10:39 ` Catalin Marinas
2015-01-26 23:45 Stephen Rothwell
2013-06-17  0:37 Stephen Rothwell
2012-12-05 23:17 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git