Commit 0a8ea52c ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API
feature") inadvertently removed the arch/arm prototype instead of the
arm64 one introduced by the original patch. There should not be any
bisection issues since this function is not called from anywhere else
(it could as well be removed from arch/arm at some point).

Fixes: 0a8ea52c ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

We always have vma->vm_mm around.

Link: http://lkml.kernel.org/r/1466021202-61880-8-git-send-email-kirill.shutemov@linux.intel.comSigned-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This allows an arch which needs to do special handing with respect to
different page size when flushing tlb to implement the same in mmu
gather.

Link: http://lkml.kernel.org/r/1465049193-22197-3-git-send-email-aneesh.kumar@linux.vnet.ibm.comSigned-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This updates the generic and arch specific implementation to return true
if we need to do a tlb flush.  That means if a __tlb_remove_page
indicate a flush is needed, the page we try to remove need to be tracked
and added again after the flush.  We need to track it because we have
already update the pte to none and we can't just loop back.

This change is done to enable us to do a tlb_flush when we try to flush
a range that consists of different page sizes.  For architectures like
ppc64, we can do a range based tlb flush and we need to track page size
for that.  When we try to remove a huge page, we will force a tlb flush
and starts a new mmu gather.

[aneesh.kumar@linux.vnet.ibm.com: mm-change-the-interface-for-__tlb_remove_page-v3]
  Link: http://lkml.kernel.org/r/1465049193-22197-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1464860389-29019-2-git-send-email-aneesh.kumar@linux.vnet.ibm.comSigned-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.

PGALLOC_GFP uses __GFP_REPEAT but none of the allocation which uses this
flag is for more than order-2.  This means that this flag has never been
actually useful here because it has always been used only for
PAGE_ALLOC_COSTLY requests.

Link: http://lkml.kernel.org/r/1464599699-30131-5-git-send-email-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter
while Xen's idea is expected. In some cases these ideas diverge so we
need to do remapping.

Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr().

Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as
they're only being called by PV guests before perpu areas are
initialized. While the issue could be solved by switching to
early_percpu for xen_vcpu_id I think it's not worth it: PV guests will
probably never get to the point where their idea of vCPU id diverges
from Xen's.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try
booting on the vCPU which crashed. This doesn't work very well for
PVHVM guests as we have a number of hypercalls where we pass vCPU id
as a parameter. These hypercalls either fail or do something
unexpected.

To solve the issue introduce percpu xen_vcpu_id mapping. ARM and PV
guests get direct mapping for now. Boot CPU for PVHVM guest gets its
id from CPUID. With secondary CPUs it is a bit more
trickier. Currently, we initialize IPI vectors before these CPUs boot
so we can't use CPUID. Use ACPI ids from MADT instead.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

