The uncore subsystem in Haswell-EP is similar to Sandy/Ivy
Bridge-EP. There are some differences in config register
encoding and pci device IDs. The Haswell-EP uncore also
supports a few new events. Add the Haswell-EP driver to
the snbep split driver.
Signed-off-by: NYan, Zheng <zheng.z.yan@intel.com>
[ Add missing break. Add imc events. Add cbox nc/isoc/c6. ]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1409872109-31645-2-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Use the newly added Broadwell cache event list for Haswell too.
All Haswell and Broadwell events and offcore masks used in these lists
are identical.

However Haswell is very different from the Sandy Bridge
list that was used previously. That fixes a wide range of mis-counting
cache events.

The node events are now only for retired memory events, so prefetching
and speculative memory accesses are not included. They are PEBS
capable now, which makes it much easier to sample for them, plus it's
possible to create address maps with -d.

The prefetch events are gone now. They way the hardware counts
them is very misleading (some prefetches included, others not), so
it seemed best to leave them out.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1409683455-29168-5-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

On Broadwell INST_RETIRED.ALL cannot be used with any period
that doesn't have the lowest 6 bits cleared. And the period
should not be smaller than 128.

Add a new callback to enforce this, and set it for Broadwell.

This is erratum BDM57 and BDM11.

How does this handle the case when an app requests a specific
period with some of the bottom bits set

The apps thinks it is sampling at X occurences per sample, when it is
in fact at X - 63 (worst case).

Short answer:

Any useful instruction sampling period needs to be 4-6 orders
of magnitude larger than 128, as an PMI every 128 instructions
would instantly overwhelm the system and be throttled.
So the +-64 error from this is really small compared to the
period, much smaller than normal system jitter.

Long answer:

<write up by Peter:>

IFF we guarantee perf_event_attr::sample_period >= 128.

