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..
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@@ -66,8 -66,8 +66,9 @@@
>   #define ARM64_WORKAROUND_150841258
>   #define ARM64_HAS_LDAPR 59
>   #define ARM64_KVM_PROTECTED_MODE60
>  -#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]

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..
--- 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_EPAN61
 +#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP61
++#define ARM64_HAS_EPAN62
  
--#define ARM64_NCAPS   62
++#define ARM64_NCAPS   63
  
  #endif /* __ASM_CPUCAPS_H */


pgpitfF7yrPg6.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgpPPfbgDgFbx.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgp66ncJSYMLQ.pgp
Description: OpenPGP digital signature

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]

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


pgpVAtkuNmpBM.pgp
Description: OpenPGP digital signature

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

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

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

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

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

[Stephen Rothwell]

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


pgp8QGpQFHTST.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgp8QGpQFHTST.pgp
Description: OpenPGP digital signature

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

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


pgpvHpRT0yEyw.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgpvHpRT0yEyw.pgp
Description: OpenPGP digital signature

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

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..
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@@ -91,7 -94,7 +94,8 @@@
>   #define BRCM_CPU_PART_VULCAN0x516
>   
>   #define QCOM_CPU_PART_FALKOR_V1 0x800
> + #define QCOM_CPU_PART_KRYO  0x200
>  +#define QCOM_CPU_PART_FALKOR0xC00
>   
>   #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

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..
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@@ -91,7 -94,7 +94,8 @@@
>   #define BRCM_CPU_PART_VULCAN0x516
>   
>   #define QCOM_CPU_PART_FALKOR_V1 0x800
> + #define QCOM_CPU_PART_KRYO  0x200
>  +#define QCOM_CPU_PART_FALKOR0xC00
>   
>   #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/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..
--- 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_KRYO0x200
 +#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__
  

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..
--- 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_KRYO0x200
 +#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 Fri, Jan 12, 2018 at 08:23:59AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/kernel/cpufeature.c
> index a73a5928f09b,da6722db50b0..
> --- 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

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

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

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

[Lorenzo Pieralisi]

On Mon, Nov 13, 2017 at 09:15:08AM +, 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  
> > 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..
> > > --- 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

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

[Lorenzo Pieralisi]

On Mon, Nov 13, 2017 at 09:15:08AM +, 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  
> > 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..
> > > --- 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

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

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

[Stephen Rothwell]

Hi all,

On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell  
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..
> --- 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

[Stephen Rothwell]

Hi all,

On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell  
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..
> --- 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

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

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

[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..
> --- 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=150817031118241=2

Thank you,
Lorenzo

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..
> --- 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=150817031118241=2

Thank you,
Lorenzo

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

[Mark Brown]

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


signature.asc
Description: PGP signature

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

[Mark Brown]

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


signature.asc
Description: PGP signature

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

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

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

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

[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

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:

  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 
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 
---
 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_EL013
 #define ARM64_HYP_OFFSET_LOW   14
 #define ARM64_MISMATCHED_CACHE_LINE_SIZE   15
+#define ARM64_HAS_NO_FPSIMD16
 
-#define ARM64_NCAPS16
+#define ARM64_NCAPS17
 
 #endif /* __ASM_CPUCAPS_H */
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cpufeature.h
index 0bc0b1de90c4,0ef718b67c54..
--- 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 
- 
 +#include 
  #include 
  #include 
  
@@@ -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_CPUIF3
 -#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 
+ #include 
  #include 
  
  /* CPU feature register tracking */

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 
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 
---
 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_EL013
 #define ARM64_HYP_OFFSET_LOW   14
 #define ARM64_MISMATCHED_CACHE_LINE_SIZE   15
+#define ARM64_HAS_NO_FPSIMD16
 
-#define ARM64_NCAPS16
+#define ARM64_NCAPS17
 
 #endif /* __ASM_CPUCAPS_H */
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cpufeature.h
index 0bc0b1de90c4,0ef718b67c54..
--- 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 
- 
 +#include 
  #include 
  #include 
  
@@@ -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_CPUIF3
 -#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 
+ #include 
  #include 
  
  /* CPU feature register tracking */

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:

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

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..
> --- 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(_init_cpu_nb);
>  +hyp_cpu_pm_exit();
>   }
>   
>   static int init_vhe_mode(void)

Thanks Stephen, this looks good to me.

Will

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..
> --- 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(_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/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..
--- 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(_init_cpu_nb);
 +  hyp_cpu_pm_exit();
  }
  
  static int init_vhe_mode(void)

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..
--- 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(_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

[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

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:

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

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

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

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

Re: linux-next: manual merge of the 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the 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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/kernel/suspend.c
index 44ca4143b013,3c5e4e6dcf68..
--- 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 == _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 != _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 == _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 != _mm)
 +  cpu_switch_mm(mm->pgd, mm);
  
/*
 * Restore per-cpu offset before any kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the 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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/kernel/suspend.c
index 44ca4143b013,3c5e4e6dcf68..
--- 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 == _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 != _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 == _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 != _mm)
 +  cpu_switch_mm(mm->pgd, mm);
  
/*
 * Restore per-cpu offset before any kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the 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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/mm/dump.c
index d54dc9ac4b70,bbc5a29ecaaf..
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@@ -14,8 -14,9 +14,10 @@@
   * of the License.
   */
  #include 
+ #include 
  #include 
+ #include 
 +#include 
  #include 
  #include 
  #include 


pgpLQyvpoYcYR.pgp
Description: OpenPGP digital signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/mm/dump.c
index d54dc9ac4b70,bbc5a29ecaaf..
--- 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


pgpLQyvpoYcYR.pgp
Description: OpenPGP digital signature

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

diff --cc include/uapi/linux/kvm.h
index d88c8ee,aac2764..000
--- 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  0x3000ULL
  #define KVM_REG_ARM   0x4000ULL
  #define KVM_REG_S390  0x5000ULL
+ #define KVM_REG_ARM64 0x6000ULL
 +#define KVM_REG_MIPS  0x7000ULL
  
  #define KVM_REG_SIZE_SHIFT52
  #define KVM_REG_SIZE_MASK 0x00f0ULL


pgpvkQPgL9J1F.pgp
Description: PGP signature

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

diff --cc include/uapi/linux/kvm.h
index d88c8ee,aac2764..000
--- 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  0x3000ULL
  #define KVM_REG_ARM   0x4000ULL
  #define KVM_REG_S390  0x5000ULL
+ #define KVM_REG_ARM64 0x6000ULL
 +#define KVM_REG_MIPS  0x7000ULL
  
  #define KVM_REG_SIZE_SHIFT52
  #define KVM_REG_SIZE_MASK 0x00f0ULL


pgpvkQPgL9J1F.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/include/asm/unistd32.h
index 656a6f2,e067f9d..000
--- 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


pgprZ3Y2eFKxA.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm64/include/asm/unistd32.h
index 656a6f2,e067f9d..000
--- 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


pgprZ3Y2eFKxA.pgp
Description: PGP signature