When booting a vcpu using PSCI, make sure we start it with the
endianness of the caller. Otherwise, secondaries can be pretty
unhappy to execute a BE kernel in LE mode...

This conforms to PSCI spec Rev B, 5.13.3.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Do the necessary byteswap when host and guest have different
views of the universe. Actually, the only case we need to take
care of is when the guest is BE. All the other cases are naturally
handled.

Also be careful about endianness when the data is being memcopy-ed
from/to the run buffer.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The KVM PSCI code blindly assumes that vcpu_id and MPIDR are
the same thing. This is true when vcpus are organized as a flat
topology, but is wrong when trying to emulate any other topology
(such as A15 clusters).

Change the KVM PSCI CPU_ON code to look at the MPIDR instead
of the vcpu_id to pick a target CPU.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Now that the KVM/arm code knows about affinity, remove the hard
limit of 4 vcpus per VM.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

The L2CTLR register contains the number of CPUs in this cluster.

Make sure the register content is actually relevant to the vcpu
that is being configured by computing the number of cores that are
part of its cluster.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

In order to be able to support more than 4 A7 or A15 CPUs,
we need to fix the MPIDR computing to reflect the fact that
both A15 and A7 can only exist in clusters of at most 4 CPUs.

Fix the MPIDR computing to allow virtual clusters to be exposed
to the guest.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Support transparent huge pages in KVM/ARM and KVM/ARM64.  The
transparent_hugepage_adjust is not very pretty, but this is also how
it's solved on x86 and seems to be simply an artifact on how THPs
behave.  This should eventually be shared across architectures if
possible, but that can always be changed down the road.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Support huge pages in KVM/ARM and KVM/ARM64.  The pud_huge checking on
the unmap path may feel a bit silly as the pud_huge check is always
defined to false, but the compiler should be smart about this.

Note: This deals only with VMAs marked as huge which are allocated by
users through hugetlbfs only.  Transparent huge pages can only be
detected by looking at the underlying pages (or the page tables
themselves) and this patch so far simply maps these on a page-by-page
level in the Stage-2 page tables.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Update comments to reflect what is really going on and add the TWE bit
to the comments in kvm_arm.h.

Also renames the function to kvm_handle_wfx like is done on arm64 for
consistency and uber-correctness.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.

This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn't a typo.

The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensures that other vpus will get a scheduling
boost, allowing the lock to be released more quickly. Also, using
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
when the VM is severely overcommited.

Quick test to estimate the performance: hackbench 1 process 1000

2xA15 host (baseline):	1.843s

2xA15 guest w/o patch:	2.083s
4xA15 guest w/o patch:	80.212s
8xA15 guest w/o patch:	Could not be bothered to find out

2xA15 guest w/ patch:	2.102s
4xA15 guest w/ patch:	3.205s
8xA15 guest w/ patch:	6.887s

So we go from a 40x degradation to 1.5x in the 2x overcommit case,
which is vaguely more acceptable.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

We will use that in the later patch to find the kvm ops handler

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>

Update comments to reflect what is really going on and add the TWE bit
to the comments in kvm_arm.h.

Also renames the function to kvm_handle_wfx like is done on arm64 for
consistency and uber-correctness.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.

This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn't a typo.

The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensures that other vpus will get a scheduling
boost, allowing the lock to be released more quickly. Also, using
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
when the VM is severely overcommited.

Quick test to estimate the performance: hackbench 1 process 1000

2xA15 host (baseline):	1.843s

2xA15 guest w/o patch:	2.083s
4xA15 guest w/o patch:	80.212s
8xA15 guest w/o patch:	Could not be bothered to find out

2xA15 guest w/ patch:	2.102s
4xA15 guest w/ patch:	3.205s
8xA15 guest w/ patch:	6.887s

So we go from a 40x degradation to 1.5x in the 2x overcommit case,
which is vaguely more acceptable.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

This reverts commit 10bcdfb8. There is
no consensus on the bindings for the reserved memory, so the code for
handing it will be reverted.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