Suppose we start out with sample_period=192; then we'll set period_left
to 192, we'll end up with left = 128 (we truncate the lower bits). We
get an interrupt, find that period_left = 64 (>0 so we return 0 and
don't get an overflow handler), up that to 128. Then we trigger again,
at n=256. Then we find period_left = -64 (<=0 so we return 1 and do get
an overflow). We increment with sample_period so we get left = 128. We
fire again, at n=384, period_left = 0 (<=0 so we return 1 and get an
overflow). And on and on.

So while the individual interrupts are 'wrong' we get then with
interval=256,128 in exactly the right ratio to average out at 192. And
this works for everything >=128.

So the num_samples*fixed_period thing is still entirely correct +- 127,
which is good enough I'd say, as you already have that error anyhow.

So no need to 'fix' the tools, al we need to do is refuse to create
INST_RETIRED:ALL events with sample_period < 128.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
Cc: Mark Davies <junk@eslaf.co.uk>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1409683455-29168-4-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Add Broadwell support for Broadwell Client to perf.  This is very
similar to Haswell.  It uses a new cache event table, because there
were various changes there.

The constraint list has one new event that needs to be handled over
Haswell.

The PEBS event list is the same, so we reuse Haswell's.

[fengguang.wu: make intel_bdw_event_constraints[] static]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1409683455-29168-3-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Add names for each Haswell model as requested by Peter.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1409683455-29168-2-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

71 is a Broadwell, not a Haswell. The model number was added
by mistake earlier.

Remove it for now, until it can be re-added later with
real Broadwell support.

In practice it does not cause a lot of issues because the Broadwell
PMU is very similar to Haswell, but some details were wrong,
and it's better to handle it correctly.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Link: http://lkml.kernel.org/r/1409683455-29168-1-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

The new split Intel uncore driver code that recently went
into tip added a section mismatch, which the build process
complains about.

uncore_pmu_register() can be called from uncore_pci_probe,()
which is not __init and can be called from pci driver ->probe.
I'm not fully sure if it's actually possible to call the probe
function later, but it seems safer to mark uncore_pmu_register
not __init.

This also fixes the warning.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1409332858-29039-1-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

A few of the initialization functions are missing the __init annotation.
Fix this and thereby allow ~680 additional bytes of code to be released
after initialization.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/1409071785-26015-1-git-send-email-minipli@googlemail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The atmel,clk-divisors property is taking 4 divisors, if less are
provided, the clock registration will fail.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Actually register clocks from device tree when using the common clock
framework.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
[nicolas.ferre@atmel.com: add at91 to function name]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The at91sam9g20 SOC uses its own pllb implementation which is different
from the one inherited from at91sam9260 SOC.
Signed-off-by: NGaël PORTAY <gael.portay@gmail.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

DRA7 evm REV G and later boards uses a vtt regulator for DDR3
termination and this is controlled by gpio7_11. This gpio is
configured in boot loader. gpio7_11, which is only available only on
Pad A22, in previous boards, is connected only to an unused pad on
expansion connector EXP_P3 and is safe to be muxed as GPIO on all
DRA7-evm versions (without a need to spin off another dts file).

Since gpio7_11 is used to control VTT and should not be reset or kept
in idle state during boot up else VTT will be disconnected and DDR
gets corrupted. So, as part of this change, mark gpio7 as no-reset and
no-idle on init.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
	v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 |
		cut -d 'x' -f2|tr [a-z] [A-Z]`;
	HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`;
	echo "$HEX ===> $line";
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.

Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Both QSPI and GPMC-NAND share the same Pin (A8) from the SoC for Chip Select
functionality. So both can't be enabled simultaneously.

Disable QSPI node to prevent the pin conflict as well as
be similar to 3.12 release.

CC: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For NAND read & write wait pin monitoring must be kept disabled as the
wait pin is only used to indicate NAND device ready status and not to
extend each read/write cycle.

So don't print a warning if wait pin is specified while read/write
monitoring is not in the device tree.

Sanity check wait pin number irrespective if read/write monitoring is
set or not.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

Add gpmc wait pin information as the NAND uses wait pin 0
for device ready indication.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

This patch also gets rid of the below warning when NAND is
accessed for the first time.

omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

am437x-gp-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

am43x-epos-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Size should be 64KiB instead of 92KiB.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On the GP EVM, the ambient light sensor is limited to 100KHz on the
I2C bus.

So use 100kHz for I2C on the GP EVM due to this limitation on the
ambient light sensor.
Reported-by: NAparna Balasubramanian <aparnab@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The 8th NAND partition should be named "NAND.u-boot-env.backup1"
instead of "NAND.u-boot-env". This is to be consistent with other
TI boards as well as u-boot.

CC: Pekon Gupta <pekon@pek-sem.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The I2C3 pins are taken from pads E21 (GPIO6_14) and
F20 (GPIO6_15). Use the right pinmux register and mode.

Also set the I2C3 bus frequency to a safer 400KHz than
3.4Mhz.

CC: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Structure name and variable name were erroneously interchanged
Signed-off-by: NNoam Camus <noamc@ezchip.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
[ Also removed pointless cast from "void *".  - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

fc95ca72 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.

However, the size argument passed to memset is computed from a signed value
and its signed bit is extended by the cast the compiler is doing. This lead
to extremely large size value when dealing with order value >= 31, and
almost all the memory following the allocated space is cleaned. As a
consequence, the system is panicing and may even fail spawning the kdump
kernel.

This fix makes use of an unsigned value for the memset's size argument to
avoid sign extension. Among this fix, another shift operation which may
lead to signed extended value too is also fixed.

Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Analogous to commit 8858d88a
that fixed commit 70b41abc
"ARM: ux500: move MSP pin control to the device tree"
accidentally activated MSP2, giving rise to a boot scroll
scream as the kernel attempts to probe a driver for it and
fails to obtain DMA channel 14.

For some reason I forgot to fix this on the Snowball. Fix
this up by marking the node disabled again.

Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

commit 0944fe3f ("s390/mm: implement software referenced bits")
triggered another paging/storage key corruption. There is an
unhandled invalid->valid pte change where we have to set the real
storage key from the pgste.
When doing paging a guest page might be swapcache or swap and when
faulted in it might be read-only and due to a parallel scan old.
An do_wp_page will make it writeable and young. Due to software
reference tracking this page was invalid and now becomes valid.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Cc: stable@vger.kernel.org # v3.12+

Since 3.12 or more precisely  commit 0944fe3f ("s390/mm:
implement software referenced bits") guest storage keys get
corrupted during paging. This commit added another valid->invalid
translation for page tables - namely ptep_test_and_clear_young.
We have to transfer the storage key into the pgste in that case.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Cc: stable@vger.kernel.org # v3.12+

It turns out that vendors are relying on the format of /proc/cpuinfo,
and we've even spotted out-of-tree hacks attempting to make it look
identical to the format used by arch/arm/. That means we can't afford to
churn this interface in mainline, so revert the recent reformatting of
the file for arm64 pending discussions on the list to find out what
people actually want.

This reverts commit d7a49086.
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Now arm64 defers reloading FPSIMD state, but this optimization also
introduces the bug after cpu resume back from low power mode.

The reason is after the cpu has been powered off, s/w need set the
cpu's fpsimd_last_state to NULL so that it will force to reload
FPSIMD state for the thread, otherwise there has the chance to meet
the condition for both the task's fpsimd_state.cpu field contains the
id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable
points to the task's fpsimd_state, so finally kernel will skip to reload
the context during it return back to userland.
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLeo Yan <leoy@marvell.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

unicore32 builds fail with

  arch/unicore32/kernel/signal.c: In function ‘setup_frame’:
  arch/unicore32/kernel/signal.c:257: error: ‘usig’ undeclared (first use in this function)
  arch/unicore32/kernel/signal.c:279: error: ‘usig’ undeclared (first use in this function)
  arch/unicore32/kernel/signal.c: In function ‘handle_signal’:
  arch/unicore32/kernel/signal.c:306: warning: unused variable ‘tsk’
  arch/unicore32/kernel/signal.c: In function ‘do_signal’:
  arch/unicore32/kernel/signal.c:376: error: implicit declaration of function ‘get_signsl’
  make[1]: *** [arch/unicore32/kernel/signal.o] Error 1
  make: *** [arch/unicore32/kernel/signal.o] Error 2

Bisect points to commit 649671c9 ("unicore32: Use get_signal()
signal_setup_done()").

This code never even compiled.  Reverting the patch does not work, since
previously used functions no longer exist, so try to fix it up.  Compile
tested only.

Fixes: 649671c9 ("unicore32: Use get_signal() signal_setup_done()")
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With ARCH_VEXPRESS_SPC option, kernel build has the following
warning:

arch/arm/mach-vexpress/spc.c: In function ‘ve_spc_clk_init’:
arch/arm/mach-vexpress/spc.c:431:38: warning: array subscript is below array bounds [-Warray-bounds]
  struct ve_spc_opp *opps = info->opps[cluster];
                                      ^
since 'cluster' maybe '-1' in UP system. This patch does a active
checking to fix this issue.
Signed-off-by: NAlex Shi <alex.shi@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Without this patch the kexec-purgatory.c and purgatory.ro files are not
removed after make mrproper.
Signed-off-by: NMichael Welling <mwelling@ieee.org>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix building errors occuring due to a missing export of
flush_icache_range() in

kisskb.ellerman.id.au/kisskb/buildresult/11677809/

ERROR: "flush_icache_range" [drivers/misc/lkdtm.ko] undefined!
Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Vineet Gupta <vgupta@synopsys.com>	[arc]
Acked-by: Richard Kuo <rkuo@codeaurora.org>	[hexagon]
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Chris Zankel <chris@zankel.net>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>	[xtensa]
Cc: Noam Camus <noamc@ezchip.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Zhigang Lu <zlu@tilera.com>		[tile]
Cc: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Thomas reported that build of x86_64 kernel was failing for him.  He is
using 32bit tool chain.

Problem is that while compiling purgatory, I have not specified -m64
flag.  And 32bit tool chain must be assuming -m32 by default.

Following is error message.

(mini) [~/work/linux-2.6] make
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/config/kernel.release
  UPD     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  CC      arch/x86/purgatory/purgatory.o
arch/x86/purgatory/purgatory.c:1:0: error: code model 'large' not supported in
the 32 bit mode

Fix it by explicitly passing appropriate -m64/-m32 build flag for
purgatory.
Reported-by: NThomas Glanzmann <thomas@glanzmann.de>
Tested-by: NThomas Glanzmann <thomas@glanzmann.de>
Suggested-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

New system call depends on crypto.  As it did not have a separate config
option, CONFIG_KEXEC was modified to select CRYPTO and CRYPTO_SHA256.

But now previous patch introduced a new config option for new syscall.
So CONFIG_KEXEC does not require crypto.  Remove that dependency.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently new system call kexec_file_load() and all the associated code
compiles if CONFIG_KEXEC=y.  But new syscall also compiles purgatory
code which currently uses gcc option -mcmodel=large.  This option seems
to be available only gcc 4.4 onwards.

Hiding new functionality behind a new config option will not break
existing users of old gcc.  Those who wish to enable new functionality
will require new gcc.  Having said that, I am trying to figure out how
can I move away from using -mcmodel=large but that can take a while.

I think there are other advantages of introducing this new config
option.  As this option will be enabled only on x86_64, other arches
don't have to compile generic kexec code which will never be used.  This
new code selects CRYPTO=y and CRYPTO_SHA256=y.  And all other arches had
to do this for CONFIG_KEXEC.  Now with introduction of new config
option, we can remove crypto dependency from other arches.

Now CONFIG_KEXEC_FILE is available only on x86_64.  So whereever I had
CONFIG_X86_64 defined, I got rid of that.

For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
"depends on CRYPTO=y".  This should be safer as "select" is not
recursive.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Tested-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at
mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels:
where zap_pte_range() checks page->mapping to see if PageAnon(page).

Those addresses fit struct pages for pfns d2001 and d2000, and in each
dump a register or a stack slot showed d2001730 or d2000730: pte flags
0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has
a hole between cfffffff and 100000000, which would need special access.

Commit c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on
the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL
pte no longer passes the pte_special() test, so zap_pte_range() goes on
to try to access a non-existent struct page.

Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to
complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE).  A
hint that this was a problem was that c46a7c81 added pte_numa() test
to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast
path: This was papering over a pte_special() snag when the zero page was
encountered during zap.  This patch reverts vm_normal_page() to how it
was before, relying on pte_special().

It still appears that this patch may be incomplete: aren't there other
places which need to be handling PROTNONE along with PRESENT?  For
example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a
PROT_NONE area, that would make it pte_special().  This is side-stepped
by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there
are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be
interesting.

Fixes: c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels")
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Tested-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NHugh Dickins <hughd@google.com>
Signed-off-by: NMel Gorman <mgorman@suse.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: <stable@vger.kernel.org>	[3.16]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>