Arnd in his review pointed out that arch Kconfig organisation has several
deficiencies:

* Build time entries for things which can be runtime extracted from DT
  (e.g. SDRAM size, core clk frequency..)
* Not multi-platform-image-build friendly (choice .. endchoice constructs)
* cpu variants support (750/770) is exclusive.

The first 2 have been fixed in subsequent patches.
Due to the nature of the 750 and 770, it is not possible to build for
both together, w/o special runtime glue code which would hurt
performance.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

As the kernel is able to cope with multiple clusters,
uncomment the A7 cores in the Device Tree for V2P-CA15_A7
tile, making all 5 cores available to the user.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>

In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a
single cpu identifier, affinity levels 1 and 2 must be taken into account as
well.
This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile
secondary cores start up code in order to compare the passed pen_release
value with the full-blown affinity mask.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>

Concerning pinctrl_macb0_rmii_mii, values were okay, but not comments.
Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Reported-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

No need for this cmdline option as we are using DT.
Moreover this defconfig is targeted to multiple SoC/boards: this option
was nonsense.
Reported-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

This patch overrides default macb pinctrl config defined in
at91sam9260.dtsi (pinctrl_macb_rmii) with kizbox board config
(pinctrl_macb_rmii + pinctrl_macb_rmii_mii_alt).
Signed-off-by: NBoris BREZILLON <linux-arm@overkiz.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Make BGA as the default version as we are supposed to just have
to specify when we use the PQFP version.

Issue was existing since commit:
3e90772f (ARM: at91: fix at91rm9200 soc subtype handling).
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: stable <stable@vger.kernel.org> [v3.3]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The SCK pins where missing in usarts pinctrl.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The PIN_BANK 3 is for PDxx pins, not PCxx pins.
And PIN_BANK 1 is for PBxx, not PIN_BANK 0.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The gpio controller on kirkwood can provide interrupts but is missing
the #interrupt-cells property. This patch just adds it to both gpio
controllers.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

putreg() assumes that the tracee is not running and pt_regs_access() can
safely play with its stack.  However a killed tracee can return from
ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
that debugger can actually read/modify the kernel stack until the tracee
does SAVE_REST again.

set_task_blockstep() can race with SIGKILL too and in some sense this
race is even worse, the very fact the tracee can be woken up breaks the
logic.

As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
call, this ensures that nobody can ever wakeup the tracee while the
debugger looks at it.  Not only this fixes the mentioned problems, we
can do some cleanups/simplifications in arch_ptrace() paths.

Probably ptrace_unfreeze_traced() needs more callers, for example it
makes sense to make the tracee killable for oom-killer before
access_process_vm().

While at it, add the comment into may_ptrace_stop() to explain why
ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
Reported-by: NSalman Qazi <sqazi@google.com>
Reported-by: NSuleiman Souhlal <suleiman@google.com>
Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The kernel's internal definition of ELF_NGREG uses struct pt_regs, which
means that we disagree with userspace on the size of coredumps since
glibc correctly uses the user-visible struct user_pt_regs.

This patch fixes our ELF_NGREG definition to use struct user_pt_regs
and introduces our own ELF_CORE_COPY_REGS to convert between the user
and kernel structure definitions.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Add the UART2 muxing data to the board file (this used to be,
erroneously, done in the bootloader).