The KVM_HPAGE_DEFINES are a little artificial on ARM, since the huge
page size is statically defined at compile time and there is only a
single huge page size.

Now when the main kvm code relying on these defines has been moved to
the x86 specific part of the world, we can get rid of these.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>

In ftrace_syscall_enter(),
    syscall_get_arguments(..., 0, n, ...)
        if (i == 0) { <handle ORIG_r0> ...; n--;}
        memcpy(..., n * sizeof(args[0]));
If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
syscall_get_arguments(), none of arguments should be copied by memcpy().
Otherwise 'n--' can be a big positive number and unexpected amount of data
will be copied. Tracing system calls which take no argument, say sync(void),
may hit this case and eventually make the system corrupted.
This patch fixes the issue both in syscall_get_arguments() and
syscall_set_arguments().

Cc: <stable@vger.kernel.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Without the "clock-frequency" property in arch timer node, could able
to see the below crash dump.

[<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14)
[<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0)
[<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18)
[<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74)
[<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c)
[<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134)
[<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c)
[<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58)
[<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c)
[<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c)

THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set
up the CNTFRQ register as expected by arch_timer. Instead, we have to specify
the frequency in the device tree like this.

Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
[olof: Changed subject, added comment, elaborated on commit message]
Signed-off-by: Olof Johansson <olof@lixom.net>

This patch adds support for running Cortex-A7 guests on Cortex-A7 hosts.

As Cortex-A7 is architecturally compatible with A15, this patch is largely just
generalising existing code. Areas where 'implementation defined' behaviour
is identical for A7 and A15 is moved to allow it to be used by both cores.

The check to ensure that coprocessor register tables are sorted correctly is
also moved in to 'common' code to avoid each new cpu doing its own check
(and possibly forgetting to do so!)

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

The T{0,1}SZ fields of TTBCR are 3 bits wide when using the long descriptor
format. Likewise, the T0SZ field of the HTCR is 3-bits. KVM currently
defines TTBCR_T{0,1}SZ as 3, not 7.

The T0SZ mask is used to calculate the value for the HTCR, both to pick out
TTBCR.T0SZ and mask off the equivalent field in the HTCR during
read-modify-write. The incorrect mask size causes the (UNKNOWN) reset value
of HTCR.T0SZ to leak in to the calculated HTCR value. Linux will hang when
initializing KVM if HTCR's reset value has bit 2 set (sometimes the case on
A7/TC2)

Fixing T0SZ allows A7 cores to boot and T1SZ is also fixed for completeness.

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

KVM does not have a notion of multiple clusters for CPUs, just a linear
array of CPUs. When using a system with cores in more than one cluster, the
current method for calculating the virtual MPIDR will leak the (physical)
cluster information into the virtual MPIDR. One effect of this is that
Linux under KVM fails to boot multiple CPUs that aren't in the 0th cluster.

This patch does away with exposing the real MPIDR fields in favour of simply
using the virtual CPU number (but preserving the U bit, as before).

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670



Implement a workaround suggested by Jakub Jelinek.

Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Suggested-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs
attribute if value is higher than max_current specified in board file. By default
global C variables are zero, so changing always failed. This patch adding missing
max_current and setting it to max safe value 100 (10 mA).

It is unclear which commit exactly caused this regression as the lp5523
driver was broken and was hiding the platform data breakage. Now
the driver is fixed so this should be fixed as well.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Joerg Reisenweber <joerg@openmoko.org>
[tony@atomide.com: updated comments to describe regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>

Since dra7 reuses the  function 'omap5_realtime_timer_init' in
arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
built for this SoC as well.

Signed-off-by: Simon Barth <Simon.Pe.Barth@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Benoît Cousson <bcousson@baylibre.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.

With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):

...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...

WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state

So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.

