Changes in Makefile

0d64a24ec0c02f75e5068065b503d98e10a60d01 - arm: move the XOR code to lib/raid/

Fri, 27 Mar 2026 07:16:44 +0100

arm: move the XOR code to lib/raid/Move the optimized XOR into lib/raid and include it it in the main xor.koinstead of building a separate module for it.Link: https://lkml.kernel.org/r/20260327061704.3707577-13-hch@lst.deSigned-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Tested-by: Eric Biggers Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andreas Larsson Cc: Anton Ivanov Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Chris Mason Cc: Christian Borntraeger Cc: Dan Williams Cc: David S. Miller Cc: David Sterba Cc: Heiko Carstens Cc: Herbert Xu Cc: "H. Peter Anvin" Cc: Huacai Chen Cc: Ingo Molnar Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Li Nan Cc: Madhavan Srinivasan Cc: Magnus Lindholm Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Richard Henderson Cc: Richard Weinberger Cc: Russell King Cc: Song Liu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux/arch/arm/lib/Makefile

13150742b09e720fdf021de14cd2b98b37415a89 - Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

Tue, 29 Jul 2025 02:58:52 +0200

Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linuxPull crypto library updates from Eric Biggers: "This is the main crypto library pull request for 6.17. The main focus this cycle is on reorganizing the SHA-1 and SHA-2 code, providing high-quality library APIs for SHA-1 and SHA-2 including HMAC support, and establishing conventions for lib/crypto/ going forward: - Migrate the SHA-1 and SHA-512 code (and also SHA-384 which shares most of the SHA-512 code) into lib/crypto/. This includes both the generic and architecture-optimized code. Greatly simplify how the architecture-optimized code is integrated. Add an easy-to-use library API for each SHA variant, including HMAC support. Finally, reimplement the crypto_shash support on top of the library API. - Apply the same reorganization to the SHA-256 code (and also SHA-224 which shares most of the SHA-256 code). This is a somewhat smaller change, due to my earlier work on SHA-256. But this brings in all the same additional improvements that I made for SHA-1 and SHA-512. There are also some smaller changes: - Move the architecture-optimized ChaCha, Poly1305, and BLAKE2s code from arch/$(SRCARCH)/lib/crypto/ to lib/crypto/$(SRCARCH)/. For these algorithms it's just a move, not a full reorganization yet. - Fix the MIPS chacha-core.S to build with the clang assembler. - Fix the Poly1305 functions to work in all contexts. - Fix a performance regression in the x86_64 Poly1305 code. - Clean up the x86_64 SHA-NI optimized SHA-1 assembly code. Note that since the new organization of the SHA code is much simpler, the diffstat of this pull request is negative, despite the addition of new fully-documented library APIs for multiple SHA and HMAC-SHA variants. These APIs will allow further simplifications across the kernel as users start using them instead of the old-school crypto API. (I've already written a lot of such conversion patches, removing over 1000 more lines of code. But most of those will target 6.18 or later)"* tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (67 commits) lib/crypto: arm64/sha512-ce: Drop compatibility macros for older binutils lib/crypto: x86/sha1-ni: Convert to use rounds macros lib/crypto: x86/sha1-ni: Minor optimizations and cleanup crypto: sha1 - Remove sha1_base.h lib/crypto: x86/sha1: Migrate optimized code into library lib/crypto: sparc/sha1: Migrate optimized code into library lib/crypto: s390/sha1: Migrate optimized code into library lib/crypto: powerpc/sha1: Migrate optimized code into library lib/crypto: mips/sha1: Migrate optimized code into library lib/crypto: arm64/sha1: Migrate optimized code into library lib/crypto: arm/sha1: Migrate optimized code into library crypto: sha1 - Use same state format as legacy drivers crypto: sha1 - Wrap library and add HMAC support lib/crypto: sha1: Add HMAC support lib/crypto: sha1: Add SHA-1 library functions lib/crypto: sha1: Rename sha1_init() to sha1_init_raw() crypto: x86/sha1 - Rename conflicting symbol lib/crypto: sha2: Add hmac_sha*_init_usingrawkey() lib/crypto: arm/poly1305: Remove unneeded empty weak function lib/crypto: x86/poly1305: Fix performance regression on short messages ... List of files: /linux/arch/arm/lib/Makefile

