|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3 |
|
| #
3b9ab248 |
| 02-Feb-2024 |
Masahiro Yamada <[email protected]> |
kbuild: use 4-space indentation when followed by conditionals
GNU Make manual [1] clearly forbids a tab at the beginning of the conditional directive line: "Extra spaces are allowed and ignored at
kbuild: use 4-space indentation when followed by conditionals
GNU Make manual [1] clearly forbids a tab at the beginning of the conditional directive line: "Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed."
This will not work for the next release of GNU Make, hence commit 82175d1f9430 ("kbuild: Replace tabs with spaces when followed by conditionals") replaced the inappropriate tabs with 8 spaces.
However, the 8-space indentation cannot be visually distinguished. Linus suggested 2-4 spaces for those nested if-statements. [2]
This commit redoes the replacement with 4 spaces.
[1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax [2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/
Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc2 |
|
| #
82175d1f |
| 28-Jan-2024 |
Dmitry Goncharov <[email protected]> |
kbuild: Replace tabs with spaces when followed by conditionals
This is needed for the future (post make-4.4.1) versions of gnu make.
Starting from https://git.savannah.gnu.org/cgit/make.git/commit/
kbuild: Replace tabs with spaces when followed by conditionals
This is needed for the future (post make-4.4.1) versions of gnu make.
Starting from https://git.savannah.gnu.org/cgit/make.git/commit/?id=07fcee35f058a876447c8a021f9eb1943f902534 gnu make won't allow conditionals to follow recipe prefix.
For example there is a tab followed by ifeq on line 324 in the root Makefile. With the new make this conditional causes the following
$ make cpu.o /home/dgoncharov/src/linux-kbuild/Makefile:2063: *** missing 'endif'. Stop. make: *** [Makefile:240: __sub-make] Error 2
This patch replaces tabs followed by conditionals with 8 spaces.
See https://savannah.gnu.org/bugs/?64185 and https://savannah.gnu.org/bugs/?64259 for details.
Signed-off-by: Dmitry Goncharov <[email protected]> Reported-by: Martin Dorey <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7 |
|
| #
ce697cce |
| 24-Sep-2022 |
Masahiro Yamada <[email protected]> |
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to control the section order by the linker script. Actually, the code marked as __HEAD goes into the ".head.text" section, which is placed before the normal ".text" section.
I do not know if both of them are needed. From the build system perspective, head-y is not mandatory. If you can achieve the proper code placement by the linker script only, it would be cleaner.
I collected the current head-y objects into head-object-list.txt. It is a whitelist. My hope is it will be reduced in the long run.
Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
show more ...
|
|
Revision tags: v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6 |
|
| #
f774f5bb |
| 03-May-2022 |
Masahiro Yamada <[email protected]> |
kbuild: factor out the common installation code into scripts/install.sh
Many architectures have similar install.sh scripts.
The first half is really generic; it verifies that the kernel image and S
kbuild: factor out the common installation code into scripts/install.sh
Many architectures have similar install.sh scripts.
The first half is really generic; it verifies that the kernel image and System.map exist, then executes ~/bin/${INSTALLKERNEL} or /sbin/${INSTALLKERNEL} if available.
The second half is kind of arch-specific; it copies the kernel image and System.map to the destination, but the code is slightly different.
Factor out the generic part into scripts/install.sh.
Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
show more ...
|
|
Revision tags: v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6 |
|
| #
8212f898 |
| 13-Oct-2021 |
Masahiro Yamada <[email protected]> |
kbuild: use more subdir- for visiting subdirectories while cleaning
Documentation/kbuild/makefiles.rst suggests to use "archclean" for cleaning arch/$(SRCARCH)/boot/, but it is not a hard requiremen
kbuild: use more subdir- for visiting subdirectories while cleaning
Documentation/kbuild/makefiles.rst suggests to use "archclean" for cleaning arch/$(SRCARCH)/boot/, but it is not a hard requirement.
Since commit d92cc4d51643 ("kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild"), we can use the "subdir- += boot" trick for all architectures. This can take advantage of the parallel option (-j) for "make clean".
I also cleaned up the comments in arch/$(SRCARCH)/Makefile. The "archdep" target no longer exists.
Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Michael Ellerman <[email protected]> (powerpc)
show more ...
|
|
Revision tags: v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2 |
|
| #
d92cc4d5 |
| 12-May-2021 |
Masahiro Yamada <[email protected]> |
kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild
arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can use the obj-y syntax.
Add an empty file if it is missing in a
kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild
arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can use the obj-y syntax.
Add an empty file if it is missing in arch/$(SRCARCH)/.
Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7 |
|
| #
bc7c9993 |
| 07-Feb-2021 |
Finn Thain <[email protected]> |
m68k: Drop -fno-strength-reduce from KBUILD_CFLAGS
This workaround became redundant either when the driver in question was removed (in Linux v2.6.23) or when the compiler flag became a no-op (in GCC
m68k: Drop -fno-strength-reduce from KBUILD_CFLAGS
This workaround became redundant either when the driver in question was removed (in Linux v2.6.23) or when the compiler flag became a no-op (in GCC v4.2). Linux has required GCC v4.6 or later since v4.19.
Link: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=efa1cdf01850b28c2f6f7035ebd4420259494615 References: commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver") References: commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6") Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/baa95d7235921dff23bed6320518f3fa90396603.1612681353.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
23243c1a |
| 01-May-2021 |
Masahiro Yamada <[email protected]> |
arch: use cross_compiling to check whether it is a cross build or not
'cross_compiling' is defined by the top Makefile and available for arch Makefiles to check whether it is a cross build or not. A
arch: use cross_compiling to check whether it is a cross build or not
'cross_compiling' is defined by the top Makefile and available for arch Makefiles to check whether it is a cross build or not. A good thing is the variable name 'cross_compiling' is self-documenting.
This is a simple replacement for m68k, mips, sh, for which $(ARCH) and $(SRCARCH) always match.
No functional change is intended for xtensa, either.
This is rather a fix for parisc because arch/parisc/Makefile defines UTS_MATCHINE depending on CONFIG_64BIT, therefore cc-cross-prefix is not working in Kconfig time.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Helge Deller <[email protected]> # parisc Acked-by: Max Filippov <[email protected]> # xtensa
show more ...
|
|
Revision tags: v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5 |
|
| #
596b0474 |
| 08-Sep-2020 |
Masahiro Yamada <[email protected]> |
kbuild: preprocess module linker script
There was a request to preprocess the module linker script like we do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
The difference between vmlin
kbuild: preprocess module linker script
There was a request to preprocess the module linker script like we do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
The difference between vmlinux.lds and module.lds is that the latter is needed for external module builds, thus must be cleaned up by 'make mrproper' instead of 'make clean'. Also, it must be created by 'make modules_prepare'.
You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to arch/$(SRCARCH)/include/asm/module.lds.h, which is included from scripts/module.lds.S.
scripts/module.lds is fine because 'make clean' keeps all the build artifacts under scripts/.
You can add arch-specific sections in <asm/module.lds.h>.
Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Jessica Yu <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Jessica Yu <[email protected]>
show more ...
|
|
Revision tags: v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2 |
|
| #
e3a54948 |
| 17-Jun-2020 |
Masahiro Yamada <[email protected]> |
m68k: Use CLEAN_FILES to clean up files
The log of 'make ARCH=m68k clean' does not look nice.
$ make ARCH=m68k clean CLEAN arch/m68k/kernel [ snip ] CLEAN usr rm -f vmlinux.gz vmlinux.bz2
m68k: Use CLEAN_FILES to clean up files
The log of 'make ARCH=m68k clean' does not look nice.
$ make ARCH=m68k clean CLEAN arch/m68k/kernel [ snip ] CLEAN usr rm -f vmlinux.gz vmlinux.bz2 CLEAN vmlinux.symvers modules.builtin modules.builtin.modinfo
Use CLEAN_FILES to simplify the code, and beautify the log.
Signed-off-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc1, v5.7 |
|
| #
40b13fd7 |
| 26-May-2020 |
Masahiro Yamada <[email protected]> |
m68k: Pass -D options to KBUILD_CPPFLAGS instead of KBUILD_{A,C}FLAGS
Precisely, -D is a preprocessor option.
KBUILD_CPPFLAGS is passed for compiling .c and .S files too.
Signed-off-by: Masahiro Y
m68k: Pass -D options to KBUILD_CPPFLAGS instead of KBUILD_{A,C}FLAGS
Precisely, -D is a preprocessor option.
KBUILD_CPPFLAGS is passed for compiling .c and .S files too.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
2367b026 |
| 26-May-2020 |
Masahiro Yamada <[email protected]> |
m68k: Optimize cc-option calls for cpuflags-y
arch/m68k/Makefile computes lots of unneeded cc-option calls.
For example, if CONFIG_M5441x is not defined, there is not point in evaluating the follow
m68k: Optimize cc-option calls for cpuflags-y
arch/m68k/Makefile computes lots of unneeded cc-option calls.
For example, if CONFIG_M5441x is not defined, there is not point in evaluating the following compiler flag.
cpuflags-$(CONFIG_M5441x) := $(call cc-option,-mcpu=54455,-mcfv4e)
The result is set to cpuflags-, then thrown away.
The right hand side of ':=' is immediately expanded. Hence, all of the 16 calls for cc-option are evaluated. This is expensive since cc-option invokes the compiler. This occurs even if you are not attempting to build anything, like 'make ARCH=m68k help'.
Use '=' to expand the value _lazily_. The evaluation for cc-option is delayed until $(cpuflags-y) is expanded. So, the cc-option test happens just once at most.
This commit mimics tune-y of arch/arm/Makefile.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
028a342e |
| 26-May-2020 |
Masahiro Yamada <[email protected]> |
m68k: Add arch/m68k/Kbuild
Use the standard obj-y form to specify the sub-directories under arch/m68k/. No functional change intended.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by
m68k: Add arch/m68k/Kbuild
Use the standard obj-y form to specify the sub-directories under arch/m68k/. No functional change intended.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
e4a42c82 |
| 08-Jun-2020 |
Denis Efremov <[email protected]> |
kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables
Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp. GZIP, BZIP2, LZOP env variables are reserved by the tools. The origi
kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables
Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp. GZIP, BZIP2, LZOP env variables are reserved by the tools. The original attempt to redefine them internally doesn't work in makefiles/scripts intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in broken builds. There can be other broken build commands because of this, so the universal solution is to use non-reserved env variables for the compression tools.
Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools") Signed-off-by: Denis Efremov <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
| #
8dfb61dc |
| 05-Jun-2020 |
Denis Efremov <[email protected]> |
kbuild: add variables for compression tools
Allow user to use alternative implementations of compression tools, such as pigz, pbzip2, pxz. For example, multi-threaded tools to speed up the build: $
kbuild: add variables for compression tools
Allow user to use alternative implementations of compression tools, such as pigz, pbzip2, pxz. For example, multi-threaded tools to speed up the build: $ make GZIP=pigz BZIP2=pbzip2
Variables _GZIP, _BZIP2, _LZOP are used internally because original env vars are reserved by the tools. The use of GZIP in gzip tool is obsolete since 2015. However, alternative implementations (e.g., pigz) still rely on it. BZIP2, BZIP, LZOP vars are not obsolescent.
The credit goes to @grsecurity.
As a sidenote, for multi-threaded lzma, xz compression one can use: $ export XZ_OPT="--threads=0"
Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5 |
|
| #
10df0638 |
| 14-Aug-2019 |
Masahiro Yamada <[email protected]> |
kbuild: rebuild modules when module linker scripts are updated
Currently, the timestamp of module linker scripts are not checked. Add them to the dependency of modules so they are correctly rebuilt.
kbuild: rebuild modules when module linker scripts are updated
Currently, the timestamp of module linker scripts are not checked. Add them to the dependency of modules so they are correctly rebuilt.
Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3 |
|
| #
28713169 |
| 16-Jan-2019 |
Finn Thain <[email protected]> |
m68k: Add -ffreestanding to CFLAGS
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': block/partitions/ldm.c:153: undefined
m68k: Add -ffreestanding to CFLAGS
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': block/partitions/ldm.c:153: undefined reference to `strcmp'
This is caused by a new optimization which effectively replaces a strncmp() call with a strcmp() call. This affects a number of strncmp() call sites in the kernel.
The entire class of optimizations is avoided with -fno-builtin, which gets enabled by -ffreestanding. This may avoid possible future build failures in case new optimizations appear in future compilers.
I haven't done any performance measurements with this patch but I did count the function calls in a defconfig build. For example, there are now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the other libc functions is smaller.
If this harms performance we can tackle that regression by optimizing the call sites, ideally using semantic patches. That way, clang and ICC builds might benfit too.
Cc: [email protected] Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2 Signed-off-by: Finn Thain <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
|
Revision tags: v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3 |
|
| #
005e13a9 |
| 13-Nov-2018 |
Firoz Khan <[email protected]> |
m68k: Generate uapi header and syscall table header files
System call table generation script must be run to gener- ate unistd_32.h and syscall_table.h files. This patch will have changes which will
m68k: Generate uapi header and syscall table header files
System call table generation script must be run to gener- ate unistd_32.h and syscall_table.h files. This patch will have changes which will invokes the script.
This patch will generate unistd_32.h and syscall_table.h files by the syscall table generation script invoked by m68k/Makefile and the generated files against the removed files must be identical.
The generated uapi header file will be included in uapi/- asm/unistd.h and generated system call table header file will be included by kernel/syscalltable.S file.
Signed-off-by: Firoz Khan <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]>
show more ...
|
|
Revision tags: v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1 |
|
| #
d503ac53 |
| 23-Aug-2018 |
Masahiro Yamada <[email protected]> |
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enab
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.
Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.
For some reason, LDFLAGS was not renamed.
Using a well-known variable like LDFLAGS may result in accidental override of the variable.
Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention.
I did not touch Makefiles under tools/ since the tools build system is a different world.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Palmer Dabbelt <[email protected]>
show more ...
|
|
Revision tags: v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8, v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6 |
|
| #
a3595962 |
| 25-Feb-2016 |
Greg Ungerer <[email protected]> |
m68knommu: remove obsolete 68360 support
Remove the obsolete Motorola/Freescale 68360 SoC support. It has been bit rotting for many years with little active use in mainlne. There has been no serial
m68knommu: remove obsolete 68360 support
Remove the obsolete Motorola/Freescale 68360 SoC support. It has been bit rotting for many years with little active use in mainlne. There has been no serial driver support for many years, so it is largely not useful in its current state.
Signed-off-by: Greg Ungerer <[email protected]>
show more ...
|
|
Revision tags: v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2 |
|
| #
3ba885f5 |
| 21-Aug-2014 |
Greg Ungerer <[email protected]> |
m68k: move non-mmu 68360 platform code
The non-mmu 68360 specific code is inconsistently placed under a directory named "platform". Move it to arch/m68k/ along with the other platform and board dire
m68k: move non-mmu 68360 platform code
The non-mmu 68360 specific code is inconsistently placed under a directory named "platform". Move it to arch/m68k/ along with the other platform and board directories.
Signed-off-by: Greg Ungerer <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
18cb3faf |
| 21-Aug-2014 |
Greg Ungerer <[email protected]> |
m68k: move non-mmu 68000 platform code
The non-mmu 68000 specific code is inconsistently placed under a directory named "platform". Move it to arch/m68k/ along with the other platform and machine di
m68k: move non-mmu 68000 platform code
The non-mmu 68000 specific code is inconsistently placed under a directory named "platform". Move it to arch/m68k/ along with the other platform and machine directories.
Signed-off-by: Greg Ungerer <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]>
show more ...
|
| #
f86b9e03 |
| 19-Aug-2014 |
Greg Ungerer <[email protected]> |
m68k: move coldfire platform code
Move the m68k ColdFire platform support code directory to be with the existing m68k platforms. Although the ColdFire is not a platform as such, we have always kept
m68k: move coldfire platform code
Move the m68k ColdFire platform support code directory to be with the existing m68k platforms. Although the ColdFire is not a platform as such, we have always kept all its support together. No reason to change that as this time.
Signed-off-by: Greg Ungerer <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]>
show more ...
|
|
Revision tags: v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5 |
|
| #
e9d9dc6a |
| 05-Nov-2012 |
Greg Ungerer <[email protected]> |
m68knommu: add support for the ColdFire 537x family of CPUs
The ColdFire 537x family is very similar internally to the ColdFire 532x family. So with just a little extra configuration we can configur
m68knommu: add support for the ColdFire 537x family of CPUs
The ColdFire 537x family is very similar internally to the ColdFire 532x family. So with just a little extra configuration we can configure and target them as well.
Signed-off-by: Greg Ungerer <[email protected]>
show more ...
|
| #
99e08374 |
| 04-Dec-2012 |
Luis Alves <[email protected]> |
m68knommu: platform code merge for 68000 core cpus
This patch merges all 68000 core cpus into one directory. There is a lot of common code in the 68328, 68EZ328 and 68VZ328 directories.
This will a
m68knommu: platform code merge for 68000 core cpus
This patch merges all 68000 core cpus into one directory. There is a lot of common code in the 68328, 68EZ328 and 68VZ328 directories.
This will also facilitate easy development of support for original stand alone MC68000 CPU machines.
Signed-off-by: Luis Alves <[email protected]> Signed-off-by: Greg Ungerer <[email protected]>
show more ...
|