Replace the non-standard vendor prefix stm with st for
STMicroelectronics. The drivers do not specify the vendor prefixes
since the I2C Core strips them away from the DT provided compatible
string. Therefore, changing existing device trees does not have any
impact on device detection.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NRob Herring <robh@kernel.org>

Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Reviewed-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64, including supporting
functions and defines.
Signed-off-by: NDavid A. Long <dave.long@linaro.org>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
[catalin.marinas@arm.com: Remove unused functions]
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Commit 0dfd582e ("watchdog: qcom: use timer devicetree
binding") moved to use the watchdog as a subset timer
register block. Some devices have the watchdog completely
standalone with slightly different register offsets as
well so let's account for the differences here.

The existing "kpss-standalone" compatible string doesn't
make it entirely clear exactly what the device is so
rename to "kpss-wdt" to reflect watchdog timer
functionality. Also update ipq4019 DTS with an SoC
specific compatible.
Signed-off-by: NMatthew McClintock <mmcclint@codeaurora.org>
Signed-off-by: NThomas Pedersen <twp@codeaurora.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Update the compatible string to align with driver and also
add SoC specific string to DTS.

CC: linux-watchdog@vger.kernel.org
Signed-off-by: NMatthew McClintock <mmcclint@codeaurora.org>
Signed-off-by: NThomas Pedersen <twp@codeaurora.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.

The get_cpu() in xen_starting_cpu() boils down to preempt_disable() since
we already know the CPU we run on. Disabling preemption shouldn't be required
here from what I see since it we don't switch CPUs while invoking the function.
Signed-off-by: NRichard Cochran <rcochran@linutronix.de>
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: rt@linutronix.de
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20160713153336.971559670@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Install the callbacks via the state machine. The callbacks won't be invoked on
already online CPUs.
Signed-off-by: NRichard Cochran <rcochran@linutronix.de>
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153336.881124821@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
Signed-off-by: NRichard Cochran <rcochran@linutronix.de>
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Brad Mouring <brad.mouring@ni.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153336.801270887@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Straight forward conversion plus commentary why code which is executed
in hotplug callbacks needs to be invoked before installing them.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153335.713612993@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Currently, we check cpuidle_ops.suspend every time when entering a
low-power idle state. But this check could be avoided in this hot path
by moving it into arm_cpuidle_read_ops() to reduce arm_cpuidle_suspend
overhead a bit.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Let's assume cpuidle_ops exists but it doesn't implement the according
init callback, current arm_cpuidle_init() will return success to its
caller, but in fact it should return -EOPNOTSUPP.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When doing dma allocation with IOMMU the __iommu_alloc_atomic() was
used even when the system was coherent. However, this function
allocates from a non-cacheable pool, which is fine when the device is
not cache coherent but won't work as expected in the device is cache
coherent. Indeed, the CPU and device must access the memory using the
same cacheability attributes.

Moreover when the devices are coherent, the mmap call must not change
the pg_prot flags in the vma struct. The arm_coherent_iommu_mmap_attrs
has been updated in the same way that it was done for the arm_dma_mmap
in commit 55af8a91 ("ARM: 8387/1: arm/mm/dma-mapping.c: Add
arm_coherent_dma_mmap").
Suggested-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When a L2 cache controller is used in a system that provides hardware
coherency, the entire outer cache operations are useless, and can be
skipped.  Moreover, on some systems, it is harmful as it causes
deadlocks between the Marvell coherency mechanism, the Marvell PCIe
controller and the Cortex-A9.

In the current kernel implementation, the outer cache flush range
operation is triggered by the dma_alloc function.
This operation can be take place during runtime and in some
circumstances may lead to the PCIe/PL310 deadlock on Armada 375/38x
SoCs.

This patch extends the __dma_clear_buffer() function to receive a
boolean argument related to the coherency of the system. The same
things is done for the calling functions.
Reported-by: NNadav Haklai <nadavh@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The workaround for both errata is to set bit 24 in the diagnostic
register.  There are no known end-user bugs solved by fixing this
errata, but the fix is trivial and it seems sane to apply it.

The arguments for why this needs to be in the kernel are similar to the
arugments made in the patch "Workaround errata A12 818325/852422 A17
852423".
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This erratum has a very simple workaround (set a bit in a register), so
let's apply it.  Apparently the workaround's downside is a very slight
power impact.

Note that applying this errata fixes deadlocks that are easy to
reproduce with real world applications.

The arguments for why this needs to be in the kernel are similar to the
arugments made in the patch "Workaround errata A12 818325/852422 A17
852423".
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There are several similar errata on Cortex A12 and A17 that all have the same workaround: setting bit[12] of the Feature Register.
Technically the list of errata are:

- A12 818325: Execution of an UNPREDICTABLE STR or STM instruction
  might deadlock.  Fixed in r0p1.
- A12 852422: Execution of a sequence of instructions might lead to
  either a data corruption or a CPU deadlock.  Not fixed in any A12s
  yet.
- A17 852423: Execution of a sequence of instructions might lead to
  either a data corruption or a CPU deadlock.  Not fixed in any A17s
  yet.

Since A12 got renamed to A17 it seems likely that there won't be any
future Cortex-A12 cores, so we'll enable for all Cortex-A12.

For Cortex-A17 I believe that all known revisions are affected and that all knows revisions means <= r1p2.  Presumably if a new A17 was
released it would have this problem fixed.

Note that in <https://patchwork.kernel.org/patch/4735341/> folks
previously expressed opposition to this change because:
A) It was thought to only apply to r0p0 and there were no known r0p0
   boards supported in mainline.
B) It was argued that such a workaround beloned in firmware.

Now that this same fix solves other errata on real boards (like
rk3288) point A) is addressed.

Point B) is impossible to address on boards like rk3288.  On rk3288
the firmware doesn't stay resident in RAM and isn't involved at all in
the suspend/resume process nor in the SMP bringup process.  That means
that the most the firmware could do would be to set the bit on "core
0" and this bit would be lost at suspend/resume time.  It is true that
we could write a "generic" solution that saved the boot-time "core 0"
value of this register and applied it at SMP bringup / resume time.
However, since this register (described as the "Feature Register" in
errata) appears to be undocumented (as far as I can tell) and is only
modified for these errata, that "generic" solution seems questionably
cleaner.  The generic solution also won't fix existing users that
haven't happened to do a FW update.