530b304f00f278b3aa31bdfccf09b3ffb457a607 - lib/crc: arm: Migrate optimized CRC code into lib/crc/

Sat, 07 Jun 2025 22:04:45 +0200

lib/crc: arm: Migrate optimized CRC code into lib/crc/Move the arm-optimized CRC code from arch/arm/lib/crc* into its newlocation in lib/crc/arm/, and wire it up in the new way. This new wayof organizing the CRC code eliminates the need to artificially split thecode for each CRC variant into separate arch and generic modules,enabling better inlining and dead code elimination. For more details,see "lib/crc: Prepare for arch-optimized code in subdirs of lib/crc/".Reviewed-by: "Martin K. Petersen" Acked-by: Ingo Molnar Acked-by: "Jason A. Donenfeld" Link: https://lore.kernel.org/r/20250607200454.73587-4-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/arch/arm/lib/Makefile

4a32e5dc1dcfa8f1ed6ca33328e71dcb6196c09e - lib/crypto: arm: Move arch/arm/lib/crypto/ into lib/crypto/

Thu, 19 Jun 2025 21:19:00 +0200

lib/crypto: arm: Move arch/arm/lib/crypto/ into lib/crypto/Move the contents of arch/arm/lib/crypto/ into lib/crypto/arm/.The new code organization makes a lot more sense for how this codeactually works and is developed. In particular, it makes it possible tobuild each algorithm as a single module, with better inlining and deadcode elimination. For a more detailed explanation, see the patchsetwhich did this for the CRC library code:https://lore.kernel.org/r/20250607200454.73587-1-ebiggers@kernel.org/.Also see the patchset which did this for SHA-512:https://lore.kernel.org/linux-crypto/20250616014019.415791-1-ebiggers@kernel.org/This is just a preparatory commit, which does the move to get the filesinto their new location but keeps them building the same way as before.Later commits will make the actual improvements to the way thearch-optimized code is integrated for each algorithm.Add a gitignore entry for the removed directory arch/arm/lib/crypto/ sothat people don't accidentally commit leftover generated files.Acked-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Reviewed-by: Sohil Mehta Link: https://lore.kernel.org/r/20250619191908.134235-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/arch/arm/lib/Makefile

14418ddcc2c2055743ac7ee53d5ac2cf8a8660a7 - Merge tag 'v6.16-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

Mon, 26 May 2025 22:47:28 +0200

Merge tag 'v6.16-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Pull crypto updates from Herbert Xu: "API: - Fix memcpy_sglist to handle partially overlapping SG lists - Use memcpy_sglist to replace null skcipher - Rename CRYPTO_TESTS to CRYPTO_BENCHMARK - Flip CRYPTO_MANAGER_DISABLE_TEST into CRYPTO_SELFTESTS - Hide CRYPTO_MANAGER - Add delayed freeing of driver crypto_alg structures Compression: - Allocate large buffers on first use instead of initialisation in scomp - Drop destination linearisation buffer in scomp - Move scomp stream allocation into acomp - Add acomp scatter-gather walker - Remove request chaining - Add optional async request allocation Hashing: - Remove request chaining - Add optional async request allocation - Move partial block handling into API - Add ahash support to hmac - Fix shash documentation to disallow usage in hard IRQs Algorithms: - Remove unnecessary SIMD fallback code on x86 and arm/arm64 - Drop avx10_256 xts(aes)/ctr(aes) on x86 - Improve avx-512 optimisations for xts(aes) - Move chacha arch implementations into lib/crypto - Move poly1305 into lib/crypto and drop unused Crypto API algorithm - Disable powerpc/poly1305 as it has no SIMD fallback - Move sha256 arch implementations into lib/crypto - Convert deflate to acomp - Set block size correctly in cbcmac Drivers: - Do not use sg_dma_len before mapping in sun8i-ss - Fix warm-reboot failure by making shutdown do more work in qat - Add locking in zynqmp-sha - Remove cavium/zip - Add support for PCI device 0x17D8 to ccp - Add qat_6xxx support in qat - Add support for RK3576 in rockchip-rng - Add support for i.MX8QM in caam Others: - Fix irq_fpu_usable/kernel_fpu_begin inconsistency during CPU bring-up - Add new SEV/SNP platform shutdown API in ccp"* tag 'v6.16-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (382 commits) x86/fpu: Fix irq_fpu_usable() to return false during CPU onlining crypto: qat - add missing header inclusion crypto: api - Redo lookup on EEXIST Revert "crypto: testmgr - Add hash export format testing" crypto: marvell/cesa - Do not chain submitted requests crypto: powerpc/poly1305 - add depends on BROKEN for now Revert "crypto: powerpc/poly1305 - Add SIMD fallback" crypto: ccp - Add missing tee info reg for teev2 crypto: ccp - Add missing bootloader info reg for pspv5 crypto: sun8i-ce - move fallback ahash_request to the end of the struct crypto: octeontx2 - Use dynamic allocated memory region for lmtst crypto: octeontx2 - Initialize cptlfs device info once crypto: xts - Only add ecb if it is not already there crypto: lrw - Only add ecb if it is not already there crypto: testmgr - Add hash export format testing crypto: testmgr - Use ahash for generic tfm crypto: hmac - Add ahash support crypto: testmgr - Ignore EEXIST on shash allocation crypto: algapi - Add driver template support to crypto_inst_setname crypto: shash - Set reqsize in shash_alg ... List of files: /linux/arch/arm/lib/Makefile