Signed-off-by: Nishanth Menon <nm@ti.com>
[tony@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>

With DT-based boot, the GPMC OneNAND sync mode setup does not work
correctly. During the async mode setup, sync flags gets incorrectly
set in the onenand_async data and the system crashes during the async
setup. Also, the sync mode never gets set in gpmc_onenand_data->flags, so
even without the crash, the actual sync mode setup would never be called.

The patch fixes this by adjusting the gpmc_onenand_data->flags when the
data is read from the DT. Also while doing this we force the onenand_async
to be always async.

The patch enables to use the following DTS chunk (that should correspond
the arch/arm/mach-omap2/board-rm680.c board file setup) with Nokia N950,
which currently crashes with 3.12-rc1. The crash output can be also
found below.

&gpmc {
	ranges = <0 0 0x04000000 0x20000000>;

	onenand@0,0 {
		#address-cells = <1>;
		#size-cells = <1>;
		reg = <0 0 0x20000000>;

		gpmc,sync-read;
		gpmc,sync-write;
		gpmc,burst-length = <16>;
		gpmc,burst-read;
		gpmc,burst-wrap;
		gpmc,burst-write;
		gpmc,device-width = <2>;
		gpmc,mux-add-data = <2>;
		gpmc,cs-on-ns = <0>;
		gpmc,cs-rd-off-ns = <87>;
		gpmc,cs-wr-off-ns = <87>;
		gpmc,adv-on-ns = <0>;
		gpmc,adv-rd-off-ns = <10>;
		gpmc,adv-wr-off-ns = <10>;
		gpmc,oe-on-ns = <15>;
		gpmc,oe-off-ns = <87>;
		gpmc,we-on-ns = <0>;
		gpmc,we-off-ns = <87>;
		gpmc,rd-cycle-ns = <112>;
		gpmc,wr-cycle-ns = <112>;
		gpmc,access-ns = <81>;
		gpmc,page-burst-access-ns = <15>;
		gpmc,bus-turnaround-ns = <0>;
		gpmc,cycle2cycle-delay-ns = <0>;
		gpmc,wait-monitoring-ns = <0>;
		gpmc,clk-activation-ns = <5>;
		gpmc,wr-data-mux-bus-ns = <30>;
		gpmc,wr-access-ns = <81>;
		gpmc,sync-clk-ps = <15000>;
	};
};

[    1.467559] GPMC CS0: cs_on     :   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.474822] GPMC CS0: cs_rd_off :   1 ticks,   5 ns (was  24 ticks)   5 ns
[    1.482116] GPMC CS0: cs_wr_off :  14 ticks,  71 ns (was  24 ticks)  71 ns
[    1.489349] GPMC CS0: adv_on    :   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.496582] GPMC CS0: adv_rd_off:   3 ticks,  15 ns (was   3 ticks)  15 ns
[    1.503845] GPMC CS0: adv_wr_off:   3 ticks,  15 ns (was   3 ticks)  15 ns
[    1.511077] GPMC CS0: oe_on     :   3 ticks,  15 ns (was   4 ticks)  15 ns
[    1.518310] GPMC CS0: oe_off    :   1 ticks,   5 ns (was  24 ticks)   5 ns
[    1.525543] GPMC CS0: we_on     :   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.532806] GPMC CS0: we_off    :   8 ticks,  40 ns (was  24 ticks)  40 ns
[    1.540039] GPMC CS0: rd_cycle  :   4 ticks,  20 ns (was  29 ticks)  20 ns
[    1.547302] GPMC CS0: wr_cycle  :   4 ticks,  20 ns (was  29 ticks)  20 ns
[    1.554504] GPMC CS0: access    :   0 ticks,   0 ns (was  23 ticks)   0 ns
[    1.561767] GPMC CS0: page_burst_access:   0 ticks,   0 ns (was   3 ticks)   0 ns
[    1.569641] GPMC CS0: bus_turnaround:   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.577270] GPMC CS0: cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.585144] GPMC CS0: wait_monitoring:   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.592834] GPMC CS0: clk_activation:   0 ticks,   0 ns (was   0 ticks)   0 ns
[    1.600463] GPMC CS0: wr_data_mux_bus:   5 ticks,  25 ns (was   8 ticks)  25 ns
[    1.608154] GPMC CS0: wr_access :   0 ticks,   0 ns (was  23 ticks)   0 ns
[    1.615386] GPMC CS0 CLK period is 5 ns (div 1)
[    1.625122] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf009e442
[    1.633178] Internal error: : 1008 [#1] ARM
[    1.637573] Modules linked in:
[    1.640777] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1-n9xx-los.git-5318619-00006-g4baa700-dirty #26
[    1.651123] task: ef04c000 ti: ef050000 task.ti: ef050000
[    1.656799] PC is at gpmc_onenand_setup+0x98/0x1e0
[    1.661865] LR is at gpmc_cs_set_timings+0x494/0x5a4
[    1.667083] pc : [<c002e040>]    lr : [<c001f384>]    psr: 60000113
[    1.667083] sp : ef051d10  ip : ef051ce0  fp : ef051d94
[    1.679138] r10: c0caaf60  r9 : ef050000  r8 : ef18b32c
[    1.684631] r7 : f0080000  r6 : c0caaf60  r5 : 00000000  r4 : f009e400
[    1.691497] r3 : f009e442  r2 : 80050000  r1 : 00000014  r0 : 00000000
[    1.698333] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    1.706024] Control: 10c5387d  Table: af290019  DAC: 00000015
[    1.712066] Process swapper (pid: 1, stack limit = 0xef050240)
[    1.718200] Stack: (0xef051d10 to 0xef052000)
[    1.722778] 1d00:                                     00004000 00001402 00000000 00000005
[    1.731384] 1d20: 00000047 00000000 0000000f 0000000f 00000000 00000028 0000000f 00000005
[    1.739990] 1d40: 00000000 00000000 00000014 00000014 00000000 00000000 00000000 00000000
[    1.748596] 1d60: 00000000 00000019 00000000 00000000 ef18b000 ef099c50 c0c8cb30 00000000
[    1.757171] 1d80: c0488074 c048f868 ef051dcc ef051d98 c024447c c002dfb4 00000000 c048f868
[    1.765777] 1da0: 00000000 00000000 c010e4a4 c0dbbb7c c0c8cb40 00000000 c0ca2500 c0488074
[    1.774383] 1dc0: ef051ddc ef051dd0 c01fd508 c0244370 ef051dfc ef051de0 c01fc204 c01fd4f4
[    1.782989] 1de0: c0c8cb40 c0ca2500 c0c8cb74 00000000 ef051e1c ef051e00 c01fc3b0 c01fc104
[    1.791595] 1e00: ef0983bc 00000000 c0ca2500 c01fc31c ef051e44 ef051e20 c01fa794 c01fc328
[    1.800201] 1e20: ef03634c ef0983b0 ef27d534 c0ca2500 ef27d500 c0c9a2f8 ef051e54 ef051e48
[    1.808807] 1e40: c01fbcfc c01fa744 ef051e84 ef051e58 c01fb838 c01fbce4 c0411df8 c0caa040
[    1.817413] 1e60: ef051e84 c0ca2500 00000006 c0caa040 00000066 c0488074 ef051e9c ef051e88
[    1.825988] 1e80: c01fca30 c01fb768 c04975b8 00000006 ef051eac ef051ea0 c01fd728 c01fc9bc
[    1.834594] 1ea0: ef051ebc ef051eb0 c048808c c01fd6e4 ef051f4c ef051ec0 c0008888 c0488080
[    1.843200] 1ec0: 0000006f c046bae8 00000000 00000000 ef051efc ef051ee0 ef051f04 ef051ee8
[    1.851806] 1ee0: c046d400 c0181218 c046d410 c18da8d5 c036a8e4 00000066 ef051f4c ef051f08
[    1.860412] 1f00: c004b9a8 c046d41c c048f840 00000006 00000006 c046b488 00000000 c043ec08
[    1.869018] 1f20: ef051f4c c04975b8 00000006 c0caa040 00000066 c046d410 c048f85c c048f868
[    1.877593] 1f40: ef051f94 ef051f50 c046db8c c00087a0 00000006 00000006 c046d410 ffffffff
[    1.886199] 1f60: ffffffff ffffffff ffffffff 00000000 c0348fd0 00000000 00000000 00000000
[    1.894805] 1f80: 00000000 00000000 ef051fac ef051f98 c0348fe0 c046daa8 00000000 00000000
[    1.903411] 1fa0: 00000000 ef051fb0 c000e7f8 c0348fdc 00000000 00000000 00000000 00000000
[    1.912017] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.920623] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[    1.929199] Backtrace:
[    1.931793] [<c002dfa8>] (gpmc_onenand_setup+0x0/0x1e0) from [<c024447c>] (omap2_onenand_probe+0x118/0x49c)
[    1.942047] [<c0244364>] (omap2_onenand_probe+0x0/0x49c) from [<c01fd508>] (platform_drv_probe+0x20/0x24)
[    1.952117]  r8:c0488074 r7:c0ca2500 r6:00000000 r5:c0c8cb40 r4:c0dbbb7c
[    1.959197] [<c01fd4e8>] (platform_drv_probe+0x0/0x24) from [<c01fc204>] (driver_probe_device+0x10c/0x224)
[    1.969360] [<c01fc0f8>] (driver_probe_device+0x0/0x224) from [<c01fc3b0>] (__driver_attach+0x94/0x98)
[    1.979125]  r7:00000000 r6:c0c8cb74 r5:c0ca2500 r4:c0c8cb40
[    1.985107] [<c01fc31c>] (__driver_attach+0x0/0x98) from [<c01fa794>] (bus_for_each_dev+0x5c/0x90)
[    1.994506]  r6:c01fc31c r5:c0ca2500 r4:00000000 r3:ef0983bc
[    2.000488] [<c01fa738>] (bus_for_each_dev+0x0/0x90) from [<c01fbcfc>] (driver_attach+0x24/0x28)
[    2.009735]  r6:c0c9a2f8 r5:ef27d500 r4:c0ca2500
[    2.014587] [<c01fbcd8>] (driver_attach+0x0/0x28) from [<c01fb838>] (bus_add_driver+0xdc/0x260)
[    2.023742] [<c01fb75c>] (bus_add_driver+0x0/0x260) from [<c01fca30>] (driver_register+0x80/0xfc)
[    2.033081]  r8:c0488074 r7:00000066 r6:c0caa040 r5:00000006 r4:c0ca2500
[    2.040161] [<c01fc9b0>] (driver_register+0x0/0xfc) from [<c01fd728>] (__platform_driver_register+0x50/0x64)
[    2.050476]  r5:00000006 r4:c04975b8
[    2.054260] [<c01fd6d8>] (__platform_driver_register+0x0/0x64) from [<c048808c>] (omap2_onenand_driver_init+0x18/0x20)
[    2.065490] [<c0488074>] (omap2_onenand_driver_init+0x0/0x20) from [<c0008888>] (do_one_initcall+0xf4/0x150)
[    2.075836] [<c0008794>] (do_one_initcall+0x0/0x150) from [<c046db8c>] (kernel_init_freeable+0xf0/0x1b4)
[    2.085815] [<c046da9c>] (kernel_init_freeable+0x0/0x1b4) from [<c0348fe0>] (kernel_init+0x10/0xec)
[    2.095336] [<c0348fd0>] (kernel_init+0x0/0xec) from [<c000e7f8>] (ret_from_fork+0x14/0x3c)
[    2.104125]  r4:00000000 r3:00000000
[    2.107879] Code: ebffc3ae e2505000 ba00002e e2843042 (e1d320b0)
[    2.114318] ---[ end trace b8ee3e3e5e002451 ]---

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The generic code is well equipped to differentiate between
SMP and UP configurations.However, there are some devices which
use Cortex-A9 MP core IP with 1 CPU as configuration. To let
these SOCs to co-exist in a CONFIG_SMP=y build by leveraging
the SMP_ON_UP support, we need to additionally check the
number the cores in Cortex-A9 MPCore configuration. Without
such a check in place, the startup code tries to execute
ALT_SMP() set of instructions which lead to CPU faults.

