- 16 10月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 09 10月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 04 10月, 2017 1 次提交
-
-
由 Josh Poimboeuf 提交于
With CONFIG_ORC_UNWINDER, if the user doesn't have libelf-devel installed, and they don't see the make warning, their ORC unwinder will be silently broken. Upgrade the warning to an error. Reported-and-tested-by: NBorislav Petkov <bp@alien8.de> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/d9dfc39fb8240998820f9efb233d283a1ee96084.1507079417.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 02 10月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 25 9月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 21 9月, 2017 1 次提交
-
-
由 Shuah Khan 提交于
kselftest and kselftest-clean targets fail when object directory is specified to relocate objects. Fix it so it can find the source tree to build from. make O=/tmp/kselftest_top kselftest make[1]: Entering directory '/tmp/kselftest_top' make[2]: Entering directory '/tmp/kselftest_top' make[2]: *** tools/testing/selftests: No such file or directory. Stop. make[2]: Leaving directory '/tmp/kselftest_top' ./linux-kselftest/Makefile:1185: recipe for target 'kselftest' failed make[1]: *** [kselftest] Error 2 make[1]: Leaving directory '/tmp/kselftest_top' Makefile:145: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 17 9月, 2017 2 次提交
-
-
由 Linus Torvalds 提交于
-
由 Markus Trippelsdorf 提交于
Commit 5620a0d1 ("firmware: delete in-kernel firmware") removed the entire firmware directory. Unfortunately it thereby also removed the support for built-in firmware. This restores the ability to build firmware directly into the kernel by pruning the original Makefile to the necessary minimum. The default for EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/. Fixes: 5620a0d1 ("firmware: delete in-kernel firmware") Signed-off-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Acked-by: NGreg K-H <gregkh@linuxfoundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 9月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
The last firmware change for the in-kernel firmware source code was back in 2013. Everyone has been relying on the out-of-tree linux-firmware package for a long long time. So let's drop it, it's baggage we don't need to keep dragging around (and having to fix random kbuild issues over time...) Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Marek <mmarek@suse.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 9月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 9月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get the absolute path of the directory because GNU Make 3.80, the minimal supported version at that time, did not support $(abspath ...) or $(realpath ...). Commit 37d69ee3 ("docs: bump minimal GNU Make version to 3.81") dropped the GNU Make 3.80 support, so we are now allowed to use those make-builtin helpers. This conversion will provide better portability without relying on the pwd command or its location /bin/pwd. I am intentionally using $(realpath ...) instead $(abspath ...) in some places. The difference between the two is $(realpath ...) returns an empty string if the given path does not exist. It is convenient in places where we need to error-out if the makefile fails to create an output directory. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NThierry Reding <treding@nvidia.com>
-
- 28 8月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 21 8月, 2017 3 次提交
-
-
由 Shuah Khan 提交于
kselftest-clean isn't in the PHONY target list. Add it. Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Arnd Bergmann 提交于
Commit 971a69db ("Xen: don't warn about 2-byte wchar_t in efi") added the --no-wchar-size-warning to the Makefile to avoid this harmless warning: arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail Changing kbuild to use thin archives instead of recursive linking unfortunately brings the same warning back during the final link. The kernel does not use wchar_t string literals at this point, and xen does not use wchar_t at all (only efi_char16_t), so the flag has no effect, but as pointed out by Jan Beulich, adding a wchar_t string literal would be bad here. Since wchar_t is always defined as u16, independent of the toolchain default, always passing -fshort-wchar is correct and lets us remove the Xen specific hack along with fixing the warning. Link: https://patchwork.kernel.org/patch/9275217/ Fixes: 971a69db ("Xen: don't warn about 2-byte wchar_t in efi") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NDavid Vrabel <david.vrabel@citrix.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Linus Torvalds 提交于
-
- 14 8月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 09 8月, 2017 1 次提交
-
-
由 Cao jin 提交于
This is a bunch of trivial fixes and cleanups. Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 07 8月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 31 7月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 24 7月, 2017 2 次提交
-
-
由 Linus Torvalds 提交于
-
由 Mauro Carvalho Chehab 提交于
After removal of DocBook, those targets are bogus. Reported-by: NJim Davis <jim.epost@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 16 7月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 13 7月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
I made the mistake of upgrading my desktop to the new Fedora 26 that comes with gcc-7.1.1. There's nothing wrong per se that I've noticed, but I now have 1500 lines of warnings, mostly from the new format-truncation warning triggering all over the tree. We use 'snprintf()' and friends in a lot of places, and often know that the numbers are fairly small (ie a controller index or similar), but gcc doesn't know that, and sees an 'int', and thinks that it could be some huge number. And then complains when our buffers are not able to fit the name for the ten millionth controller. These warnings aren't necessarily bad per se, and we probably want to look through them subsystem by subsystem, but at least during the merge window they just mean that I can't even see if somebody is introducing any *real* problems when I pull. So warnings disabled for now. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 7月, 2017 2 次提交
-
-
由 Uwe Kleine-König 提交于
This fixes the following build error for me when building on an 32 bit machine using an XFS file system: $ make scripts/basic/fixdep HOSTCC scripts/basic/fixdep fixdep: error fstat'ing depfile: scripts/basic/.fixdep.d: Value too large for defined data type Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
When we install headers, we are interested only in headers under uapi directories. Split out uapi-asm-generic target and make headers_install depend on it. It will avoid generating unneeded asm-generic wrappers. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 10 7月, 2017 2 次提交
-
-
由 Masahiro Yamada 提交于
We can always pass dst= from the top Makefile. This will simplify the logic in Makefile.headersinst. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Commit 61562f98 ("uapi: export all arch specifics directories") changed the dst from asm-<arch> to arch-<arch> for headers_install_all or headers_check_all. Update the comment. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 03 7月, 2017 2 次提交
-
-
由 Linus Torvalds 提交于
-
由 Cao jin 提交于
Original comments is confusing on "OBJ directory", make it clear. Bonus: move comments close to what it wants to comment. Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 30 6月, 2017 1 次提交
-
-
由 Nicholas Piggin 提交于
The thin archives build currently puts all lib.a and built-in.o files together and links them with --whole-archive. This works because thin archives can recursively refer to thin archives. However some architectures include libgcc.a, which may not be a thin archive, or it may not be constructed with the "P" option, in which case its contents do not get linked correctly. So don't pull .a libs into the root built-in.o archive. These libs should already have symbol tables and indexes built, so they can be direct linker inputs. Move them out of the --whole-archive option, which restore the conditional linking behaviour of lib.a to thin archives builds. Signed-off-by: NNicholas Piggin <npiggin@gmail.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 26 6月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 25 6月, 2017 1 次提交
-
-
由 Matthias Kaehlcke 提交于
cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines whether an option is supported or not. This is fine for options used to build the kernel itself, however some components like the x86 boot code use a different set of flags. Add the new macro __cc-option which is a more generic version of cc-option with additional parameters. One parameter is the compiler with which the check should be performed, the other the compiler options to be used instead KBUILD_C*FLAGS. Refactor cc-option and hostcc-option to use __cc-option and move hostcc-option to scripts/Kbuild.include. Suggested-by: NArnd Bergmann <arnd@arndb.de> Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NMichal Marek <mmarek@suse.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 24 6月, 2017 1 次提交
-
-
由 Jonathan Corbet 提交于
There were a few bits and pieces left over from the now-disused DocBook toolchain; git rid of them. Reported-by: NMarkus Heiser <markus.heiser@darmarit.de> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 22 6月, 2017 1 次提交
-
-
由 Matthias Kaehlcke 提交于
clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 19 6月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 12 6月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 10 6月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Commit 90ac086b ("Makefile: include arch/*/include/generated/uapi before .../generated") introduced this for bisect'ability. The commit chose to promote arch/*/include/generated/uapi in the search path rather than cleaning stale headers. After all, we found that approach was not enough, and ended up with cleaning stale headers by commit cda2c65f ("kbuild: Remove stale asm-generic wrappers"). So, the extra search path is no longer needed because Kbuild invokes scripts/Makefile.asm-generic and remove stale headers before it starts descending. This commit is also reverting commit dc33db7c ("Kbuild: avoid duplicate include path") because we have no more duplicated path. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 06 6月, 2017 2 次提交
-
-
由 Cao jin 提交于
The help info of `make C=1` is little confusing, make it clear. Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This allows to detect -s (--silent) option without checking GNU Make version. As commit e36aaea2 ("kbuild: Fix silent builds with make-4") pointed out, GNU Make 4.x changed the way/order it presents the command line options into MAKEFLAGS. In Make 3.8x, 's' is always the first in a group of short options. The group may be prefixed with '-' in some cases. In Make 4.x, 's' is always the last in a group of short options. As commit e6ac89fa ("kbuild: Correctly deal with make options which contain an 's'") addressed, we also need to deal with long options that contain 's', like --warn-undefined-variables. Test cases: [1] command line input: make --silent -> MAKEFLAGS for Make 3.8x: s -> MAKEFLAGS for Make 4.x : s [2] command line input: make -srR -> MAKEFLAGS for Make 3.8x: sRr -> MAKEFLAGS for Make 4.x : rRs [3] command line input: make -s -rR --warn-undefined-variables -> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr -> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables My idea to cater to all the cases more easily is to filter out long options (--%), then search 's' with $(findstring ...). This way will be more future-proof even if future versions of Make put 's' in the middle of the group. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 05 6月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-