6cc25e4b7c819c183a21d6b9a4bcec84229131d1 - arm/crc: drop "glue" from filenames

Thu, 24 Apr 2025 02:20:32 +0200

arm/crc: drop "glue" from filenamesThe use of the term "glue" in filenames is a Crypto API-ism that rarelyshows up elsewhere in lib/ or arch/*/lib/. I think adopting it therewas a mistake. The library just uses standard functions, so the amountof code that could be considered "glue" is quite small. And while oftenthe C functions just wrap the assembly functions, there are also caseslike crc32c_arch() in arch/x86/lib/crc32-glue.c that blur the line byin-lining the actual implementation into the C function. That's not"glue code", but rather the actual code.Therefore, let's drop "glue" from the filenames and instead use e.g.crc32.c instead of crc32-glue.c.Reviewed-by: "Martin K. Petersen" Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250424002038.179114-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/arch/arm/lib/Makefile

714656a84697f9615b9488b490c99edb3ecfcd3d - crypto: arm - move library functions to arch/arm/lib/crypto/

Tue, 22 Apr 2025 17:27:08 +0200

crypto: arm - move library functions to arch/arm/lib/crypto/Continue disentangling the crypto library functions from the genericcrypto infrastructure by moving the arm BLAKE2s, ChaCha, and Poly1305library functions into a new directory arch/arm/lib/crypto/ that doesnot depend on CRYPTO. This mirrors the distinction between crypto/ andlib/crypto/.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux/arch/arm/lib/Makefile

1684e8293605062dee45a5e4118fe8db6cd0d9d9 - arm/crc-t10dif: expose CRC-T10DIF function through lib

Mon, 02 Dec 2024 02:20:49 +0100

arm/crc-t10dif: expose CRC-T10DIF function through libMove the arm CRC-T10DIF assembly code into the lib directory and wire itup to the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/arm/crypto/crct10dif-ce-glue.c toarch/arm/lib/crc-t10dif-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20241202012056.209768-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/arch/arm/lib/Makefile

1e1b6dbc3d9c152df818f3e560f96839a901ebce - arm/crc32: expose CRC32 functions through lib

Mon, 02 Dec 2024 02:08:30 +0100

arm/crc32: expose CRC32 functions through libMove the arm CRC32 assembly code into the lib directory and wire it upto the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/arm/crypto/crc32-ce-glue.c toarch/arm/lib/crc32-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20241202010844.144356-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/arch/arm/lib/Makefile

c41624315b602da32f59e70baa825c5f11fea892 - ARM: crypto: use CC_FLAGS_FPU for NEON CFLAGS

Fri, 29 Mar 2024 08:18:18 +0100

ARM: crypto: use CC_FLAGS_FPU for NEON CFLAGSNow that CC_FLAGS_FPU is exported and can be used anywhere in the sourcetree, use it instead of duplicating the flags here.Link: https://lkml.kernel.org/r/20240329072441.591471-4-samuel.holland@sifive.comSigned-off-by: Samuel Holland Reviewed-by: Christoph Hellwig Acked-by: Christian König Cc: Alex Deucher Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Dave Hansen Cc: Huacai Chen Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Masahiro Yamada Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Russell King Cc: Thomas Gleixner Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux/arch/arm/lib/Makefile

aaa4dd1b47f5ff5ef477fec5dcc6c397b457f1c2 - ARM: 9279/1: support function error injection

Sun, 04 Dec 2022 04:46:40 +0100

ARM: 9279/1: support function error injectionThis enables HAVE_FUNCTION_ERROR_INJECTION by adding necessaryregs_set_return_value() and override_function_with_return().Simply tested according to Documentation/fault-injection/fault-injection.rst.Signed-off-by: Kefeng Wang Signed-off-by: Russell King (Oracle) List of files: /linux/arch/arm/lib/Makefile

a2faac39866d0313f3ca59c36a9f4e077faf4f53 - ARM: 9263/1: use .arch directives instead of assembler command line flags

Mon, 24 Oct 2022 21:44:41 +0200

ARM: 9263/1: use .arch directives instead of assembler command line flagsSimilar to commit a6c30873ee4a ("ARM: 8989/1: use .fpu assemblerdirectives instead of assembler arguments").GCC and GNU binutils support setting the "sub arch" via -march=,-Wa,-march, target function attribute, and .arch assembler directive.Clang was missing support for -Wa,-march=, but this was implemented inclang-13.The behavior of both GCC and Clang is toprefer -Wa,-march= over -march= for assembler and assembler-with-cppsources, but Clang will warn about the -march= being unused.clang: warning: argument unused during compilation: '-march=armv6k'[-Wunused-command-line-argument]Since most assembler is non-conditionally assembled with one sub arch(modulo arch/arm/delay-loop.S which conditionally is assembled as armv4based on CONFIG_ARCH_RPC, and arch/arm/mach-at91/pm-suspend.S which isconditionally assembled as armv7-a based on CONFIG_CPU_V7), prefer the.arch assembler directive.Add a few more instances found in compile testing as found by Arnd andNathan.Link: https://github.com/llvm/llvm-project/commit/1d51c699b9e2ebc5bcfdbe85c74cc871426333d4Link: https://bugs.llvm.org/show_bug.cgi?id=48894Link: https://github.com/ClangBuiltLinux/linux/issues/1195Link: https://github.com/ClangBuiltLinux/linux/issues/1315Suggested-by: Arnd Bergmann Suggested-by: Nathan Chancellor Signed-off-by: Arnd Bergmann Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Russell King (Oracle) List of files: /linux/arch/arm/lib/Makefile

6dc5fd93b2f1ef75d5e50fced8cb193811f25f22 - ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for Clang

Thu, 22 Aug 2019 22:26:53 +0200

ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for ClangThe stackframe setup when compiled with clang is different.Since the stack unwinder expects the gcc stackframe setup itfails to print backtraces. This patch adds support for theclang stackframe setup.Link: https://github.com/ClangBuiltLinux/linux/issues/35Cc: clang-built-linux@googlegroups.comSuggested-by: Tri Vo Signed-off-by: Nathan Huckleberry Tested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

12290cc462c24deee503e84e87dea622b40ea15d - ARM: riscpc: move RiscPC assembly files from arch/arm/lib to mach-rpc

Tue, 21 May 2019 16:31:42 +0200

ARM: riscpc: move RiscPC assembly files from arch/arm/lib to mach-rpcMove the assembly files for RiscPC from arch/arm/lib to mach-rpc sothat we contain RiscPC bits in one subdirectory.Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

de9c0d49d85dc563549972edc5589d195cd5e859 - ARM: 8833/1: Ensure that NEON code always compiles with Clang

Sat, 02 Feb 2019 03:34:36 +0100

ARM: 8833/1: Ensure that NEON code always compiles with ClangWhile 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 Clangonly 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 thebeginning of the NEON_FLAGS definitions so that __ARM_NEON__ always getsdefinined by Clang. This doesn't functionally change anything becausethat code will only run where NEON is supported, which is implicitlyarmv7.Link: https://github.com/ClangBuiltLinux/linux/issues/287Suggested-by: Ard Biesheuvel Signed-off-by: Nathan Chancellor Acked-by: Nicolas Pitre Reviewed-by: Nick Desaulniers Reviewed-by: Stefan Agner Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

ff5fdafc9e9702846480e0cea55ba861f72140a2 - ARM: 8745/1: get rid of __memzero()

Fri, 19 Jan 2018 18:17:46 +0100

ARM: 8745/1: get rid of __memzero()The __memzero assembly code is almost identical to memset's except fortwo orr instructions. The runtime performance of __memset(p, n) andmemset(p, 0, n) is accordingly almost identical.However, the memset() macro used to guard against a zero length and tocall __memzero at compile time when the fill value is a constant zerointerferes with compiler optimizations.Arnd found tha the test against a zero length brings up some newwarnings with gcc v8: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103And successively rremoving the test against a zero length and the callto __memzero optimization produces the following kernel sizes fordefconfig with gcc 6: text data bss dec hex filename12248142 6278960 413588 18940690 1210312 vmlinux.orig12244474 6278960 413588 18937022 120f4be vmlinux.no_zero_test12239160 6278960 413588 18931708 120dffc vmlinux.no_memzeroSo it is probably not worth keeping __memzero around given that thecompiler can do a better job at inlining trivial memset(p,0,n) on itsown. And the memset code already handles a zero length just fine.Suggested-by: Arnd Bergmann Signed-off-by: Nicolas Pitre Acked-by: Ard Biesheuvel Acked-by: Arnd Bergmann Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

b24413180f5600bcb3bb70fbed5cf186b60864bd - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 15:07:57 +0100

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux/arch/arm/lib/Makefile

215e362dafede7cc691d8a573d2b31bc7138a770 - ARM: 8306/1: loop_udelay: remove bogomips value limitation

Wed, 25 Feb 2015 22:50:39 +0100

ARM: 8306/1: loop_udelay: remove bogomips value limitationNow that we don't support ARMv3 anymore, the loop based delay code canconvert microsecs into number of loops using a 64-bit multiplicationand more precision.This allows us to lift the hard limit of 3355 on the bogomips value asloops_per_jiffy may now safely span the full 32-bit range.Signed-off-by: Nicolas Pitre Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

c25630381c6e093819d86d9618798db932cc2d90 - ARM: 8285/1: remove ARMv3 user access code again

Thu, 15 Jan 2015 23:41:54 +0100

ARM: 8285/1: remove ARMv3 user access code againThis code was restored with commit 080fc66fb5 ("ARM: Bring back ARMv3 IOand user access code") because the RiscPC memory bus does not understandhalf-word load/stores. However only the IO code needed restoring sincethe alternative user access code contains no half-word accesses, isalready used when CONFIG_PREEMPT is set and runs faster on a StrongARM.Signed-off-by: Nicolas Pitre Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile

017f161a55b48807a73fc9dff0b69f081bf43ee3 - ARM: 7877/1: use built-in byte swap function

Wed, 06 Nov 2013 05:15:24 +0100

ARM: 7877/1: use built-in byte swap functionEnable the compiler intrinsic for byte swapping on arch ARM. Thisallows the compiler to detect and be able to optimize out byteswappings, and has a very modest benefit on vmlinux size (Linaro gcc4.8):text data bss dec hex filename2840310 123932 61960 3026202 2e2d1a vmlinux-lart #orig2840152 123932 61960 3026044 2e2c7c vmlinux-lart #builtin-bswap6473120 314840 5616016 12403976 bd4508 vmlinux-mxs #orig6472586 314848 5616016 12403450 bd42fa vmlinux-mxs #builtin-bswap7419872 318372 379556 8117800 7bde28 vmlinux-imx_v6_v7 #orig7419170 318364 379556 8117090 7bdb62 vmlinux-imx_v6_v7 #builtin-bswapSigned-off-by: Kim Phillips Reviewed-by: Nicolas Pitre Acked-by: David Woodhouse Signed-off-by: Russell King List of files: /linux/arch/arm/lib/Makefile