Blackbird™ Linux sources for OpenBMC https://git.raptorcs.com/git/blackbird-obmc-linux/atom?h=dev-5.0-raptor-04-16-2019 2019-04-05T20:34:39+00:00 2019-04-05T20:34:39+00:00 Nathan Chancellor natechancellor@gmail.com 2019-02-02T02:34:36+00:00 urn:sha1:c716b08e06cafe9e6b713cd5e34dc8cf2286dab8 [ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ] While building arm32 allyesconfig, I ran into the following errors: arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with '-mfloat-abi=softfp -mfpu=neon' In file included from lib/raid6/neon1.c:27: /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2: error: "NEON support not enabled" Building V=1 showed NEON_FLAGS getting passed along to Clang but __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang only defining __ARM_NEON__ when targeting armv7, rather than armv6k, which is the '-march' value for allyesconfig. >From lib/Basic/Targets/ARM.cpp in the Clang source: // This only gets set when Neon instructions are actually available, unlike // the VFP define, hence the soft float and arch check. This is subtly // different from gcc, we follow the intent which was that it should be set // when Neon instructions are actually available. if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) { Builder.defineMacro("__ARM_NEON", "1"); Builder.defineMacro("__ARM_NEON__"); // current AArch32 NEON implementations do not support double-precision // floating-point even when it is present in VFP. Builder.defineMacro("__ARM_NEON_FP", "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP)); } Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets definined by Clang. This doesn't functionally change anything because that code will only run where NEON is supported, which is implicitly armv7. Link: https://github.com/ClangBuiltLinux/linux/issues/287 Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Nicolas Pitre <nico@linaro.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org> 2019-01-07T00:33:10+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-01-07T00:33:10+00:00 urn:sha1:85e1ffbd42f664965dc05f6e9851c06379f27fb2 Pull more Kbuild updates from Masahiro Yamada: - improve boolinit.cocci and use_after_iter.cocci semantic patches - fix alignment for kallsyms - move 'asm goto' compiler test to Kconfig and clean up jump_label CONFIG option - generate asm-generic wrappers automatically if arch does not implement mandatory UAPI headers - remove redundant generic-y defines - misc cleanups * tag 'kbuild-v4.21-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: rename generated .*conf-cfg to *conf-cfg kbuild: remove unnecessary stubs for archheader and archscripts kbuild: use assignment instead of define ... endef for filechk_* rules arch: remove redundant UAPI generic-y defines kbuild: generate asm-generic wrappers if mandatory headers are missing arch: remove stale comments "UAPI Header export list" riscv: remove redundant kernel-space generic-y kbuild: change filechk to surround the given command with { } kbuild: remove redundant target cleaning on failure kbuild: clean up rule_dtc_dt_yaml kbuild: remove UIMAGE_IN and UIMAGE_OUT jump_label: move 'asm goto' support test to Kconfig kallsyms: lower alignment on ARM scripts: coccinelle: boolinit: drop warnings on named constants scripts: coccinelle: check for redeclaration kconfig: remove unused "file" field of yylval union nds32: remove redundant kernel-space generic-y nios2: remove unneeded HAS_DMA define 2019-01-06T00:46:51+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2018-12-31T08:24:08+00:00 urn:sha1:172caf1993b7a6503a9f7faf589e2cf26eb1f219 Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"), the target file is automatically deleted on failure. The boilerplate code ... || { rm -f $@; false; } is unneeded. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 2019-01-03T15:21:02+00:00 Jens Axboe axboe@kernel.dk 2019-01-03T15:21:02+00:00 urn:sha1:dc629c211c65ee5c8f1c4976886d4a5f33f50674 Pull the pending 4.21 changes for md from Shaohua. * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md: md: fix raid10 hang issue caused by barrier raid10: refactor common wait code from regular read/write request md: remvoe redundant condition check lib/raid6: add option to skip algo benchmarking lib/raid6: sort algos in rough performance order lib/raid6: check for assembler SSSE3 support lib/raid6: avoid __attribute_const__ redefinition lib/raid6: add missing include for raid6test md: remove set but not used variable 'bi_rdev' 2018-12-20T16:53:23+00:00 Daniel Verkamp dverkamp@chromium.org 2018-11-12T23:26:52+00:00 urn:sha1:be85f93ae2df32dea0b20908316f1d894c3e0f64 This is helpful for systems where fast startup time is important. It is especially nice to avoid benchmarking RAID functions that are never used (for example, BTRFS selects RAID6_PQ even if the parity RAID mode is not in use). This saves 250+ milliseconds of boot time on modern x86 and ARM systems with a dozen or more available implementations. The new option is defaulted to 'y' to match the previous behavior of always benchmarking on init. Signed-off-by: Daniel Verkamp <dverkamp@chromium.org> Signed-off-by: Shaohua Li <shli@fb.com> 2018-12-20T16:53:23+00:00 Daniel Verkamp dverkamp@chromium.org 2018-11-12T23:26:51+00:00 urn:sha1:0437de4fa09fe59b57d12b785e4afb73b0f34c05 Sort the list of RAID6 algorithms in roughly decreasing order of expected performance: newer instruction sets first (within each architecture) and wider unrollings first. This doesn't make any difference right now, since all functions are benchmarked; a follow-up change will make use of this by optionally choosing the first valid function rather than testing all of them. The Itanium raid6_intx{16,32} entries are also moved down to be near the other raid6_intx entries for clarity. Signed-off-by: Daniel Verkamp <dverkamp@chromium.org> Signed-off-by: Shaohua Li <shli@fb.com> 2018-12-20T16:53:23+00:00 Daniel Verkamp dverkamp@chromium.org 2018-11-12T23:22:18+00:00 urn:sha1:86919f9dd2dbb88bbbe4e381dc8e6b9e9a1b9eb5 Allow the x86 SSSE3 recovery function to be tested in raid6test. Signed-off-by: Daniel Verkamp <dverkamp@chromium.org> Signed-off-by: Shaohua Li <shli@fb.com> 2018-12-20T09:53:11+00:00 Joel Stanley joel@jms.id.au 2018-11-02T00:44:55+00:00 urn:sha1:e213574a449f7a57d4202c1869bbc7680b6b5521 We cannot build these files with clang as it does not allow altivec instructions in assembly when -msoft-float is passed. Jinsong Ji <jji@us.ibm.com> wrote: > We currently disable Altivec/VSX support when enabling soft-float. So > any usage of vector builtins will break. > > Enable Altivec/VSX with soft-float may need quite some clean up work, so > I guess this is currently a limitation. > > Removing -msoft-float will make it work (and we are lucky that no > floating point instructions will be generated as well). This is a workaround until the issue is resolved in clang. Link: https://bugs.llvm.org/show_bug.cgi?id=31177 Link: https://github.com/ClangBuiltLinux/linux/issues/239 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 2018-11-06T17:12:44+00:00 Jeremy Linton jeremy.linton@arm.com 2018-11-06T00:14:41+00:00 urn:sha1:313a06e636808387822af24c507cba92703568b1 The lib/raid6/test fails to build the neon objects on arm64 because the correct machine type is 'aarch64'. Once this is correctly enabled, the neon recovery objects need to be added to the build. Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 2018-07-04T06:37:50+00:00 Kees Cook keescook@chromium.org 2018-07-03T19:52:21+00:00 urn:sha1:ad5728ce21398926a1215ebb38570113fa8edd99 In the quest to remove all stack VLA usage from the kernel[1], this moves the "$#" replacement from being an argument to being inside the function, which avoids generating VLAs. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>