This patch enables arm-pmu to bind device tree for exynos5250. The exynos5250
has two pmus which have combiner irq type.
Reviewed-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch defines irq numbers of ARM performance monitoring unit for exynos4.
Firs of all, we need to fix IRQ_PMU correctly and to split pmu initialization
of exynos from plat-samsung for easily defining it.

The number of CPU cores and PMU irq numbers are vary according to soc types.
So, we need to identify each soc type using soc_is_xxx function and to define
the pmu irqs dynamically. For example, the exynos4412 has 4 cpu cores and pmus.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch corrects combined IRQs for exynos4 series platform. The exynos4412
has four extra combined irq group and the exynos4212 has two more combined
irqs
than exynos4210. Each irq is mapped to IRQ_SPI(xx). Unfortunately, extra 4
combined IRQs isn't sequential. So, we need to map the irqs manually.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
[kgene.kim@samsung.com: changes moved into drivers/irqchip/]
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>

The expression to compute the padding needed to fill the uc_sigmask field
to 1024 bits actually computes the padding needed for 1080 bits.
Fortunately, due to the 16-byte alignment of the following field
(uc_mcontext) the definition in glibc contains enough bytes of padding
after uc_sigmask so that the overall offsets and size match in both
definitions.
Signed-off-by: NAndreas Schwab <schwab@suse.de>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The __atomic_hash is only defined when SMP is enabled but the
arm64ksyms.c exports it even for the UP case.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>