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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/exception.h

between commits:

  23529049c684 ("arm64: entry: fix non-NMI user<->kernel transitions")
  f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")

from the arm64-fixes tree and commit:

  dceec3ff7807 ("arm64: expose FAR_EL1 tag bits in siginfo")

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/exception.h
index 0756191f44f6,2a8aa1884d8a..000000000000
--- a/arch/arm64/include/asm/exception.h
+++ b/arch/arm64/include/asm/exception.h
@@@ -31,13 -31,8 +31,13 @@@ static inline u32 disr_to_esr(u64 disr
  	return esr;
  }
  
 +asmlinkage void noinstr enter_el1_irq_or_nmi(struct pt_regs *regs);
 +asmlinkage void noinstr exit_el1_irq_or_nmi(struct pt_regs *regs);
  asmlinkage void enter_from_user_mode(void);
 +asmlinkage void exit_to_user_mode(void);
 +void arm64_enter_nmi(struct pt_regs *regs);
 +void arm64_exit_nmi(struct pt_regs *regs);
- void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs);
+ void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs);
  void do_undefinstr(struct pt_regs *regs);
  void do_bti(struct pt_regs *regs);
  asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr);

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

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

[Catalin Marinas]

On Tue, Dec 01, 2020 at 10:05:47AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/exception.h
> index 0756191f44f6,2a8aa1884d8a..000000000000
> --- a/arch/arm64/include/asm/exception.h
> +++ b/arch/arm64/include/asm/exception.h
> @@@ -31,13 -31,8 +31,13 @@@ static inline u32 disr_to_esr(u64 disr
>   	return esr;
>   }
>   
>  +asmlinkage void noinstr enter_el1_irq_or_nmi(struct pt_regs *regs);
>  +asmlinkage void noinstr exit_el1_irq_or_nmi(struct pt_regs *regs);
>   asmlinkage void enter_from_user_mode(void);
>  +asmlinkage void exit_to_user_mode(void);
>  +void arm64_enter_nmi(struct pt_regs *regs);
>  +void arm64_exit_nmi(struct pt_regs *regs);
> - void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> + void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs);
>   void do_undefinstr(struct pt_regs *regs);
>   void do_bti(struct pt_regs *regs);
>   asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr);

Thanks Stephen. It looks alright.

-- 
Catalin

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

[Will Deacon]

Hi Stephen,

On Thu, Jul 21, 2022 at 08:45:17PM +1000, Stephen Rothwell wrote:
> On Thu, 21 Jul 2022 09:45:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the arm64 tree got a conflict in:
> > 
> >   arch/arm64/kernel/head.S
> > 
> > between commit:
> > 
> >   f7b4c3b82e7d ("arm64: set UXN on swapper page tables")
> > 
> > from the arm64-fixes tree and commits:
> > 
> >   e42ade29e3bc ("arm64: head: split off idmap creation code")
> >   c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map")
> > 
> > from the arm64 tree.
> > 
> > I didn't know if the change from the former was still needed after the
> > changes in the latter, so I left it out for now.
> 
> OK, so my arm64 defconfig build produced these errors:
> 
> arch/arm64/kernel/head.S: Assembler messages:
> arch/arm64/kernel/head.S:334: Error: immediate cannot be moved by a single instruction
> arch/arm64/kernel/head.S:343: Error: immediate cannot be moved by a single instruction
> arch/arm64/kernel/head.S:354: Error: immediate cannot be moved by a single instruction
> arch/arm64/kernel/head.S:379: Error: immediate cannot be moved by a single instruction
> arch/arm64/mm/proc.S:296: Error: immediate cannot be moved by a single instruction
> 
> So I tried this patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 21 Jul 2022 20:21:36 +1000
> Subject: [PATCH] fixup for "arm64: set UXN on swapper page tables"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm64/kernel/head.S | 8 ++++----
>  arch/arm64/mm/proc.S     | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index cefe6a73ee54..aa7c58689f68 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -331,7 +331,7 @@ SYM_FUNC_START_LOCAL(create_idmap)
>  	adrp	x0, init_idmap_pg_dir
>  	adrp	x3, _text
>  	adrp	x6, _end + MAX_FDT_SIZE + SWAPPER_BLOCK_SIZE
> -	mov	x7, SWAPPER_RX_MMUFLAGS
> +	mov_q	x7, SWAPPER_RX_MMUFLAGS

