Boards using secure firmware must use different CPU boot registers and
call secure firmware to boot the CPU.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

On TrustZone-enabled boards the non-secure SYSRAM is used for secondary
CPU bring-up, so add a mapping for it.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Some Exynos-based boards contain secure firmware and must use firmware
operations to set up some hardware.

This patch adds firmware operations for Exynos secure firmware and a way
for board code and device tree to specify that they must be used.

Example of use:

In board code:

  ...MACHINE_START(...)
          /* ... */
          .init_early   = exynos_firmware_init,
          /* ... */
  MACHINE_END

In device tree:

  / {
          /* ... */

          firmware@0203F000 {
                  compatible = "samsung,secure-firmware";
                  reg = <0x0203F000 0x1000>;
          };

          /* ... */
  };
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Some boards use secure monitor calls to communicate with secure
firmware.

This patch adds exynos_smc function which uses smc assembly instruction
to do secure monitor calls.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized.

This patch adds an interface for platforms to specify available firmware
operations and call them.

A wrapper macro, call_firmware_op(), checks if the operation is provided
and calls it if so, otherwise returns -ENOSYS to allow fallback to
legacy operation..

By default no operations are provided.

Example of use:

In code using firmware ops:

  __raw_writel(virt_to_phys(exynos4_secondary_startup),
               CPU1_BOOT_REG);

  /* Call Exynos specific smc call */
  if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
          cpu_boot_legacy(...); /* Try legacy way */

  gic_raise_softirq(cpumask_of(cpu), 1);

In board-/platform-specific code:

  static int platformX_do_idle(void)
  {
          /* tell platformX firmware to enter idle */
          return 0;
  }

  static int platformX_cpu_boot(int i)
  {
          /* tell platformX firmware to boot CPU i */
          return 0;
  }

  static const struct firmware_ops platformX_firmware_ops = {
          .do_idle      = exynos_do_idle,
          .cpu_boot     = exynos_cpu_boot,
          /* other operations not available on platformX */
  };

  static void __init board_init_early(void)
  {
          register_firmware_ops(&platformX_firmware_ops);
  }
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The functions exynos4_clk_init and exynos4_clk_register_fixed_ext
are applicable only on Exynos4 non-dt platforms. But when building
Exynos5 platforms without including Exynos4 platforms, the following
errors show up.

arch/arm/mach-exynos/built-in.o: In function `exynos_init_time':
arch/arm/mach-exynos/common.c:446: undefined reference to `exynos4_clk_init'
arch/arm/mach-exynos/common.c:447: undefined reference to `exynos4_clk_register_fixed_ext'

Fix this compilation errors by marking these calls as Exynos4 specific.
Signed-off-by: NThomas Abraham <thomas.ab@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit 3e7fc708 ("ia64 idle: delete pm_idle") in 3.9-rc1 didn't
finish the job, leaving an un-initialized reference to (*idle)().

[ Haven't seen a crash from this - but seems like we are just being
  lucky that "idle" is zero so it does get initialized before we jump to
  randomland  - Len ]
Reported-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We move the setting of write_cr3 from the early bootup variant
(see git commit 0cc9129d
"x86-64, xen, mmu: Provide an early version of write_cr3.")
to a more appropiate location.

This new location sets all of the other non-early variants
of pvops calls - and most importantly is before the
alternative_asm mechanism kicks in.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

For 32-bit, CONFIG_EPAPR_PARAVIRT pulls in both epapr_paravirt.c
and epapr_hcalls.c which contains the 32-bit paravirt idle loop.

For 64-bit, the paravirt idle loop is in idle_book3e.S and that
source file is included only if CONFIG_PPC_BOOK3E_64 defined.

This patch makes that dependency for 64-bit explicit.

Fixes these build errors:

arch/powerpc/kernel/built-in.o: In function `restore_pblist_ptr':
ftrace.c:(.toc+0xdc0): undefined reference to `epapr_ev_idle_start'
ftrace.c:(.toc+0xdd0): undefined reference to `epapr_ev_idle'
Signed-off-by: NStuart Yoder <stuart.yoder@freescale.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>

The 'CONFIG_' prefix is not implicit in IS_ENABLED().
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

They are defined in coreboot (MSR_PLATFORM) and the other
one is already defined in msr-index.h.

Let's use those.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The clock frequency of xxti and xusbxti clocks is dependent on the
frequency of the on-board oscillator that is used to generate these
clocks. So allow the frequency of these clocks to be specfied from
device tree.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

For all supported peripheral controllers on Exynos5440, add clock
lookup information.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

For all supported peripheral controllers on Exynos5250, add clock
lookup information.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