Note that in ARM64 presumably PSCI will be universal and fixes like
this will end up in ATF.  Hopefully we are nearing the end of this
style of errata workaround.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHuang Tao <huangtao@rock-chips.com>
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The change to simplify of_platform_populate() had an unintended
side-effect of introducing a build warning on s3c64xx:

In file included from arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:18:0:
arch/arm/mach-s3c64xx/common.h:27:30: error: 'struct device_node' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]

This adds a forward-declaration for the structure name in the
header to avoid the warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 850bea23 ("arm: Remove unnecessary of_platform_populate with default match table")
Acked-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>

commit 6bce5efd ("ARM: davinci: remove unused davinci-i2s pdata")
removed all instances of davinci-i2s pdata. However, on DM365 EVM,
the same platform data is passed to the voicecodec present on that
device.

This causes build breakage when voicecodec support is enabled:

arch/arm/mach-davinci/board-dm365-evm.c:764:17: error: 'dm365_evm_snd_data' undeclared (first use in this function)

voicecodec driver does not use the platform data as well, and
it is safe to remove it.

Fixes: 6bce5efd ("ARM: davinci: remove unused davinci-i2s pdata")
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Install the callbacks via the state machine.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153333.503198935@linutronix.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Noticed while making a copy of these files to tools/ where those kernel
files were being directly accessed, which we're not allowing anymore to
avoid that changes in the kernel side break tooling.

Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Eric Auger <eric.auger@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-82thftcdhj2j5wt6ir4vuyhk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Now that we have a different clock representation, switch to it.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMichael Turquette <mturquette@baylibre.com>
Link: lkml.kernel.org/r/20160629190535.11855-15-maxime.ripard@free-electrons.com

The smartq_map_io() and smartq_machine_init() functions are used by both
SmartQ 5 and SmartQ 7 machines and exported via the mach-smartq.h header
file. However that header file is not included by the mach-smartq.c file
that implements them, causing sparse warnings.

Include mach-smartq.h from mach-smartq.c to fix these warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>

In a configuration that enables CONFIG_UBSAN_SANITIZE_ALL, I am getting
a section mismatch warning for tegra20:

WARNING: arch/arm/mach-tegra/built-in.o(.data+0x6e0): Section mismatch in reference from the variable board_init_funcs to the function .init.text:paz00_init()

The array is no longer useful here since there is only one entry,
so we can simply call the function directly after checking
of_machine_is_compatible(). This fixes the section mismatch
and is easier to read.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

With the recent Kconfig changes we need to now enable
the PHYs to keep USB working.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch implements the write_sec callback that handle PL310
secure registers writes.
This callback is just a stub for now, to avoid system crash.
Later, it could handle SMC calls so that TZ handles the needed writes.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

This string is used by dump_stack and as we now support
more SoC's than just STiH415/6 it is misleading to have
the current string in the stack trace.

This patch updates it to be more generic for the STi
family of SoCs.

So instead of looking like this

[  271.672555] Hardware name: STiH415/416 SoC with Flattened Device Tree
[  271.678998] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14)
[  271.686746] [<c030bb54>] (show_stack) from [<c058bc4c>] (dump_stack+0x98/0xac)
[snip]

it now looks like this:

[    2.669879] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3-00026-g38a1ce6-dirty #76
[    2.677973] Hardware name: STi SoC with Flattened Device Tree
[    2.683723] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14)
[    2.691472] [<c030bb54>] (show_stack) from [<c058bc0c>] (dump_stack+0x98/0xac)
[snip]
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Acked-by: NPatrice Chotard <patrice.chotard@st.com>

Enable ADC and DAC IIO drivers for LPC18xx/43xx SoCs.
Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Fix indentation in iop3xx_std_desc
Signed-off-by: NJungseung Lee <js07.lee@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The AmLogic clock controller code is used by both arm and arm64
architectures. Explicitly select the core code for all Meson (32-bit
arm) builds, and also select the Meson8b driver when that machine is
built.
Signed-off-by: NMichael Turquette <mturquette@baylibre.com>
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

When we enter an exception, the current address limit should not apply
to the exception context: if the exception context wishes to access
kernel space via the user accessors (eg, perf code), it must explicitly
request such access.
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Ask firmware to put RAM in self-refresh mode and power system down.

    echo mem > /sys/power/state

See Documentation/power/states.txt
Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>