The issue was spotted on TI's Aegis device and this patch
makes now the device work with omap2plus_defconfig which
enables SMP by default. The change is kept limited to only
Cortex-A9 MPCore detection code.

Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then
the SCU address check code needs to be #ifdef'd for for the Aegis
platform.

Acked-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This fixes a regression for kernels after v3.2

After commit 72662e01
ARM: head.S: only include __turn_mmu_on in the initial identity mapping

Zaurus PXA devices call sharpsl_save_param() during fixup and hang on
boot because memcpy refers to physical addresses no longer valid if the
MMU is setup.
Zaurus collie (SA1100) is unaffected (function is called in init_machine).

The code was making assumptions and for PXA the virtual address
should have been used before.

Signed-off-by: Marko Katic <dromede@gmail.com>
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Commit 09096f6a (ARM: 7822/1: add workaround for ambiguous C99 stdint.h
types) introduced an ARM specific 'asm/types.h' to work around some
ambiguities in the definitions of 32 bit types. Hence, we will not be
needing the generic version anymore.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Currently mcpm_cpu_power_down() and mcpm_cpu_suspend() trigger BUG()
if mcpm_platform_register() is not called beforehand.  This may occur
for many reasons such as some incomplete device tree passed to the kernel
or the like.

Let's be nicer to users and avoid killing the kernel if that happens by
logging a warning and returning to the caller.  The mcpm_cpu_suspend()
user is already set to deal with this situation, and so is cpu_die()
invoking mcpm_cpu_die().

