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

2021-03-29 Thread 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

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

2018-12-11 Thread 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

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

2018-12-07 Thread 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

2018-12-07 Thread 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

2018-12-07 Thread 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

2018-12-07 Thread 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

2018-07-24 Thread 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

2018-07-24 Thread 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

2018-01-14 Thread 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

2018-01-14 Thread 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

2018-01-12 Thread 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

2018-01-12 Thread 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

2017-11-13 Thread 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

2017-11-13 Thread 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

2017-11-13 Thread 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

2017-11-13 Thread 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

2017-11-12 Thread 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

2017-11-12 Thread 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

2017-10-19 Thread 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

2017-10-19 Thread 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

2017-09-04 Thread 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

2017-09-04 Thread 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

2016-11-22 Thread 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

2016-11-22 Thread 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

2016-04-29 Thread 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

2016-04-29 Thread 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

2016-03-23 Thread 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

2016-03-23 Thread 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

2015-11-02 Thread 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

2015-11-02 Thread 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/