For all supported peripheral controllers on Exynos4 SoCs, add clock
lookup information.
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Tested-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Add clock controller nodes for EXYNOS4210, EXYNOS4x12, EXYNOS5250
and EXYNOS5440 SoCs.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

With support for device tree based clock lookup now available, remove
the auxdata table from exynos4/5 dt-enabled machine file.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The clock speed of xxti and xusbxti clocks depends on the oscillator
used on the board to generate these clocks. For non-dt platforms,
allow the board support for those platforms to set the clock frequency
of xxti and xusbxti clocks.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Since the clock initialization should be completed prior to the mct
timer initialization, create a new function 'exynos_init_time' that
first sets up the clock and then invokes the timer initialization
function. The 'init_time' callback in the board files are updated to
invoke this new wrapper function.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Remove Samsung specific clock support in Exynos4/5 and migrate to
use common clock framework.
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Tested-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)

Fixes this build error:

arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>

Fix typo on register address of slink3 controller where register
address is wrongly set as 0x7000d480 but it is 0x7000d800.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

For MSI-X capable devices the hypervisor wants to write protect the
MSI-X table and PBA, yet it can't assume that resources have been
assigned to their final values at device enumeration time. Thus have
pciback do that notification, as having the device controlled by it is
a prerequisite to assigning the device to guests anyway.