The problematic case would have been the B.L switcher's usage of
mcpm_cpu_power_down(), however it has to call mcpm_cpu_power_up() first
which is already set to catch an error resulting from a missing
mcpm_platform_register() call.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Turn on SDHCI for i.MX support so machines can boot with local rootfs
on SD. Tested on a Wandboard Quad.

Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>

Install targets (install, zinstall, uinstall) on arm have a dependency
to vmlinux. This may cause parts of the kernel to be rebuilt during
installation. We must avoid this since this may run as root. Install
targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus
emphasized this in:

 http://lkml.org/lkml/2013/7/10/600



So on arm and maybe other archs we need the same as for x86:

 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux

This patch fixes this for arm. Dependencies are removed and instead a
check to install.sh is added for the files that are needed.

This issue was uncovered by this build error where the -j option is
used in conjunction with install targets:

 $ make <makeflags>
 $ make <makeflags> zinstall
 ...
   DEPMOD
 Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease>

(INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms
required in this case.)

The problem is that zinstall on arm due to its dependency to vmlinux
does a prepare/prepare3 and finally does a forced rewrite of
kernel.release even if it exists already.

Rebuilding kernel.release removes it first and then recreates it. This
might race with another parallel make job running depmod.

So this patch should fix this one too.

Also quoting $(KERNELRELEASE) arg for install.sh as this messes
argument order in case it is empty (which is the case if the kernel
was not built yet).

