I was not seeing my linker flags getting added when using ld-option when
cross compiling with Clang. Upon investigation, this seems to be due to
a difference in how GCC vs Clang handle cross compilation.

GCC is configured at build time to support one backend, that is implicit
when compiling.  Clang is explicit via the use of `-target <triple>` and
ships with all supported backends by default.

GNU Make feature test macros that compile then link will always fail
when cross compiling with Clang unless Clang's triple is passed along to
the compiler. For example:

$ clang -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
unknown architecture of input file `temp.o' is incompatible with
aarch64 output
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to
0000000000400078
$ echo $?
1

$ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00000000004002e4
$ echo $?
0

This causes conditional checks that invoke $(CC) without the target
triple, then $(LD) on the result, to always fail.
Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The cache files are only cleaned away by "make clean".  If you continue
incremental builds, the cache files will grow up little by little.
It is not a big deal in general use cases because compiler flags do not
change quite often.

However, if you do build-test for various architectures, compilers, and
kernel configurations, you will end up with huge cache files soon.

When the cache file exceeds 1000 lines, shrink it down to 500 by "tail".
The Least Recently Added lines are cut. (not Least Recently Used)
I hope it will work well enough.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

While timing a "no-op" build of the kernel (incrementally building the
kernel even though nothing changed) in the Chrome OS build system I
found that it was much slower than I expected.

Digging into things a bit, I found that quite a bit of the time was
spent invoking the C compiler even though we weren't actually building
anything.  Currently in the Chrome OS build system the C compiler is
called through a number of wrappers (one of which is written in
python!) and can take upwards of 100 ms to invoke even if we're not
doing anything difficult, so these invocations of the compiler were
taking a lot of time.  Worse the invocations couldn't seem to take
advantage of the multiple cores on my system.

Certainly it seems like we could make the compiler invocations in the
Chrome OS build system faster, but only to a point.  Inherently
invoking a program as big as a C compiler is a fairly heavy
operation.  Thus even if we can speed the compiler calls it made sense
to track down what was happening.

It turned out that all the compiler invocations were coming from
usages like this in the kernel's Makefile:

KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)

Due to the way cc-option and similar statements work the above
contains an implicit call to the C compiler.  ...and due to the fact
that we're storing the result in KBUILD_CFLAGS, a simply expanded
variable, the call will happen every time the Makefile is parsed, even
if there are no users of KBUILD_CFLAGS.

Rather than redoing this computation every time, it makes a lot of
sense to cache the result of all of the Makefile's compiler calls just
like we do when we compile a ".c" file to a ".o" file.  Conceptually
this is quite a simple idea.  ...and since the calls to invoke the
compiler and similar tools are centrally located in the Kbuild.include
file this doesn't even need to be super invasive.

Implementing the cache in a simple-to-use and efficient way is not
quite as simple as it first sounds, though.  To get maximum speed we
really want the cache in a format that make can natively understand
and make doesn't really have an ability to load/parse files. ...but
make _can_ import other Makefiles, so the solution is to store the
cache in Makefile format.  This requires coming up with a valid/unique
Makefile variable name for each value to be cached, but that's
solvable with some cleverness.

After this change, we'll automatically create a ".cache.mk" file that
will contain our cached variables.  We'll load this on each invocation
of make and will avoid recomputing anything that's already in our
cache.  The cache is stored in a format that it shouldn't need any
invalidation since anything that might change should affect the "key"
and any old cached value won't be used.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NIngo Molnar <mingo@kernel.org>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

$(kbuild-file) and Kbuild.include are included before the default
target "all".

We will add a target into Kbuild.include.  In advance, add a forward
declaration of the default target.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS.
Remove KBUILD_SUBDIR_{AS,CC}FLAGS.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NCao jin <caoj.fnst@cn.fujitsu.com>

It has:
1. Move comments close to what it want to comment.
2. Comments cleanup & improvement.
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 5e538790 ("sparc,sparc64: unify Makefile"), hdr-arch
and SRCARCH always match.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

This script does not need to create .version; it will be created by
scripts/link-vmlinux.sh later.  Clean-up the code slightly.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 1f2bfbd0 ("kbuild: link of vmlinux moved to a
script"), it is easy to increment .version without using a temporary
file .old_version.

I do not see anybody who creates the .tmp_version.  Probably it is a
left-over of commit 4e25d8bb ("[PATCH] kbuild: adjust .version
updating").  Just remove it.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The kbuild bot occasionally reports warnings like:

  drivers/scsi/pcmcia/aha152x_core.o: warning: objtool: seldo_run()+0x130: unreachable instruction

These warnings are always with GCC 4.4.  That version of GCC sometimes
places unreachable instructions after calls to noreturn functions.

The unreachable warnings aren't very important anyway.  Just ignore them
for old versions of GCC.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
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/bc89b807d965b98ec18a0bb94f96a594bd58f2f2.1506551639.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Update dtx_diff include paths in the same manner as:
commit b12869a8 ("of: remove drivers/of/testcase-data from
include search path for CPP"), commit 5ffa2aed ("of: remove
arch/$(SRCARCH)/boot/dts from include search path for CPP"), and
commit 50f9ddaf ("of: search scripts/dtc/include-prefixes path
for both CPP and DTC").

Remove proposed include path kernel/dts/, which was never implemented
for the dtb build.

For the diff case, each source file is compiled separately.  For
each of those compiles, provide the location of the source file
as an include path, not the location of both source files.
Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
Signed-off-by: NRob Herring <robh@kernel.org>

The "Release:" field of the spec file is determined based on the
.version file.

However, the .version file is not copied to the source tar file.
So, when we build the kernel from the source package, the UTS_VERSION
always indicates #1.  This does not match with "rpm -q".

The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
Please note the kernel has already been built before the spec file is
created.  Currently, mkspec invokes mkversion.  This script returns an
incremented version.  So, the "Release:" field of the spec file is
greater than the version in the kernel by one.

For the source package build (where .version file is missing), we can
give KBUILD_BUILD_VERSION=%{release} to the build command.

For the binary package build, we can simply read out the .version file
because it contains the version number that was used for building the
kernel image.

We can remove scripts/mkversion because scripts/package/Makefile need
not touch the .version file.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including the firmware install command.

So, the firmware package does not make sense any more.  Remove it.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NRiku Voipio <riku.voipio@linaro.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including "make firmware_install".

Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
the error:

  make[2]: *** No rule to make target `firmware_install'.  Stop.