This is the kernel part of hypervisor side commit 4245d33 ("x86/MSI:
add mechanism to fully protect MSI-X table from PV guest accesses") on
the master branch of git://xenbits.xen.org/xen.git.

CC: stable@vger.kernel.org
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add missing __cpuinit annotation to apply_microcode_early().
Reported-by: NShaun Ruffell <sruffell@digium.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/20130320170310.GA23362@digium.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

orig_r8_IS_EXCPN and orig_r8_IS_BRKPT were same values due to a
copy/paste error. Although it looks bad and is wrong, it really doesn't
affect gdb working.

orig_r8_IS_BRKPT is the one relevant to debugging (breakpoints), since
it is used to provide EFA vs. ERET to a ptrace "stop_pc" request.

So when gdb has inserted a breakpoint, orig_r8_IS_BRKPT is already set,
and anything else (i.e. orig_r8_IS_EXCPN) becoming same as it, really
doesn't hurt gdb. The corollary case, could be nasty but nobody uses the
ptrace "stop_pc" request in that case
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

In 32-bit, __pa_symbol() in CONFIG_DEBUG_VIRTUAL accesses kernel data
(e.g.  max_low_pfn) that not only hasn't been setup yet in such early
boot phase, but since we are in linear mode, cannot even be detected
as uninitialized.

Thus, use __pa_nodebug() rather than __pa_symbol() to get a global
symbol's physical address.
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/1363705484-27645-1-git-send-email-fenghua.yu@intel.comReported-and-tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Once instance of this Kconfig macro remained after commit
51acbcec ("md: remove
CONFIG_MULTICORE_RAID456"). Remove that one too. And, while we're at it,
also remove it from the defconfig files that carry it.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NNeilBrown <neilb@suse.de>

sparc's asm/module.h got removed in commit
786d35d4 ("Make most arch asm/module.h
files use asm-generic/module.h"). That removed the only two uses of this
Kconfig symbol. So we can remove its entry too.

> >From arch/sparc/Makefile:
>     ifeq ($(CONFIG_SPARC32),y)
>     [...]
>
>     [...]
>     export BITS    := 32
>     [...]
>
>     else
>     [...]
>
>     [...]
>     export BITS   := 64
>     [...]
>
> So $(BITS) is set depending on whether CONFIG_SPARC32 is set or not.
> Using $(BITS) in sparc's Makefiles is not using CONFIG_BITS. That
> doesn't count as usage of "config BITS".
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 2d78d4be ("[PATCH] bitops:
sparc64: use generic bitops") made the default of GENERIC_HWEIGHT depend
on !ULTRA_HAS_POPULATION_COUNT. But since there's no Kconfig symbol with
that name, this always evaluates to true. Delete this dependency.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a potential use after free issue with the handling of
MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
memory such as frame buffers then KVM might continue to write to that
address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
the page in memory so it's unlikely to cause an issue, but if the user
space component re-purposes the memory previously used for the guest, then
the guest will be able to corrupt that memory.

Tested: Tested against kvmclock unit test
Signed-off-by: NAndrew Honig <ahonig@google.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

If the guest sets the GPA of the time_page so that the request to update the
time straddles a page then KVM will write onto an incorrect page.  The
write is done byusing kmap atomic to get a pointer to the page for the time
structure and then performing a memcpy to that page starting at an offset
that the guest controls.  Well behaved guests always provide a 32-byte aligned
address, however a malicious guest could use this to corrupt host kernel
memory.

Tested: Tested against kvmclock unit test.
Signed-off-by: NAndrew Honig <ahonig@google.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

The Kconfig entry for DEBUG_ERRORS is a verbatim copy of the former arm
entry for that symbol. It got removed in v2.6.39 because it wasn't
actually used anywhere. There are still no users of DEBUG_ERRORS so
remove this entry too.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
[catalin.marinas@arm.com: removed option from defconfig]
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Config option GENERIC_HARDIRQS_NO_DEPRECATED was removed in commit
78c89825 ("genirq: Remove the now obsolete
config options and select statements"), but the select was accidentally
reintroduced in commit 8c2c3df3 ("arm64:
Build infrastructure").
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Signed-off-by: NPierrick Hascoet <pierrick.hascoet@abilis.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

While adding i.MX DEBUG_LL selection, commit f8c95fe6 (ARM: imx: support
DEBUG_LL uart port selection for all i.MX SoCs) leaves Kconfig symbol
DEBUG_IMX_UART_PORT there without any dependency check.  This results in
that everyone gets the symbol in their config, which is someting
undesirable.  Add "depends on ARCH_MXC" for the symbol to prevent that.
Reported-by: NKarl Beldan <karl.beldan@gmail.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

The issue fixed by this patch manifests only then using X11
with mxsfb driver. The X11 will display either shifted image
or otherwise distorted image on the LCD.

The problem is that the X11 tries to reconfigure the framebuffer
and along the way calls fb_ops.fb_set_par() with X11's desired
configuration values. The field of particular interest is
fb_info->var.sync which contains non-standard values if
configured by kernel. These are either FB_SYNC_DATA_ENABLE_HIGH_ACT,
FB_SYNC_DOTCLK_FAILING_ACT or both, depending on the platform
configuration. Both of these values are defined in the
include/linux/mxsfb.h file.

The driver interprets these values and configures the LCD controller
accordingly. Yet X11 only has access to the standard values for this
field defined in include/uapi/linux/fb.h and thus, unlike kernel,
omits these special values. This results in distorted image on the
LCD.

This patch moves these non-standard values into new field of the
mxsfb_platform_data structure so the driver can in turn check this
field instead of the video mode field for these specific portions.

Moreover, this patch prefixes these values with MXSFB_SYNC_ prefix
instead of FB_SYNC_ prefix to prevent confusion of subsequent users.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
Cc: Lothar Waßmann <LW@karo-electronics.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Somehow the driver snuck in with these still in it.
Signed-off-by: NBen Collins <ben.c@servergy.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is a deadlock in pvclock handling:

cpu0:                                               cpu1:
kvm_gen_update_masterclock()
                                              kvm_guest_time_update()
 spin_lock(pvclock_gtod_sync_lock)
                                               local_irq_save(flags)

spin_lock(pvclock_gtod_sync_lock)

 kvm_make_mclock_inprogress_request(kvm)
  make_all_cpus_request()
   smp_call_function_many()

Now if smp_call_function_many() called by cpu0 tries to call function on
cpu1 there will be a deadlock.

Fix by moving pvclock_gtod_sync_lock protected section outside irq
disabled section.

Analyzed by Gleb Natapov <gleb@redhat.com>
Acked-by: NGleb Natapov <gleb@redhat.com>
Reported-and-Tested-by: NYongjie Ren <yongjie.ren@intel.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

The increment of "to" in copy_user_handle_tail() will have incremented
before a failure has been noted.  This causes us to skip a byte in the
failure case.

Only do the increment when assured there is no failure.
Signed-off-by: NCQ Tang <cq.tang@intel.com>
Link: http://lkml.kernel.org/r/20130318150221.8439.993.stgit@phlsvslse11.ph.intel.comSigned-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>

887cbce0 "arch Kconfig: centralise CONFIG_ARCH_NO_VIRT_TO_BUS"
and  4febd95a "Select VIRT_TO_BUS directly where needed" from
Stephen Rothwell changed globally how CONFIG_VIRT_TO_BUS is
selected, while my own a5d533ee "ARM: disable virt_to_bus/
virt_to_bus almost everywhere" was merged at the same time and
changed which platforms select it on ARM.

The result of this conflict was that we again see CONFIG_VIRT_TO_BUS
on all ARM systems. This patch fixes up the problem and removes
CONFIG_ARCH_NO_VIRT_TO_BUS again on ARM.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>