"make allnoconfig" exists to ease testing of minimal configurations.
Documentation/SubmitChecklist includes a note to test with allnoconfig.
This helps catch missing dependencies on common-but-not-required
functionality, which might otherwise go unnoticed.

However, allnoconfig still leaves many symbols enabled, because they're
hidden behind CONFIG_EMBEDDED or CONFIG_EXPERT.  For instance, allnoconfig
still has CONFIG_PRINTK and CONFIG_BLOCK enabled, so drivers don't
typically get build-tested with those disabled.

To address this, introduce a new Kconfig option "allnoconfig_y", used on
symbols which only exist to hide other symbols.  Set it on CONFIG_EMBEDDED
(which then selects CONFIG_EXPERT).  allnoconfig will then disable all the
symbols hidden behind those.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Tested-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This test prevents code from being aligned around the : for easy visual
counting of bitfield lengths.

ie:
	int foo		: 1,
	int bar		: 2,
	int foobar	:29;

should be acceptable so remove the test.
Signed-off-by: NJoe Perches <joe@perches.com>
Suggested-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently the parenthesis alignment test works only on misalignments of
if statements like

	if (foo(bar,
			baz)

Expand the test to find misalignments like:

static inline int foo(int bar,
			int baz)

and

	foo(bar,
			baz);

and

	foo = bar(baz,
			qux);

Expand the $Inline keyword for __inline and __inline__ too.
Add $Inline to $Declare so it also matches "static inline <foo>".

These checks are only performed with --strict.
Signed-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>

A commit hook for the Gerrit code review server [1] inserts change
identifiers so Gerrit can track patches through multiple revisions.
These identifiers are noise in the context of the upstream kernel.
(Many Gerrit servers are private.  Even given a public instance, given
only a Change-Id, one must guess which server a change was tracked on.
Patches submitted to the Linux kernel mailing lists should be able to
stand on their own.  If it's truly useful to reference code review on a
Gerrit server, a URL is a much clearer way to do so.) Thus, issue an
error when a Change-Id line is encountered before the Signed-off-by.

1. https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msgSigned-off-by: NChristopher Covington <cov@codeaurora.org>
Cc: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revert commit 7e4915e7 ("checkpatch: add warning of future
__GFP_NOFAIL use").

There are no plans to remove __GFP_NOFAIL.

__GFP_NOFAIL exists to

a) centralise the retry-allocation-for-ever operation into the core
   allocator, which is the appropriate implementation site and

b) permit us to identify code sites which aren't handling memory
   exhaustion appropriately.

Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Networking prefers this style, so warn when it's not used.

Networking uses:

    void foo(int bar)
    {
        int baz;

        code...
   }

not

    void foo(int bar)
    {
        int baz;
        code...
    }

There are a limited number of false positives when using macros to
declare variables like:

  WARNING: networking uses a blank line after declarations
  #330: FILE: net/ipv4/inet_hashtables.c:330:
  +	int dif = sk->sk_bound_dev_if;
  +	INET_ADDR_COOKIE(acookie, saddr, daddr)
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Improve the vendor name match in vendor-prefix.txt by only matching the
exact vendor name at the beginning of lines.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Cc: Joe Perches <joe@perches.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Look for ".compatible = "foo" strings not only in .dts files, but
in .c and .h too.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Cc: Joe Perches <joe@perches.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With a compatible string like

  compatible = "foo";

checkpatch will currently try to find "foo" in vendor-prefixes.txt,
which is wrong since the vendor prefix is empty in this specific case.

Skip the vendor test if the compatible is not like

  compatible = "vendor,something";
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Cc: Joe Perches <joe@perches.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current vendor compatible check will not match vendors with dashes,
like:

  compatible="asahi-kasei"
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Reported-by: NJoe Perches <joe@perches.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current octal permissions test is very slow.

When patch ("checkpatch: add checks for constant non-octal permissions")
was added, processing time approximately tripled.

Regain almost all of the performance by not looping through all the
possible functions unless the line contains one of the functions.
Signed-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>