Signed-off-by: Robert Richter <robert.richter@linaro.org>
Signed-off-by: Robert Richter <rric@kernel.org>
Acked-by: Michal Marek <mmarek@suse.cz&gt;.>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>

For implementing CPU=host, we need a mechanism for querying
preferred VCPU target type on underlying Host.

This patch implements KVM_ARM_PREFERRED_TARGET vm ioctl which
returns struct kvm_vcpu_init instance containing information
about preferred VCPU target type and target specific features
available for it.

Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

This patch implements kvm_vcpu_preferred_target() function for
KVM ARM which will help us implement KVM_ARM_PREFERRED_TARGET ioctl
for user space.

Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Very minor typo in comments of inject_abt() when we update fault status
register for injecting prefetch abort.

Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

... otherwise it is impossible for the low level iommu driver to
figure out which pte flags should be used.

In __map_sg_chunk we can derive the flags from dma_data_direction.

In __iommu_create_mapping we should treat the memory like
DMA_BIDIRECTIONAL and pass both IOMMU_READ and IOMMU_WRITE to
iommu_map.
__iommu_create_mapping is used during dma_alloc_coherent (via
arm_iommu_alloc_attrs).  AFAIK dma_alloc_coherent is responsible for
allocation _and_ mapping.  I think this implies that access to the
mapped pages should be allowed.

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

