[PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

[PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

[Stephen Boyd]

>From what I can see there isn't anything about ACPI_APEI_SEA that
means the arm64 architecture can or cannot support NMI safe
cmpxchg, so the if condition here is not important. Let's remove
it. Doing that allows us to support ftrace histograms via
CONFIG_HIST_TRIGGERS that depends on the arch having this config
selected.

Cc: Tyler Baicar <tbaicar@codeaurora.org>
Cc: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm64/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6a56d4..27ce2ab7b080 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -21,7 +21,7 @@ config ARM64
 	select ARCH_HAS_STRICT_KERNEL_RWX
 	select ARCH_HAS_STRICT_MODULE_RWX
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-	select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
+	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 	select ARCH_SUPPORTS_ATOMIC_RMW
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

[James Morse]

Hi Stephen,

On 15/09/17 02:19, Stephen Boyd wrote:
> From what I can see there isn't anything about ACPI_APEI_SEA that
> means the arm64 architecture can or cannot support NMI safe
> cmpxchg, so the if condition here is not important. 

Yup, it was to match 'HAVE_NMI', which was new with ACPI_APEI_SEA and pulls in
some printk() stuff.

... how come you don't need to change HAVE_NMI too?


> Let's remove
> it. Doing that allows us to support ftrace histograms via
> CONFIG_HIST_TRIGGERS that depends on the arch having this config
> selected.

What does CONFIG_HIST_TRIGGERS need this for? I can't see any
cmpxchg use in kernel/trace/trace_events_hist.c


Regardless,

Acked-by: James Morse <james.morse@arm.com>


Thanks,

James

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 0df64a6a56d4..27ce2ab7b080 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -21,7 +21,7 @@ config ARM64
>  	select ARCH_HAS_STRICT_KERNEL_RWX
>  	select ARCH_HAS_STRICT_MODULE_RWX
>  	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> -	select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
> +	select ARCH_HAVE_NMI_SAFE_CMPXCHG
>  	select ARCH_USE_CMPXCHG_LOCKREF
>  	select ARCH_SUPPORTS_MEMORY_FAILURE
>  	select ARCH_SUPPORTS_ATOMIC_RMW
> 

[PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

[Stephen Boyd]

On 09/15, James Morse wrote:
> On 15/09/17 02:19, Stephen Boyd wrote:
> > From what I can see there isn't anything about ACPI_APEI_SEA that
> > means the arm64 architecture can or cannot support NMI safe
> > cmpxchg, so the if condition here is not important. 
> 
> Yup, it was to match 'HAVE_NMI', which was new with ACPI_APEI_SEA and pulls in
> some printk() stuff.
> 
> ... how come you don't need to change HAVE_NMI too?

I didn't change HAVE_NMI because it wasn't needed to get hist
triggers working. Sorry, I didn't even notice that HAVE_NMI
was also there, probably both of these configs should drop the
condition. I'll update the patch to do so.

> 
> 
> > Let's remove
> > it. Doing that allows us to support ftrace histograms via
> > CONFIG_HIST_TRIGGERS that depends on the arch having this config
> > selected.
> 
> What does CONFIG_HIST_TRIGGERS need this for? I can't see any
> cmpxchg use in kernel/trace/trace_events_hist.c

True. I think this isn't necessary for CONFIG_HIST_TRIGGERS, but
more for CONFIG_TRACING_MAP that is selected and used by
CONFIG_HIST_TRIGGERS. We put the dependency in both places so we
don't get the trigger config selecting a config that has unmet
dependencies. Note there's a cmpxchg in the tracing map code too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project