Cc: stable <stable@vger.kernel.org> [3.7]
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get the following with
CONFIG_OF_DYNAMIC set:

ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[<c001329c>] (unwind_backtrace+0x0/0xe0) from [<c03dd8f0>] (of_node_release+0x2c/0xa0)!
[<c03dd8f0>] (of_node_release+0x2c/0xa0) from [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90)!
[<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90) from [<c06d349c>] (omap_get_timer_dt+0x78/0x90)!
[<c06d349c>] (omap_get_timer_dt+0x78/0x90) from [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
[<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
[<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from [<c06cca58>] (time_init+0x20/0x30)!
[<c06cca58>] (time_init+0x20/0x30) from [<c06c9690>] (start_kernel+0x1a8/0x2fc)!
Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com>
Acked-by: NJon Hunter <jon-hunter@ti.com>
[tony@atomide.com: updated description per Jon]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we will get:

WARNING: vmlinux.o(.text+0x1d4f0): Section mismatch in reference from the
function omap_init_ocp2scp() to the function .init.text:omap_device_build()
The function omap_init_ocp2scp() references
the function __init omap_device_build().
This is often because omap_init_ocp2scp lacks a __init
annotation or the annotation of omap_device_build is wrong.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fixes compile break with 3.8-rc4.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The ia64 function "thread_matches()" has no users since commit
e868a55c ("[IA64] remove find_thread_for_addr()").  Remove it.

This allows us to make ptrace_check_attach() static to kernel/ptrace.c,
which is good since we'll need to change the semantics of it and fix up
all the callers.
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 8fb54284 {ARM: mm: Add strongly ordered descriptor support}
added XN flag at section level but missed it at PTE level.

Fix it by adding the L_PTE_XN to MT_MEMORY_SO PTE descriptor.
Reported-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Subhash Jadavani reported this partial backtrace:
  Now consider this call stack from MMC block driver (this is on the ARMv7
  based board):

  [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
  [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
  [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114)

This is caused by incrementing the struct page pointer, and running off
the end of the sparsemem page array.  Fix this by incrementing by pfn
instead, and convert the pfn to a struct page.

Cc: <stable@vger.kernel.org>
Suggested-by: NJames Bottomley <JBottomley@Parallels.com>
Tested-by: NSubhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

During the migration to the common clock framework, calls to the
functions omap2xxx_clkt_vps_late_init() were not preserved for
OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and
"curr_prcm_set" to be uninitialised on boot. On reboot, this causes the
following error message to be displayed because the appropriate MPU
clock frequency (derived from sys_ck_rate) cannot be found.

"Could not set MPU rate to 4294MHz"

Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the
OMAP2420 and OMAP2430 clock initialisation code.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: dropped the duplicated call to
 omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon;
 updated patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[paul@pwsan.com: copy patch description into hwmod data comments]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: cleaned up patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime

Meanwhile we update the platform code accordingly.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Guests can trigger MMIO exits using dcbf. Since we don't emulate cache
incoherent MMIO, just do nothing and move on.
Reported-by: NBen Collins <ben.c@servergy.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
Tested-by: NBen Collins <ben.c@servergy.com>
CC: stable@vger.kernel.org

We are using S3C_EINT(4) instead of S3C_EINT(5).
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

As per the current exynos-dw-mshc bindings, dw-mshc-sdr-timing and
dw-mshc-ddr-timing properties are having only two cells, these properties
are wrongly set for exynos5250 based cros5250 and smdk5250 platfroms. This
patch corrects above timing propreties for above platfroms
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

If there is no board selecting CONFIG_S3C_DEV_FB enabled, build will
fail on arch/arm/mach-s3c64xx/pm.c, where s3c_device_fb is referenced.

This patch adds ifdef guard around the code making it compile only
when CONFIG_S3C_DEV_FB is enabled.
Signed-off-by: NTomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

debug_ll_addr is only used on machines with an MMU so it can be #ifdef'ed
out safely. This fixes:

arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:104: Error: too many positional arguments

The problem was introduced in e5c5f2ad ARM: implement debug_ll_io_init().
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This fixes CVE-2013-0190 / XSA-40

There has been an error on the xen_failsafe_callback path for failed
iret, which causes the stack pointer to be wrong when entering the
iret_exc error path.  This can result in the kernel crashing.

In the classic kernel case, the relevant code looked a little like:

        popl %eax      # Error code from hypervisor
        jz 5f
        addl $16,%esp
        jmp iret_exc   # Hypervisor said iret fault
5:      addl $16,%esp
                       # Hypervisor said segment selector fault

Here, there are two identical addls on either option of a branch which
appears to have been optimised by hoisting it above the jz, and
converting it to an lea, which leaves the flags register unaffected.

In the PVOPS case, the code looks like:

        popl_cfi %eax         # Error from the hypervisor
        lea 16(%esp),%esp     # Add $16 before choosing fault path
        CFI_ADJUST_CFA_OFFSET -16
        jz 5f
        addl $16,%esp         # Incorrectly adjust %esp again
        jmp iret_exc

It is possible unprivileged userspace applications to cause this
behaviour, for example by loading an LDT code selector, then changing
the code selector to be not-present.  At this point, there is a race
condition where it is possible for the hypervisor to return back to
userspace from an interrupt, fault on its own iret, and inject a
failsafe_callback into the kernel.

This bug has been present since the introduction of Xen PVOPS support
in commit 5ead97c8 (xen: Core Xen implementation), in 2.6.23.
Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: NAndrew Cooper <andrew.cooper3@citrix.com>
Cc: stable@vger.kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The UART controller used in the A10/A13 is the Synopsys DesignWare 8250.
The wrong use of a regular 8250 driver may lead to a oops during kernel
boot with "irq 17: nobody cared", because the apb UART as an extra
interrupt that gets raised when writing to the LCR when busy.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

We currently use a temporary 1MB section aligned to a 1MB boundary for
mapping the provided device tree until the final page table is created.
However, if the device tree happens to cross that 1MB boundary, the end
of it remains unmapped and the kernel crashes when it attempts to access
it.  Given no restriction on the location of that DTB, it could end up
with only a few bytes mapped at the end of a section.

Solve this issue by mapping two consecutive sections.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NTomasz Figa <t.figa@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patrik Kluba reports that the preempt count becomes invalid due
to the preempt_enable() call being unbalanced with a
preempt_disable() call in the vfp assembly routines. This happens
because preempt_enable() and preempt_disable() update preempt
counts under PREEMPT_COUNT=y but the vfp assembly routines do so
under PREEMPT=y. In a configuration where PREEMPT=n and
DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable()
call in VFP_bounce() keeps subtracting from the preempt count
until it goes negative.

Fix this by always using PREEMPT_COUNT to decided when to update
preempt counts in the ARM assembly code.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reported-by: NPatrik Kluba <pkluba@dension.com>
Tested-by: NPatrik Kluba <pkluba@dension.com>
Cc: <stable@vger.kernel.org> # 2.6.30
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Cc: stable@kernel.org
Reviewed-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

FSI - DA7210 needs amixer settings to use it.
This patch adds quick setting guide
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This reverts commit 41bd956d.

The fix is incorrect and not appropiate for the latest kernels.
In fact it _causes_ the BUG: scheduling while atomic while
doing vCPU hotplug.
Suggested-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There have been a number of new syscalls introduced to arch/arm/ since
the compat layer was implemented for arm64, so add pointers to the
relevant functions to the compat syscall table.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>