Thread (11 messages) 11 messages, 3 authors, 2020-10-30

Re: [PATCHv2 2/3] arm64: cpufeature: reorder cpus_have_{const,final}_cap()

From: Will Deacon <will@kernel.org>
Date: 2020-10-30 08:21:30
Also in: kvmarm

On Fri, Oct 30, 2020 at 08:18:48AM +0000, Will Deacon wrote:
On Mon, Oct 26, 2020 at 01:49:30PM +0000, Mark Rutland wrote:
quoted
In a subsequent patch we'll modify cpus_have_const_cap() to call
cpus_have_final_cap(), and hence we need to define cpus_have_final_cap()
first.

To make subsequent changes easier to follow, this patch reorders the two
without making any other changes.

There should be no functional change as a result of this patch.
You say this...
quoted
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: David Brazdil <redacted>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/include/asm/cpufeature.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f7e7144af174c..5d18c54507e6a 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -428,35 +428,35 @@ static __always_inline bool __cpus_have_const_cap(int num)
 }
 
 /*
- * Test for a capability, possibly with a runtime check.
+ * Test for a capability without a runtime check.
  *
- * Before capabilities are finalized, this behaves as cpus_have_cap().
+ * Before capabilities are finalized, this will BUG().
  * After capabilities are finalized, this is patched to avoid a runtime check.
  *
  * @num must be a compile-time constant.
  */
-static __always_inline bool cpus_have_const_cap(int num)
+static __always_inline bool cpus_have_final_cap(int num)
 {
 	if (system_capabilities_finalized())
 		return __cpus_have_const_cap(num);
 	else
-		return cpus_have_cap(num);
+		BUG();
... but isn't the failure case of calling cpus_have_final_cap() early now
different? What does BUG() do at EL2 w/ nVHE?
Ah no, sorry, I see you're just moving things around and the diff makes it
look confusing (that and I've been up since 5:30 for KVM Forum).

So on closer inspection:

Acked-by: Will Deacon <will@kernel.org>

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help