[...]

I think Marc posted something similar here:

https://lore.kernel.org/r/20220721124244.903567-1-maz@kernel.org

but in further discussion offline (and echoed on that thread), we've decided
to drop f7b4c3b82e7d ("arm64: set UXN on swapper page tables") for now; the
issue it addresses doesn't affect the hardware which is readily available at
the moment so we'll just get it into -stable instead rather than disrupt
everything at this stage in the release cycle.

> So I gave up and left arm64 broken for today :-(

No problem, thank you for trying and hopefully it will be better tomorrow
once we've dropped that commit.

Will

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

[Stephen Rothwell]

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

Hi all,

On Thu, 21 Jul 2022 09:45:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/head.S
> 
> between commit:
> 
>   f7b4c3b82e7d ("arm64: set UXN on swapper page tables")
> 
> from the arm64-fixes tree and commits:
> 
>   e42ade29e3bc ("arm64: head: split off idmap creation code")
>   c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map")
> 
> from the arm64 tree.
> 
> I didn't know if the change from the former was still needed after the
> changes in the latter, so I left it out for now.

OK, so my arm64 defconfig build produced these errors:

arch/arm64/kernel/head.S: Assembler messages:
arch/arm64/kernel/head.S:334: Error: immediate cannot be moved by a single instruction
arch/arm64/kernel/head.S:343: Error: immediate cannot be moved by a single instruction
arch/arm64/kernel/head.S:354: Error: immediate cannot be moved by a single instruction
arch/arm64/kernel/head.S:379: Error: immediate cannot be moved by a single instruction
arch/arm64/mm/proc.S:296: Error: immediate cannot be moved by a single instruction

So I tried this patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Jul 2022 20:21:36 +1000
Subject: [PATCH] fixup for "arm64: set UXN on swapper page tables"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm64/kernel/head.S | 8 ++++----
 arch/arm64/mm/proc.S     | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index cefe6a73ee54..aa7c58689f68 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -331,7 +331,7 @@ SYM_FUNC_START_LOCAL(create_idmap)
 	adrp	x0, init_idmap_pg_dir
 	adrp	x3, _text
 	adrp	x6, _end + MAX_FDT_SIZE + SWAPPER_BLOCK_SIZE
-	mov	x7, SWAPPER_RX_MMUFLAGS
+	mov_q	x7, SWAPPER_RX_MMUFLAGS
 
 	map_memory x0, x1, x3, x6, x7, x3, IDMAP_PGD_ORDER, x10, x11, x12, x13, x14, EXTRA_SHIFT
 
@@ -340,7 +340,7 @@ SYM_FUNC_START_LOCAL(create_idmap)
 	adrp	x2, init_pg_dir
 	adrp	x3, init_pg_end
 	bic	x4, x2, #SWAPPER_BLOCK_SIZE - 1
-	mov	x5, SWAPPER_RW_MMUFLAGS
+	mov_q	x5, SWAPPER_RW_MMUFLAGS
 	mov	x6, #SWAPPER_BLOCK_SHIFT
 	bl	remap_region
 
@@ -351,7 +351,7 @@ SYM_FUNC_START_LOCAL(create_idmap)
 	bfi	x22, x21, #0, #SWAPPER_BLOCK_SHIFT		// remapped FDT address
 	add	x3, x2, #MAX_FDT_SIZE + SWAPPER_BLOCK_SIZE
 	bic	x4, x21, #SWAPPER_BLOCK_SIZE - 1
-	mov	x5, SWAPPER_RW_MMUFLAGS
+	mov_q	x5, SWAPPER_RW_MMUFLAGS
 	mov	x6, #SWAPPER_BLOCK_SHIFT
 	bl	remap_region
 
@@ -376,7 +376,7 @@ SYM_FUNC_START_LOCAL(create_kernel_mapping)
 	adrp	x3, _text			// runtime __pa(_text)
 	sub	x6, x6, x3			// _end - _text
 	add	x6, x6, x5			// runtime __va(_end)
-	mov	x7, SWAPPER_RW_MMUFLAGS
+	mov_q	x7, SWAPPER_RW_MMUFLAGS
 
 	map_memory x0, x1, x5, x6, x7, x3, (VA_BITS - PGDIR_SHIFT), x10, x11, x12, x13, x14
 
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 7837a69524c5..b4fe8e6e85cb 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -293,7 +293,7 @@ SYM_FUNC_START(idmap_kpti_install_ng_mappings)
 	isb
 
 	mov	temp_pte, x5
-	mov	pte_flags, #KPTI_NG_PTE_FLAGS
+	mov_q	pte_flags, #KPTI_NG_PTE_FLAGS
 
 	/* Everybody is enjoying the idmap, so we can rewrite swapper. */
 	/* PGD */
-- 
2.35.1

Which mostly worked, but produced this:

arch/arm64/mm/proc.S: Assembler messages:
arch/arm64/mm/proc.S:296: Error: bad expression
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: junk at end of line, first unrecognized character is `('
arch/arm64/mm/proc.S:296: Error: bad expression
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: found '(', expected: ')'
arch/arm64/mm/proc.S:296: Error: junk at end of line, first unrecognized character is `('
arch/arm64/mm/proc.S:296: Error: bad expression at operand 2 -- `movz pte_flags,:abs_g3:#(((0)<<2)|((3<<0)|(1<<10)|(3<<8)|(1<<54)))'
arch/arm64/mm/proc.S:296: Error: bad expression at operand 2 -- `movk pte_flags,:abs_g2_nc:#(((0)<<2)|((3<<0)|(1<<10)|(3<<8)|(1<<54)))'
arch/arm64/mm/proc.S:296: Error: bad expression at operand 2 -- `movk pte_flags,:abs_g1_nc:#(((0)<<2)|((3<<0)|(1<<10)|(3<<8)|(1<<54)))'
arch/arm64/mm/proc.S:296: Error: bad expression at operand 2 -- `movk pte_flags,:abs_g0_nc:#(((0)<<2)|((3<<0)|(1<<10)|(3<<8)|(1<<54)))'

So I gave up and left arm64 broken for today :-(
-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/head.S

between commit:

  f7b4c3b82e7d ("arm64: set UXN on swapper page tables")

from the arm64-fixes tree and commits:

  e42ade29e3bc ("arm64: head: split off idmap creation code")
  c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map")

from the arm64 tree.

I didn't know if the change from the former was still needed after the
changes in the latter, so I left it out for now.

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

-- 
Cheers,
Stephen Rothwell

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

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

[Will Deacon]

On Thu, Oct 07, 2021 at 09:42:21AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/mm/hugetlbpage.c
> 
> between commit:
> 
>   0350419b14b9 ("arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE")
> 
> from the arm64-fixes tree and commit:
> 
>   f8b46c4b51ab ("arm64/mm: Add pud_sect_supported()")
> 
> 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/hugetlbpage.c
> index a8158c948966,029cf5e42c4c..000000000000
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@@ -40,11 -40,10 +40,10 @@@ void __init arm64_hugetlb_cma_reserve(v
>   {
>   	int order;
>   
> - #ifdef CONFIG_ARM64_4K_PAGES
> - 	order = PUD_SHIFT - PAGE_SHIFT;
> - #else
> - 	order = CONT_PMD_SHIFT - PAGE_SHIFT;
> - #endif
> + 	if (pud_sect_supported())
> + 		order = PUD_SHIFT - PAGE_SHIFT;
> + 	else
>  -		order = CONT_PMD_SHIFT + PMD_SHIFT - PAGE_SHIFT;
> ++		order = CONT_PMD_SHIFT - PAGE_SHIFT;

Thanks, Stephen. I think I'll merge our fixes branch into the core branch
and resolve this there.

Will

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/mm/hugetlbpage.c

between commit:

  0350419b14b9 ("arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE")

from the arm64-fixes tree and commit:

  f8b46c4b51ab ("arm64/mm: Add pud_sect_supported()")

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/hugetlbpage.c
index a8158c948966,029cf5e42c4c..000000000000
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@@ -40,11 -40,10 +40,10 @@@ void __init arm64_hugetlb_cma_reserve(v
  {
  	int order;
  
- #ifdef CONFIG_ARM64_4K_PAGES
- 	order = PUD_SHIFT - PAGE_SHIFT;
- #else
- 	order = CONT_PMD_SHIFT - PAGE_SHIFT;
- #endif
+ 	if (pud_sect_supported())
+ 		order = PUD_SHIFT - PAGE_SHIFT;
+ 	else
 -		order = CONT_PMD_SHIFT + PMD_SHIFT - PAGE_SHIFT;
++		order = CONT_PMD_SHIFT - PAGE_SHIFT;
  	/*
  	 * HugeTLB CMA reservation is required for gigantic
  	 * huge pages which could not be allocated via the

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/module.c

between commit:

  6f496a555d93 ("arm64: kaslr: keep modules inside module region when KASAN is enabled")

from the arm64-fixes tree and commit:

  7dfac3c5f40e ("arm64: module: create module allocations without exec permissions")

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/module.c
index 71530e080ecc,5b5936b7868c..000000000000
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@@ -29,12 -39,9 +29,12 @@@ void *module_alloc(unsigned long size
  	if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
  		gfp_mask |= __GFP_NOWARN;
  
 +	if (IS_ENABLED(CONFIG_KASAN))
 +		/* don't exceed the static module region - see below */
 +		module_alloc_end = MODULES_END;
 +
  	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
- 				module_alloc_end, gfp_mask, PAGE_KERNEL_EXEC, 0,
 -				module_alloc_base + MODULES_VSIZE,
 -				gfp_mask, PAGE_KERNEL, 0,
++				module_alloc_end, gfp_mask, PAGE_KERNEL, 0,
  				NUMA_NO_NODE, __builtin_return_address(0));
  
  	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/thread_info.h

between commit:

  2b55d83e9a8c ("ARM64: trivial: s/TIF_SECOMP/TIF_SECCOMP/ comment typo fix")

from the arm64-fixes tree and commit:

  f086f67485c5 ("arm64: ptrace: add support for syscall emulation")

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/thread_info.h
index f1d032be628a,c285d1ce7186..000000000000
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@@ -75,7 -75,8 +75,8 @@@ void arch_release_task_struct(struct ta
   *  TIF_SYSCALL_TRACE	- syscall trace active
   *  TIF_SYSCALL_TRACEPOINT - syscall tracepoint for ftrace
   *  TIF_SYSCALL_AUDIT	- syscall auditing
+  *  TIF_SYSCALL_EMU     - syscall emulation active
 - *  TIF_SECOMP		- syscall secure computing
 + *  TIF_SECCOMP		- syscall secure computing
   *  TIF_SIGPENDING	- signal pending
   *  TIF_NEED_RESCHED	- rescheduling necessary
   *  TIF_NOTIFY_RESUME	- callback before returning to user

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/cpu_errata.c

between commit:

  e21da1c99200 ("arm64: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery")

from the arm64-fixes tree and commit:

  c0cda3b8ee6b ("arm64: capabilities: Update prototype for enable call back")

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 b5a28336c077,4613e4d75c73..000000000000
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@@ -178,8 -196,8 +196,8 @@@ enable_smccc_arch_workaround_1(const st
  	case PSCI_CONDUIT_HVC:
  		arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
  				  ARM_SMCCC_ARCH_WORKAROUND_1, &res);
 -		if (res.a0)
 +		if ((int)res.a0 < 0)
- 			return 0;
+ 			return;
  		cb = call_hvc_arch_workaround_1;
  		smccc_start = __smccc_workaround_1_hvc_start;
  		smccc_end = __smccc_workaround_1_hvc_end;
@@@ -188,8 -206,8 +206,8 @@@
  	case PSCI_CONDUIT_SMC:
  		arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
  				  ARM_SMCCC_ARCH_WORKAROUND_1, &res);
 -		if (res.a0)
 +		if ((int)res.a0 < 0)
- 			return 0;
+ 			return;
  		cb = call_smc_arch_workaround_1;
  		smccc_start = __smccc_workaround_1_smc_start;
  		smccc_end = __smccc_workaround_1_smc_end;

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