Commit df85b2d7 ("firmware: Restore support for built-in firmware")
restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
is out of the scope of "make firmware_install".  So, the right thing to
do is to kill the use of "make firmware_install".

Fixes: 5620a0d1 ("firmware: delete in-kernel firmware")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

The previous commit spotted that "Tarball successfully created ..."
is displayed even if the "tar" command returns error code because
it is followed by "| ${compress}".

Let the build fail instead of printing the successful message since
if the "tar" command fails, the output may not be what users expect.

Avoid the use of the pipe.  While we are here, refactor the script
removing the use of sub-shell, ${compress}, ${file_ext}.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

$tmpdir/lib is created by "make modules_install".  It does not exist
if CONFIG_MODULES is disabled, then tar reports the following messages:

tar: lib: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

I removed all the gperf use, but not the Makefile rules.  Sam Ravnborg
says I get bonus points for cleaning this up.  I'll hold him to it.
Requested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Unlike all other types, LONG_LINE, LONG_LINE_COMMENT and LONG_LINE_STRING
are passed to WARN() through a variable.  This causes the parser in
list_types() to miss them and consequently they are not present in the
output of --list-types.

Additionally, types TYPO_SPELLING, FSF_MAILING_ADDRESS and AVOID_BUG are
passed with a variable level, causing the parser to miss them too.

So modify the regex to also catch these special cases.

Link: http://lkml.kernel.org/r/20170902175610.7e4a7c9d@endymion
Fixes: 3beb42ec ("checkpatch: add --list-types to show message types to show or ignore")
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The variable name "$msg_type" is sometimes used to set the message type,
and sometimes used to set the message level.  This works but is kind of
confusing.  Use "$msg_level" in the latter case instead, to make the code
clearer.

Link: http://lkml.kernel.org/r/20170902175345.175db33a@endymionSigned-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Link: http://lkml.kernel.org/r/20170902175249.15bb77f2@endymionSigned-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

An if statement test like
	if ((foo == bar) && (baz != qux))
can arguably be better written without the parentheses as
	if (foo == bar && baz != qux)

Add a test to find these cases.

Link: http://lkml.kernel.org/r/dcd0561ddd0fa43c51a420d53b550d738bf42001.1502734458.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I had stupidly missed one special use of 'is_reserved_word()' when I
converted the code to avoid gperf.

I had changed that function to return the token ID directly rather than
a pointer to the token descriptor structure, but that meant that the
test for "is this a reserved word" changed from checking the return
value against NULL, to checking that it wasn't negative.

And while I had converted the main token parser over, I missed the
special case of the typeof phrase handling.  And since our dependency
chain for genksyms does not include the genksyms program itself
changing, my kernel rebuild didn't show the problem.

