R/M classes of cpus can have memory covered by MPU which in turn might
configure RAM as Normal i.e. bufferable and cacheable. It breaks
dma_alloc_coherent() and friends, since data can stuck in caches now
or be buffered.

This patch factors out DMA support for NOMMU configuration into
separate entity which provides dedicated dma_ops. We have to handle
there several cases:
- configurations with MMU/MPU setup
- configurations without MMU/MPU setup
- special case for M-class, since caches and MPU there are optional

In general we rely on default DMA area for coherent allocations or/and
per-device memory reserves suitable for coherent DMA, so if such
regions are set coherent allocations go from there.

In case MMU/MPU was not setup we fallback to normal page allocator for
DMA memory allocation.

In case we run M-class cpus, for configuration without cache support
(like Cortex-M3/M4) dma operations are forced to be coherent and wired
with dma-noop (such decision is made based on cacheid global
variable); however, if caches are detected there and no DMA coherent
region is given (either default or per-device), dma is disallowed even
MPU is not set - it is because M-class implement system memory map
which defines part of address space as Normal memory.
Reported-by: NAlexandre Torgue <alexandre.torgue@st.com>
Reported-by: NAndras Szemzo <sza@esh.hu>
Tested-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Tested-by: NAndras Szemzo <sza@esh.hu>
Tested-by: NAlexandre TORGUE <alexandre.torgue@st.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
[hch: removed the dma_supported() implementation that isn't required anymore]
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Add ARCH_ACTIONS and mach-actions/owl.c for "actions,s500".
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Increase the maximum number of GPIOs on SoCFPGA as this platform
can have many GPIO controllers in the FPGA part.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a
ftrace operation to specify if registers need to saved/restored by
the ftrace handler. This is needed by kgraft and possibly other
ftrace-based tools, and the ARM architecture is currently lacking
this feature. It would also be the first step to support the
"Kprobes-on-ftrace" optimization on ARM.

This patch introduces a new ftrace handler that stores the registers
on the stack before calling the next stage. The registers are restored
from the stack before going back to the instrumented function.

A side-effect of this patch is to activate the support for
ftrace_modify_call() as it defines ARCH_SUPPORTS_FTRACE_OPS for the
ARM architecture.
Signed-off-by: NAbel Vesa <abelvesa@linux.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The config option name is now renamed to 'TIMER_OF' for consistency with
the CLOCKSOURCE_OF_DECLARE => TIMER_OF_DECLARE change.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

This patch provides all required callbacks required by the generic
get_user_pages_fast() code and switches x86 over - and removes
the platform specific implementation.
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170606113133.22974-2-kirill.shutemov@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

When both enable CONFIG_ARM_LPAE=y and CONFIG_VMSPLIT_3G_OPT=y, which
means use PAGE_OFFSET=0xB0000000 with ARM_LPAE, the kernel will boot
fail and stop after uncompressed:

   Starting kernel ...

   Uart base = 0x20001000
   watchdog reg = 0x20013000
   dtb addr = 0x80840308
   Uncompressing Linux... done, booting the kernel.

For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in:
   http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16

So we should make VMSPLIT_3G_OPT depends on !ARM_LPAE to avoid trigger
this bug.
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NYisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Wire up the existing arm64 support for SMBIOS tables (aka DMI) for ARM as
well, by moving the arm64 init code to drivers/firmware/efi/arm-runtime.c
(which is shared between ARM and arm64), and adding a asm/dmi.h header to
ARM that defines the mapping routines for the firmware tables.

This allows userspace to access these tables to discover system information
exposed by the firmware. It also sets the hardware name used in crash
dumps, e.g.:

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  pgd = ed3c0000
  [00000000] *pgd=bf1f3835
  Internal error: Oops: 817 [#1] SMP THUMB2
  Modules linked in:
  CPU: 0 PID: 759 Comm: bash Not tainted 4.10.0-09601-g0e8f38792120-dirty #112
  Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
  ^^^

NOTE: This does *NOT* enable or encourage the use of DMI quirks, i.e., the
      the practice of identifying the platform via DMI to decide whether
      certain workarounds for buggy hardware and/or firmware need to be
      enabled. This would require the DMI subsystem to be enabled much
      earlier than we do on ARM, which is non-trivial.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170602135207.21708-14-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

arm and arm64 share lot of code relative to parsing CPU capacity
information from DT, using that information for appropriate scaling and
exposing a sysfs interface for chaging such values at runtime.

Factorize such code in a common place (driver/base/arch_topology.c) in
preparation for further additions.
Suggested-by: NWill Deacon <will.deacon@arm.com>
Suggested-by: NMark Rutland <mark.rutland@arm.com>
Suggested-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJuri Lelli <juri.lelli@arm.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

all architectures converted
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This reverts commit 2947ba05.

Dan Williams reported dax-pmem kernel warnings with the following signature:

   WARNING: CPU: 8 PID: 245 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0x1f5/0x200
   percpu ref (dax_pmem_percpu_release [dax_pmem]) <= 0 (0) after switching to atomic

... and bisected it to this commit, which suggests possible memory corruption
caused by the x86 fast-GUP conversion.

He also pointed out:

 "
  This is similar to the backtrace when we were not properly handling
  pud faults and was fixed with this commit: 220ced16 "mm: fix
  get_user_pages() vs device-dax pud mappings"

  I've found some missing _devmap checks in the generic
  get_user_pages_fast() path, but this does not fix the regression
  [...]
 "

So given that there are known bugs, and a pretty robust looking bisection
points to this commit suggesting that are unknown bugs in the conversion
as well, revert it for the time being - we'll re-try in v4.13.
Reported-by: NDan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dann.frazier@canonical.com
Cc: dave.hansen@intel.com
Cc: steve.capper@linaro.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.

Since it is non-trivial to transparantly support both HWCAP and HWCAP2
capabilities in the cpu_feature() macro (which allows a module's hwcap
dependency and init routine to be declared using a single invocation of
module_cpu_feature_match()), support only HWCAP2 for now, which covers
the capabilities that are most likely to be useful in this manner.
Module dependencies on HWCAP will need to be declared explicitly via a
MODULE_DEVICE_TABLE(cpu, ...) declaration.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Create a dedicated Kconfig file in mach-stm32/ and move existing stm32
configs inside.
Signed-off-by: NAlexandre TORGUE <alexandre.torgue@st.com>

This patch provides all required callbacks required by the generic
get_user_pages_fast() code and switches x86 over - and removes
the platform specific implementation.
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Aneesh Kumar K . V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dann Frazier <dann.frazier@canonical.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20170316213906.89528-1-kirill.shutemov@linux.intel.com
[ Minor readability edits. ]
Signed-off-by: NIngo Molnar <mingo@kernel.org>

This converts the Gemini platform to ARMv4 multiplatform, deleting
the local <mach/*> include directory, moving an idiomatic local
idling function into the .machine_init() call and getting rid of
the Makefile.boot finally.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This platform survives physical to virtual patching
without any hickups, and can use AUTO_ZRELADDR.
We still need to keep Makefile.boot but it is now empty.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is no boardfiles or anything else using the fixed IRQs
anymore, switch the platform to use sparse IRQs and delete
the <mach/irqs.h> header.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Delete the Gemini boardfiles: we have corresponding, fully-featured
device trees for all these boards. Delete the referenced include
files. Delete the local config symbols, especially one for
"swapped memory", as all supported boards have swapped memory, and
would a new board be supported this is likely not the right way
to achieve it anyways. Only the Kconfig options in the central
arch/arm/Kconfig remains.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds initial and compulsory device tree support to the
Gemini ARMv4 platform.

We are selecting a bunch of "absolute minimals" for getting a working
system up with just device tree:

- We select USE_OF for natural reasons or nothing works.

- We select CLKSRC_OF and GEMINI_TIMER so we get timekeeping from
  the clocksource.

- We select GPIO_GEMINI because these are used as irqchips, and
  for a generic driver it is not reasonable for those to have to
  select every possible irqchip in the world to work, the platform
  should simply provide the available irqchips.

- We select a UART that can be exprected to work with
  SERIAL_OF_PLATFORM which is the name for an 8250 OF-probed
  serial port.

- We select the syscon-based reset controller: it's not fun when
  "reboot" doesn't work because of Kconfig, so we just select
  POWER_RESET and POWER_RESET_SYSCON.

- We perhaps a bit controversiallt select ARM_APPENDED_DTB, because
  this platform is using the ancient RedBoot, and can *NOT* be
  expected to upgrade its bootloaders. Appended device tree is
  simply how these devices have to work with device tree.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to enable device tree boot on this machine we must first
convert it to runtime-manage its irq handler, so do this.

Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. This includes caller
using __virt_to_phys() on image addresses instead of __pa_symbol(). This
is a generally useful debug feature to spot bad code (particulary in
drivers).
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Acked-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently, there's no good way to test for the presence of
set_memory_ro/rw/x/nx() helpers implemented by archs such as
x86, arm, arm64 and s390.

There's DEBUG_SET_MODULE_RONX and DEBUG_RODATA, however both
don't really reflect that: set_memory_*() are also available
even when DEBUG_SET_MODULE_RONX is turned off, and DEBUG_RODATA
is set by parisc, but doesn't implement above functions. Thus,
add ARCH_HAS_SET_MEMORY that is selected by mentioned archs,
where generic code can test against this.

This also allows later on to move DEBUG_SET_MODULE_RONX out of
the arch specific Kconfig to define it only once depending on
ARCH_HAS_SET_MEMORY.
Suggested-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are multiple architectures that support CONFIG_DEBUG_RODATA and
CONFIG_SET_MODULE_RONX. These options also now have the ability to be
turned off at runtime. Move these to an architecture independent
location and make these options def_bool y for almost all of those
arches.
Signed-off-by: NLaura Abbott <labbott@redhat.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz.  Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is enabled.

This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx.  Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd1 ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").

Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's).  I believe this choice
was rather an effect of coincidence instead of conscious choice.

On S3C24xx, the PWM counter is only 16 bit wide, and with the
typical 12MHz input clock that overflows every 5.5ms.  This works
with HZ=200 or higher but not with HZ=100 which needs a 10ms
interval between ticks.  On Later chips (S3C64xx, S5P and EXYNOS),
the counter is 32 bits and does not have this problem.

The new samsung_pwm_timer driver solves the problem by scaling the input
clock by a factor of 50 on S3C24xx, which makes it less accurate but
allows HZ=100 as well as CONFIG_NO_HZ with fewer wakeups.

Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: NLee Jones <lee.jones@linaro.org>
[Dropping of 200_HZ from S3C/S5P was suggested by Arnd]
Reported-by: NArnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene@kernel.org>
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
[Tested on Exynos5800]
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Acked-by: NKukjin Kim <kgene@kernel.org>
[Tested on S3C2440]
Tested-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NLee Jones <lee.jones@linaro.org>

This patch allows ARM guests to use GICv3 ITS on an arm64 host
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This patch introduces the MACH_STM32F746 to make possible to only select
STM32F746 pinctrl driver

By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
Signed-off-by: NAlexandre TORGUE <alexandre.torgue@st.com>

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.  It seems it
was needed when not every arch defined it.  However as of current code
the Kconfig option seems needless

 - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
   generic definition of API is present lib/atomic64.c
 - arches with native 64-bit atomics select it in arch/*/Kconfig and
   define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)
 - ia64

Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.comSigned-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ming Lin <ming.l@ssi.samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Instead of comparing the name to a magic string, use archdata to
explicitly communicate whether the arch timer is suitable for
direct vdso access.
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NScott Wood <oss@buserror.net>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

PCI_DOMAINS config should be selected for any SoCs
having more than a single PCIe controller. Without PCI_DOMAINS
config, only one PCIe controller gets registered.

Select PCI_DOMAINS in ARCH_MULTIPLATFORM if PCI is selected, since
it doesn't harm even if a platform has a single PCIe port.
Also remove PCI_DOMAINS being selected from other platform
specific configs.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Originally-from: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: NAlexandre TORGUE <alexandre.torgue@st.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: arnd@arndb.de
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: bruherrera@gmail.com
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: lee.jones@linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1474387259-18926-4-git-send-email-alexandre.torgue@st.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This reduces the Kconfig for the RealView by assuming we are
always booting from the device tree, and removing all the uses
of CONFIG_REALVIEW_DT and replacing with CONFIG_ARCH_REALVIEW.

Further:

- Drop REALVIEW_HIGH_PHYS_OFFSET: we don't use this with device
  tree.

- Drop the REALVIEW_EB_ARM11MP_REVB option: we now handle this
  by simply using another device tree.

- Drop the PB1176 secure flash option: this is defined in the
  PB1176 device tree but marked as "disabled", so users who
  want to use it can simply enable it in the device tree and
  go hacking around.

Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Enables CONFIG_HARDENED_USERCOPY checks on arm.

Based on code from PaX and grsecurity.
Signed-off-by: NKees Cook <keescook@chromium.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>

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>

Switch CLPS711X to multiplatform.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Change the Kconfig option logic to fullfil with the current approach.

A new Kconfig option is added, CONFIG_CLPS711X_TIMER and is selected by the
platform. Then the clocksource's Kconfig is changed to make this option
selectable by the user if the COMPILE_TEST option is set. Otherwise, it is
up to the platform's Kconfig to select the timer.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>