summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Linux 5.4.54v5.4.54Greg Kroah-Hartman2020-07-291-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilationFangrui Song2020-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream. When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: stable@vger.kernel.org Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 5.4.53v5.4.53Greg Kroah-Hartman2020-07-221-1/+1
|
* Linux 5.4.52v5.4.52Greg Kroah-Hartman2020-07-161-1/+1
|
* Linux 5.4.51v5.4.51Greg Kroah-Hartman2020-07-091-1/+1
|
* Linux 5.4.50v5.4.50Sasha Levin2020-06-301-1/+1
| | | | Signed-off-by: Sasha Levin <sashal@kernel.org>
* Linux 5.4.49v5.4.49Greg Kroah-Hartman2020-06-241-1/+1
|
* Linux 5.4.48v5.4.48Greg Kroah-Hartman2020-06-221-1/+1
|
* kbuild: force to build vmlinux if CONFIG_MODVERSION=yMasahiro Yamada2020-06-221-5/+8
| | | | | | | | | | | | | | | | | | | commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream. This code does not work as stated in the comment. $(CONFIG_MODVERSIONS) is always empty because it is expanded before include/config/auto.conf is included. Hence, 'make modules' with CONFIG_MODVERSION=y cannot record the version CRCs. This has been broken since 2003, commit ("kbuild: Enable modules to be build using the "make dir/" syntax"). [1] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7 Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 5.4.47v5.4.47Greg Kroah-Hartman2020-06-171-1/+1
|
* Linux 5.4.46v5.4.46Greg Kroah-Hartman2020-06-101-1/+1
|
* Linux 5.4.45v5.4.45Greg Kroah-Hartman2020-06-071-1/+1
|
* Linux 5.4.44v5.4.44Greg Kroah-Hartman2020-06-031-1/+1
|
* Linux 5.4.43v5.4.43Greg Kroah-Hartman2020-05-271-1/+1
|
* kbuild: avoid concurrency issue in parallel building dtbs and dtbs_checkMasahiro Yamada2020-05-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b5154bf63e5577faaaca1d942df274f7de91dd2a ] 'make dtbs_check' checks the shecma in addition to building *.dtb files, in other words, 'make dtbs_check' is a super-set of 'make dtbs'. So, you do not have to do 'make dtbs dtbs_check', but I want to keep the build system as robust as possible in any use. Currently, 'dtbs' and 'dtbs_check' are independent of each other. In parallel building, two threads descend into arch/*/boot/dts/, one for dtbs and the other for dtbs_check, then end up with building the same DTB simultaneously. This commit fixes the concurrency issue. Otherwise, I see build errors like follows: $ make ARCH=arm64 defconfig $ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check <snip> DTC arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-evk.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb DTC arch/arm64/boot/dts/zte/zx296718-pcbox.dtb DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb CHECK arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb' make[2]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb fixdep: parse error; no targets found make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb' make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2 make[1]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Linux 5.4.42v5.4.42Greg Kroah-Hartman2020-05-201-1/+1
|
* Makefile: disallow data races on gcc-10 as wellSergei Trofimovich2020-05-201-0/+1
| | | | | | | | | | | | | | | | commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream. gcc-10 will rename --param=allow-store-data-races=0 to -fno-allow-store-data-races. The flag change happened at https://gcc.gnu.org/PR92046. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Thomas Backlund <tmb@mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'restrict' warning for nowLinus Torvalds2020-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit adc71920969870dfa54e8f40dac8616284832d02 upstream. gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers. That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input. And people do that as an odd concatenation pattern, with code like this: #define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__) where we have 'buffer' as both the destination of the final result, and as the initial argument. Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... ); where that output buffer is marked as a restrict pointer that cannot alias with any other arguments. But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own. If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'stringop-overflow' warning for nowLinus Torvalds2020-05-201-0/+1
| | | | | | | | | | | | | | commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream. This is the final array bounds warning removal for gcc-10 for now. Again, the warning is good, and we should re-enable all these warnings when we have converted all the legacy array declaration cases to flexible arrays. But in the meantime, it's just noise. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'array-bounds' warning for nowLinus Torvalds2020-05-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 44720996e2d79e47d508b0abe99b931a726a3197 upstream. This is another fine warning, related to the 'zero-length-bounds' one, but hitting the same historical code in the kernel. Because C didn't historically support flexible array members, we have code that instead uses a one-sized array, the same way we have cases of zero-sized arrays. The one-sized arrays come from either not wanting to use the gcc zero-sized array extension, or from a slight convenience-feature, where particularly for strings, the size of the structure now includes the allocation for the final NUL character. So with a "char name[1];" at the end of a structure, you can do things like v = my_malloc(sizeof(struct vendor) + strlen(name)); and avoid the "+1" for the terminator. Yes, the modern way to do that is with a flexible array, and using 'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That also technically gets the size "more correct" in that it avoids any alignment (and thus padding) issues, but this is another long-term cleanup thing that will not happen for 5.7. So disable the warning for now, even though it's potentially quite useful. Having a slew of warnings that then hide more urgent new issues is not an improvement. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'zero-length-bounds' warning for nowLinus Torvalds2020-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream. This is a fine warning, but we still have a number of zero-length arrays in the kernel that come from the traditional gcc extension. Yes, they are getting converted to flexible arrays, but in the meantime the gcc-10 warning about zero-length bounds is very verbose, and is hiding other issues. I missed one actual build failure because it was hidden among hundreds of lines of warning. Thankfully I caught it on the second go before pushing things out, but it convinced me that I really need to disable the new warnings for now. We'll hopefully be all done with our conversion to flexible arrays in the not too distant future, and we can then re-enable this warning. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Stop the ad-hoc games with -Wno-maybe-initializedLinus Torvalds2020-05-201-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 upstream. We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't. For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES). And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did. At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings. So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123". Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler. That's currently not the world we live in, though. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 5.4.41v5.4.41Greg Kroah-Hartman2020-05-141-1/+1
|
* Linux 5.4.40v5.4.40Greg Kroah-Hartman2020-05-101-1/+1
|
* Linux 5.4.39v5.4.39Greg Kroah-Hartman2020-05-061-1/+1
|
* Linux 5.4.38v5.4.38Greg Kroah-Hartman2020-05-021-1/+1
|
* Linux 5.4.37v5.4.37Greg Kroah-Hartman2020-05-021-1/+1
|
* Linux 5.4.36v5.4.36Greg Kroah-Hartman2020-04-291-1/+1
|
* Linux 5.4.35v5.4.35Greg Kroah-Hartman2020-04-231-1/+1
|
* Linux 5.4.34v5.4.34Greg Kroah-Hartman2020-04-211-1/+1
|
* Linux 5.4.33v5.4.33Greg Kroah-Hartman2020-04-171-1/+1
|
* Linux 5.4.32v5.4.32Greg Kroah-Hartman2020-04-131-1/+1
|
* Linux 5.4.31v5.4.31Greg Kroah-Hartman2020-04-081-1/+1
|
* Linux 5.4.30v5.4.30Greg Kroah-Hartman2020-04-021-1/+1
|
* Linux 5.4.29v5.4.29Greg Kroah-Hartman2020-04-011-1/+1
|
* Linux 5.4.28v5.4.28Greg Kroah-Hartman2020-03-251-1/+1
|
* Linux 5.4.27v5.4.27Greg Kroah-Hartman2020-03-211-1/+1
|
* kbuild: add dt_binding_check to PHONY in a correct placeMasahiro Yamada2020-03-211-1/+2
| | | | | | | | | | | | | | [ Upstream commit c473a8d03ea8e03ca9d649b0b6d72fbcf6212c05 ] The dt_binding_check is added to PHONY, but it is invisible when $(dtstree) is empty. So, it is not specified as phony for ARCH=x86 etc. Add it to PHONY outside the ifneq ... endif block. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kbuild: add dtbs_check to PHONYMasahiro Yamada2020-03-211-1/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 964a596db8db8c77c9903dd05655696696e6b3ad ] The dtbs_check should be a phony target, but currently it is not specified so. 'make dtbs_check' works even if a file named 'dtbs_check' exists because it depends on another phony target, scripts_dtc, but we should not rely on it. Add dtbs_check to PHONY. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Linux 5.4.26v5.4.26Greg Kroah-Hartman2020-03-181-1/+1
|
* Linux 5.4.25v5.4.25Greg Kroah-Hartman2020-03-121-1/+1
|
* Linux 5.4.24v5.4.24Greg Kroah-Hartman2020-03-051-1/+1
|
* kbuild: make single target builds even fasterMasahiro Yamada2020-03-051-43/+47
| | | | | | | | | | | | | | | | | commit b1fbfcb4a20949df08dd995927cdc5ad220c128d upstream. Commit 2dffd23f81a3 ("kbuild: make single target builds much faster") made the situation much better. To improve it even more, apply the similar idea to the top Makefile. Trim unrelated directories from build-dirs. The single build code must be moved above the 'descend' target. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: remove unneeded variable, single-allMasahiro Yamada2020-03-051-4/+2
| | | | | | | | | | | commit 35e046a203ee3bc8ba9ae3561b50de02646dfb81 upstream. When single-build is set, everything in $(MAKECMDGOALS) is a single target. You can use $(MAKECMDGOALS) to list out the single targets. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: move headers_check rule to usr/include/MakefileMasahiro Yamada2020-03-051-8/+3
| | | | | | | | | | | | | | | | | commit 7ecaf069da52e472d393f03e79d721aabd724166 upstream. Currently, some sanity checks for uapi headers are done by scripts/headers_check.pl, which is wired up to the 'headers_check' target in the top Makefile. It is true compiling headers has better test coverage, but there are still several headers excluded from the compile test. I like to keep headers_check.pl for a while, but we can delete a lot of code by moving the build rule to usr/include/Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: remove header compile testMasahiro Yamada2020-03-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream. There are both positive and negative options about this feature. At first, I thought it was a good idea, but actually Linus stated a negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it is ugly and annoying. The baseline I'd like to keep is the compile-test of uapi headers. (Otherwise, kernel developers have no way to ensure the correctness of the exported headers.) I will maintain a small build rule in usr/include/Makefile. Remove the other header test functionality. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> [ added to 5.4.y due to start of build warnings from backported patches because of this feature - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 5.4.23v5.4.23Greg Kroah-Hartman2020-02-281-1/+1
|
* Linux 5.4.22v5.4.22Greg Kroah-Hartman2020-02-241-1/+1
|
* Linux 5.4.21v5.4.21Greg Kroah-Hartman2020-02-191-1/+1
|
* Linux 5.4.20v5.4.20Greg Kroah-Hartman2020-02-141-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 22:45:25 +0000