Modify warning message when printk is used in a patch.  It mentions to
use subsystem_dbg instead of netdev_dbg as the first preferred format of
logging debug messages.
Signed-off-by: NYogesh Chaudhari <mr.yogesh@gmail.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This test is a bit noisy and opinions seem to agree that it should not
warn in a lot more situations.

It seems people agree that:

	return (foo || bar);
and
	return foo || bar;

are both acceptable style and checkpatch should be silent about them.

For now, it warns on parentheses around a simple constant or a single
function or a ternary.

	return (foo);
	return (foo(bar));
	return (foo ? bar : baz);

The last ternary test may be quieted in the future.

Modify the deparenthesize function to only strip balanced leading and
trailing parentheses.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Cc: Monam Agarwal <monamagarwal123@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It's very common to have normal block comments for the initial comments
of a file description preface.

So for files in drivers/net and net/ don't emit a warning when the first
comment block in the file uses the normal block comment style and not
the networking block comment style.
Signed-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>

Instead of array indexing $_, use temporary variables like all the other
subroutines in the script use.
Signed-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>

static const char* arrays create smaller text as each function call does
not have to populate the array.

Emit a warning when char *arrays aren't static const and the array is
not apparently global by being declared in the first column.
Signed-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>

checkpatch could not distinguish between a variable in a struct named
jiffies and the normal jiffies.

	foo->jiffies

would emit a "Comparing jiffies" arning.

Update the $Compare variable to do a negative look-behind for "-" when
finding a ">" so that a pointer dereference like -> isn't a comparison.
Signed-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>

Change a test of $dstat to $line to avoid possibly emitting the sscanf
warning multiple times.
Signed-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>

When checking permissions, make sure 4 octal digits are used, but allow
a single 0 too.
Signed-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>

Emit a warning when using any of these __constant_<foo> forms:

	__constant_cpu_to_be[x]
	__constant_cpu_to_le[x]
	__constant_be[x]_to_cpu
	__constant_le[x]_to_cpu
	__constant_htons
	__constant_ntohs

Using any of these outside of include/uapi/ isn't preferred as using the
function without __constant_ is identical when the argument is a
constant.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

umode_t permissions are sometimes mistakenly written with decimal
constants.  Verify that numeric permissions are using octal.

Add a list of the most commonly used functions and macros that have
umode_t permissions and the argument position.

Add a $Octal type to $Constant.
Allow $LvalOrFunc to be a pointer indirection too.
Signed-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>

Checks for some function pointer return styles are too strict.  Fix
them.

Multiple spaces after function pointer return types are allowed.
	int  (*foo)(int bar)

Spaces after function pointer returns of pointer types are not required.
	int *(*foo)(int bar)
Signed-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>

Holger reported:

: The macro udelay cannot handle large values because of loss-of-precision.
:
: IMHO udelay on ARM is broken, because it also cannot work with fast
: ARM processors (where bogomips >= 3355, which is in sight now). It's
: just not broken enough that someone did something against it ...   so
: the current kludge is good enough.

Until then, warn on long udelay uses.

Also fix uses of $line that should have been $herecurr.
Signed-off-by: NJoe Perches <joe@perches.com>
Reported-by: NHolger Schurig <holgerschurig@gmail.com>
Cc: Sujith Manoharan <sujith@msujith.org>
Cc: John Linville <linville@tuxdriver.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Recent increased use of typeof() throughout the tree resulted in a
number of symbols (25 in a typical distro config of ours) not getting a
proper CRC calculated for them anymore, due to the parser in genksyms
not coping with several of these uses (interestingly in the majority of
[if not all] cases the problem is due to the use of typeof() in code
preceding a certain export, not in the declaration/definition of the
exported function/object itself; I wasn't able to find a way to address
this more general parser shortcoming).

The use of parameter_declaration is a little more relaxed than would be
ideal (permitting not just a bare type specification, but also one with
identifier), but since the same code is being passed through an actual
compiler, there's no apparent risk of allowing through any broken code.

Otoh using parameter_declaration instead of the ad hoc
"decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to
be handled rather than just plain ones and pointers to plain ones.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

