History log of /linux-6.15/arch/m68k/Makefile (Results 1 – 25 of 52)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123