Fixes: bb3290d9 ("Remove gperf usage from toolchain")
Reported-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Only the media PDF book was requiring adjustbox, in order to
scale big tables. That worked pretty good with Sphinx versions
1.4 and 1.5, but Spinx 1.6 changed the way tables are produced,
by introducing some weird macros before tabulary.
That causes adjustbox to fail. So, it can't be used anymore,
and its usage was removed from the media book.

So, let's remove it from conf.py and sphinx-pre-install.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

There is code duplication between sec_name() and sech_name().  Simplify
sec_name() by re-using sech_name().  Also, move them up to remove the
forward declaration of sec_name().

Link: http://lkml.kernel.org/r/1502248721-22009-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Jessica Yu <jeyu@redhat.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Previously, .config was used in buildtar script regardless of the value of
KCONFIG_CONFIG.
Signed-off-by: NNicolas Porcel <nicolasporcel06@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

We have lots of dead defines and macros in drivers, lets offer users a way
to detect and eventually remove them.
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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>

dtc uses an incorrect format specifier for printing a uint64_t value.
uint64_t may be either 'unsigned long' or 'unsigned long long' depending
on the host architecture.

Fix this by using %llx and casting to unsigned long long, which ensures
that we always have a wide enough variable to print 64 bits of hex.

    HOSTCC  scripts/dtc/checks.o
  scripts/dtc/checks.c: In function 'check_simple_bus_reg':
  scripts/dtc/checks.c:876:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'uint64_t' [-Wformat=]
    snprintf(unit_addr, sizeof(unit_addr), "%zx", reg);
    ^
  scripts/dtc/checks.c:876:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'uint64_t' [-Wformat=]

Link: http://lkml.kernel.org/r/20170829222034.GJ20805@n2100.armlinux.org.uk
Fixes: 828d4cdd ("dtc: check.c fix compile error")
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Reported by Johannes Berg [1].  Problem here: function
process_proto_type() concatenates the striped lines of declaration
without any whitespace. A one-liner of::

 struct something {
       struct foo
       bar;
       };

has to be::

 struct something {struct foo bar;};

Without the patching process_proto_type(), the result missed the space
between 'foo' and 'bar'::

 struct something {struct foobar;};

Bugfix of process_proto_type() brings next error when blank lines
between enum declaration::

 warning: Enum value ' ' not described in enum 'foo'

Problem here: dump_enum() does not strip leading whitespaces from
the concatenated string (with the new additional space from
process_proto_type).

[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg12410.htmlSigned-off-by: NMarkus Heiser <markus.heiser@darmarit.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit d5d332d3 ("devicetree: Move include prefixes from
arch to separate directory"), cross-arch DT reference works well,
but only for CPP style #include directives.

It makes as much sense to share DT between different architectures
by using DTC's /include/ directives.

So, scripts/dtc/include-prefixes should be passed to both CPP and DTC.
I refactored Makefile.lib a bit to not repeat the same path.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Having arch/$(SRCARCH)/boot/dts as an include search path is not
very useful these days because some architectures such as ARM64,
MIPS have no DT in this directory.  Instead, they have DT in vendor
sub-directories.

With some DT files in ARM and PowerPC fixed, we can now drop this
include search path.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NRob Herring <robh@kernel.org>

This search path was added by commit b5190516 ("of: Move testcase
FDT data into drivers/of").  At that time, it was needed for platform
DT files to include testcase data.

It became unnecessary when commit ae9304c9 ("Adding selftest
testdata dynamically into live tree") introduced dynamic addition of
testcase data, but it missed to delete this search path.

Moreover, the directory drivers/of/testcase-data does not exist since
commit 19fd7487 ("of/unittest: Rename selftest.c to unittest.c").
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NRob Herring <robh@kernel.org>

This definition in Makefile.dtbinst:

    export dtbinst-root ?= $(obj)

should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories.  However some shells,
including dash, will not pass through environment variables whose name
includes a hyphen.  Usually GNU make does not use a shell to recurse,
but if e.g. $(srctree) contains '~' it will use a shell here.

Rename the variable to dtbinst_root.

References: https://bugs.debian.org/833561
Fixes: 323a028di ("dts, kbuild: Implement support for dtb vendor subdirs")
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

It turns out that gperf-3.1 changed types in the generated code in ways
that aren't even trivially detectable without having to generate a test-file.

It's just not worth using tools and libraries from clowns that don't
understand or care about compatibility.  So get rid of gperf.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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>

Allow any number of command line arguments to match either the
section header or the section contents and create new files.

Create MAINTAINERS.new and SECTION.new.

This allows scripting of the movement of various sections from
MAINTAINERS.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of reading STDIN and writing STDOUT, use specific filenames of
MAINTAINERS and MAINTAINERS.new.

Use hash references instead of global hash %hash so future modifications
can read and write specific hashes to split up MAINTAINERS into multiple
files using a script.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>