x86-64 has a problem: per-cpu variables are actually represented by
their absolute offsets within the per-cpu area, but the symbols are
not emitted as absolute.  Thus kallsyms naively creates them as offsets
from _text, meaning their values change if the kernel is relocated
(especially noticeable with CONFIG_RANDOMIZE_BASE):

 $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.nokaslr
 0000000000000000 D __per_cpu_start
 0000000000004000 D gdt_page
 0000000000014280 D __per_cpu_end
 ffffffff810001c8 T _stext
 ffffffff81ee53c0 D __per_cpu_offset
 $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.kaslr1
 000000001f200000 D __per_cpu_start
 000000001f204000 D gdt_page
 000000001f214280 D __per_cpu_end
 ffffffffa02001c8 T _stext
 ffffffffa10e53c0 D __per_cpu_offset

Making them absolute symbols is the Right Thing, but requires fixes to
the relocs tool.  So for the moment, we add a --absolute-percpu option
which makes them absolute from a kallsyms perspective:

 $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # no KASLR
 0000000000000000 A __per_cpu_start
 000000000000a000 A gdt_page
 0000000000013040 A __per_cpu_end
 ffffffff802001c8 T _stext
 ffffffff8099b180 D __per_cpu_offset
 ffffffff809a3000 D __per_cpu_load
 $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # With KASLR
 0000000000000000 A __per_cpu_start
 000000000000a000 A gdt_page
 0000000000013040 A __per_cpu_end
 ffffffff89c001c8 T _stext
 ffffffff8a39d180 D __per_cpu_offset
 ffffffff8a3a5000 D __per_cpu_load
Based-on-the-original-screenplay-by: NAndy Honig <ahonig@google.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NKees Cook <keescook@chromium.org>

This refactors the address range checks to be generalized instead of
specific to text range checks, in preparation for other range checks.
Also extracts logic for "is the symbol absolute" into a function.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

PHONY target is more suitable for "build_docproc" target.

Because PHONY targets are always executed, they do not
have to take FORCE as a prerequisite.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Commit 78551277: "Input: i8042 - add PNP modaliases" had a bug, where the
second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
the modaliases being exposed.