When 5e12a613 and 0cd3754a were introduced, Netgear ReadyNAS 102 .dts
file was queued for inclusion and missed the update to have Mbus (and
then BootROM) ranges properties declared. It also missed the relocation
of Armada 370/XP PCIe DT nodes introduced by 14fd8ed0 after de1af8d4.
This patch fixes that which makes 3.12-rc3 bootable on the NAS.

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Like we are doing on DDR0 we need to cleanly shutdown DDR1 if it is
used before rebooting.
If DDR1 is not initialized, we check it and avoid dereferencing its address.
Even by adding two more instructions, we are able to complete the procedure
within a single cache line.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.

The above issue is fixed by reading the "dmas" property from the DT node if it
exists and clearing the bits in the unused channel list if the dma controller
used by any device is EDMA. For this purpose we use the of_* helpers to parse
the arguments in the dmas phandle list.

Also introduced is a minor clean up of a checkpatch error in old code.

Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Reported-by: Balaji T K <balajitk@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Nishanth Menon <nm@ti.com>
Cc: Pantel Antoniou <panto@antoniou-consulting.com>
Cc: Jason Kridner <jkridner@beagleboard.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Joel Fernandes <joelf@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

On the TC2 testchip, when all CPUs in a cluster enter standbywfi
and commit a power down request, the power controller will wait
for standbywfil2 coming from L2 cache controller to shut the
cluster down.
By the time all CPUs in a cluster commit a power down request
and enter wfi, the power controller cannot backtrack, or put it
another way, a CPU must not be allowed to complete execution
independently of the power controller, the only way for it to
resume properly must be upon wake-up IRQ pending and subsequent
reset triggered from the power controller.

Current MCPM back-end for TC2 disables the GIC CPU IF only when
power down is committed through the tc2_pm_suspend() method, that
makes sense since a suspended CPU is still online and can receive
interrupts whereas a hotplugged CPU, since it is offline,
migrated all IRQs and shutdown the per-CPU peripherals, hence
their PPIs.

The flaw with this reasoning is the following. If all CPUs in
a clusters are entering a power down state either through CPU
idle or CPU hotplug, when the last man successfully completes
the MCPM power down sequence (and executes wfi), power controller
waits for L2 wfi signal to quiesce the cluster and shut it down.
If, when all CPUs are sitting in wfi, an online CPU hotplugs back
in one of the CPUs in the cluster being shutdown, that CPU
receives an IPI that causes wfi to complete (since tc2_pm_down()
method does not disable the GIC CPU IF in that case - CPU being
hotplugged out, not idle) and the power controller will never see
the stanbywfil2 signal coming from L2 that is required for
shutdown to happen and the system deadlocks.

Further to this issue, kexec hotplugs secondary CPUs out during
kernel reload/restart.
Because kexec may (deliberately) trash the old kernel text, it is
not OK for CPUs to follow the MCPM soft reboot path, since
instructions after the WFI may have been replaced by kexec.

If tc2_pm_down() does not disable the GIC cpu interface, there is a
race between CPU powerdown in the old kernel and the IPI from the
new kernel that triggers secondary boot, particularly if the
powerdown is slow (due to L2 cache cleaning for example).  If the
new kernel wins the race, the affected CPU(s) will not really be
reset and may execute garbage after the WFI.

The only solution to this problem consists in disabling the GIC
CPU IF on a CPU committed to power down regardless of the power
down entry method (CPU hotplug or CPU idle). This way, CPU wake-up
is under power controller control, which prevents unexpected wfi
exit caused by a pending IRQ.

This patch moves the GIC CPU IF disable call in the TC2 MCPM
implementation from the tc2_pm_suspend() method to the
tc2_pm_down() method to fix the mentioned race condition(s).

Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Tested-by: Dave Martin <Dave.Martin@arm.com> (for kexec)
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>