[PATCH] arm64: crypto: Disable xor-neon build when using clang

From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jackie Liu <liuyun01@kylinos.cn>,
	ndesaulniers@google.com, Mark Brown <broonie@kernel.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: crypto: Disable xor-neon build when using clang
Date: Tue, 12 Feb 2019 19:46:45 +0000	[thread overview]
Message-ID: <20190212194645.32504-1-broonie@kernel.org> (raw)

Currently clang is able to build an arm64 defconfig or allmodconfig
using the release branch for clang 8 apart from a series of errors in
xor-neon.c in the form:

  arch/arm64/lib/xor-neon.c:27:28: error: incompatible pointer types assigning to 'const unsigned long *' from 'uint64_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]

This issue has been extensively discussed between various interested
parties but it is still unclear what if any the best solution is in the
compiler and there are concerns about just disabling the warning with a
pragma in the header due to the potential for masking other serious
issues.  Details of the discussion can be followed here:

   https://github.com/ClangBuiltLinux/linux/issues/283

In order to avoid the issue and facilitate further clang work and
testing for the time being just disable the use of xor-neon.c if we are
building with clang.  Obviously this is not actually resolving the
problem and is not something that should be with us for the long term
but since it only affects clang and enables people working on that to
work directly with upstream it seems like a useful tradeoff.

Signed-off-by: Mark Brown <broonie@kernel.org>
---

It would also be possible to achieve the same effect by using either a
Makefile change or a pragma to disable the warning for this specific
file, I can send a patch for those approaches if that's OK and
preferable.  Disabling the acceleration entirely seemed safer and less
likely to be forgotten to me.

We've got some KernelCI support for clang in the middle of getting
deployed:

   https://staging.kernelci.org/job/next-clang/branch/master/

so being able to build and run upstream kernels directly would be
enormously helpful.

 arch/arm64/include/asm/xor.h | 2 +-
 arch/arm64/lib/Makefile      | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/xor.h b/arch/arm64/include/asm/xor.h
index 856386ad076c..971b8336d2d2 100644
--- a/arch/arm64/include/asm/xor.h
+++ b/arch/arm64/include/asm/xor.h
@@ -14,7 +14,7 @@
 #include <asm/hwcap.h>
 #include <asm/neon.h>
 
-#ifdef CONFIG_KERNEL_MODE_NEON
+#if defined(CONFIG_KERNEL_MODE_NEON) && !defined(CONFIG_CC_IS_CLANG)
 
 extern struct xor_block_template const xor_block_inner_neon;
 
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 5540a1638baf..b2a5b8d56354 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -6,10 +6,12 @@ lib-y		:= clear_user.o delay.o copy_from_user.o		\
 		   strchr.o strrchr.o tishift.o
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
+ifneq ($(CONFIG_CC_IS_CLANG), y)
 obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 CFLAGS_REMOVE_xor-neon.o	+= -mgeneral-regs-only
 CFLAGS_xor-neon.o		+= -ffreestanding
 endif
+endif
 
 # Tell the compiler to treat all general purpose registers (with the
 # exception of the IP registers, which are already handled by the caller
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