This fixes the problem by including the name of the device_id table in the
__mod_*_device_table alias, allowing us to export several device_id tables
per module.
Suggested-by: NKay Sievers <kay@vrfy.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NTom Gundersen <teg@jklm.no>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Revert the recently applied 0f55159d ("kallsyms: fix absolute
addresses for kASLR").  Kees said

: This got NAKed, please don't apply -- this patch works for x86 and
: ARM, but may cause problems for others:
:
: https://lkml.org/lkml/2014/2/24/718

It appears that Kees will be fixing all this up for 3.15.

Cc: Andy Honig <ahonig@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently symbols that are absolute addresses are incorrectly displayed
in /proc/kallsyms if the kernel is loaded with kASLR.

The problem was that the scripts/kallsyms.c file which generates the
array of symbol names and addresses uses an relocatable value for all
symbols, even absolute symbols.  This patch fixes that.

Several kallsyms output in different boot states for comparison:

  $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.nokaslr
  0000000000000000 D __per_cpu_start
  0000000000014280 D __per_cpu_end
  ffffffff810001c8 T _stext
  $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr1
  000000001f200000 D __per_cpu_start
  000000001f214280 D __per_cpu_end
  ffffffffa02001c8 T _stext
  $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr2
  000000000d400000 D __per_cpu_start
  000000000d414280 D __per_cpu_end
  ffffffff8e4001c8 T _stext
  $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr-fixed
  0000000000000000 D __per_cpu_start
  0000000000014280 D __per_cpu_end
  ffffffffadc001c8 T _stext
Signed-off-by: NAndy Honig <ahonig@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

LZ4 as implemented in the kernel differs from the default method now
used by the reference implementation of LZ4.  Until the in-kernel method
is updated to support the new default, passing the legacy flag (-l) to
the compressor is necessary.  Without this flag the kernel-generated,
LZ4-compressed initramfs is junk.

Kyungsik said:

: It seems that lz4 supports legacy format with the same option as lz4c
: does.  Just looking at the first few bytes of lz4 compressed image, we can
: see whether it is new format or not.
:
: It shows new format magic number without this patch.  New format magic
: number is 0x184d2204.
:
: $ hexdump -C ./initramfs_data.cpio.lz4 |more
: 00000000  04 22 4d 18 64 70 b9 69 (Little Endian)
: ...
:
: Currently kernel supports legacy format only.
Signed-off-by: NDaniel M. Weeks <dan@danweeks.net>
Cc: Michal Marek <mmarek@suse.cz>
Acked-by: NKyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.

This commit adds a new 'dtbs_install' make target which copies all of
the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
set before calling make to change the default install directory. If not
set then it defaults to:

	$INSTALL_PATH/dtbs/$KERNELRELEASE.

This is done to keep dtbs from different kernel versions separate until
things have settled down.  Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo.  Users will need to upgrade install scripts at that
time.

v7: (reworked by Grant Likely)
- Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
  that each dtb install could have a separate target and be reported as
  part of the make output.
- Fixed dependency problem to ensure $KERNELRELEASE is calculated before
  attempting to install
- Removed option to call external script. Copying the files should be
  sufficient and a build system can post-process the install directory.
  Despite the fact an external script is used for installing the kernel,
  I don't think that is a pattern that should be encouraged. I would
  rather see buildroot type tools post process the install directory to
  rename or move dtb files after installing to a staging directory.
  - Plus it is easy to add a hook after the fact without blocking the
    rest of this feature.
- Move the helper targets into scripts/Makefile.lib with the rest of the
  common dtb rules
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>

The testcase data is usable by any platform. This patch moves it into
the drivers/of directory so it can be included by any architecture.

Using the test cases requires manually adding #include <testcases.dtsi>
to the end of the boards .dtsi file and enabling CONFIG_OF_SELFTEST. Not
pretty though. A useful project would be to make the testcase code
easier to execute.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

The x86 CPU feature modalias handling existed before it was reimplemented
generically. This patch aligns the x86 handling so that it
(a) reuses some more code that is now generic;
(b) uses the generic format for the modalias module metadata entry, i.e., it
    now uses 'cpu:type:x86,venVVVVfamFFFFmodMMMM:feature:,XXXX,YYYY' instead of
    the 'x86cpu:vendor:VVVV:family:FFFF:model:MMMM:feature:,XXXX,YYYY' that was
    used before.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds support for advertising optional CPU features over udev
using the modalias, and for declaring compatibility with/dependency upon
such a feature in a module.

The mapping between feature numbers and actual features should be provided
by the architecture in a file called <asm/cpufeature.h> which exports the
following functions/macros:
- cpu_feature(FEAT), a preprocessor macro that maps token FEAT to a
  numeric index;
- bool cpu_have_feature(n), returning whether this CPU has support for
  feature #n;
- MAX_CPU_FEATURES, an upper bound for 'n' in the previous function.

The feature can then be enabled by setting CONFIG_GENERIC_CPU_AUTOPROBE
for the architecture.

For instance, a module that registers its module init function using

  module_cpu_feature_match(FEAT_X, module_init_function)

will be probed automatically when the CPU's support for the 'FEAT_X'
feature is advertised over udev, and will only allow the module to be
loaded by hand if the 'FEAT_X' feature is supported.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add processing for normally encountered thumb relocation types so that
section mismatches will be detected.

Comment from Rusty Russell follows:

Happiest for this to go through an ARM tree, so:
Signed-off-by: NDavid A. Long <dave.long@linaro.org>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

- Don't warn about LTO marker symbols. modpost runs before
the linker, so the module is not necessarily LTOed yet.
- Don't complain about .gnu.lto* sections
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1391846481-31491-13-git-send-email-ak@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

The asm-offset.c technique to fish data out of the assembler file
does not work with LTO. Just disable for the asm-offset.c build.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1391846481-31491-11-git-send-email-ak@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

For LTO we need to run the link step with gcc, not ld.
Since there are a lot of linker options passed to it, add a gcc-ld wrapper
that wraps them as -Wl,
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1391846481-31491-10-git-send-email-ak@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>