This removes <mach/hardware.h> and <mach/db8500-regs.h>
from the Ux500, merging them into the local include
"db8500-regs.h" in mach-ux500. There is some impact
outside the ux500 machine, but most of it is dealt with
in earlier patches.

Contains portions of a clean-up patch from Arnd Bergmann.

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is only one instance of the platform data for synaptics_i2c_rmi4
in the mainline kernel, so there is no point of pretending its
variable here. The only member that has a dependency on the platform
is actually the interrupt number, and there is a field in the
i2c_client structure that gets initialized from the board info,
so we can trivially move the board_into into the platform without
knowledge of the platform_data structure.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This header file only contains platform data structure definitions,
so it's straightforward to move.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[Delete one include rather than move it]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ux500 clock driver was including <mach/db8500-regs.h>
which will not work when building for multiplatform support
since <mach/*> is going away.

Pass the base adresses in the init call instead.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Mike Turquette <mturquette@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This pushes the knowledge of physical addresses down into
the debug macro so we can get rid of the <mach/hardware.h>
dependency.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This moves the Ux500 debug macro to the debug headers to
make way for multiplatform support.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This untangles the final bits of the prcmu code from the platform
code:

* The IRQ_PRCMU_* definitions move from irqs-db8500.h into prcmu.c
  because they are only of local significance.
* u8500_thsens_device goes into the prcmu, because it uses a PRCMU
  IRQ that the platform does not see.
* IRQ_DB8500_AB8500 and IRQ_PRCMU_BASE go into the platform data
  because the PRCMU does not see it.
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[Fixed a oneliner bug]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We are trying to decompose and decentralize the code in
the DB8500 PRCMU out into subdrivers. The code moved in
this patch concerns a group of functions used for
decoupling and recoupling the IRQs from the GIC. During
sleep and idle the Ux500 system will transfer all IRQ
handling to the PRCMU using these functions.

Basically we are left with the two alternatives of code
placement as:

- arch/arm/mach-ux500/pm.c - this because the code is
  closely related to the GIC, and takes ownership of
  some of the registers from the PRCMU related to this
  PM functionality.

- drivers/mfd/db8500-prcmu-pm.c - because the code is
  affecting stuff in the PRCMU register range. But then
  this code needs to remap and handle GIC registers.

This patch implementation is taking the first approach.

Currently the cpuidle driver is the only piece of code
using this set of functions, but it will later also be
used by the suspend/resume code which is currently under
review.

The header file is moved to:
<linux/platform_data/arm-ux500-pm.h>
The function prototypes need to be placed in a globally
visible header since the CPUidle code is planned to move
out to drivers/cpuidle.
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
Acked-by: NRickard Andersson <rickard.andersson@stericsson.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We cannot use a global variable stored in <mach/hardware.h> to
find the base address of the PRCMU. The real resource is already
there from the board, so use this to look up the base address
instead.

Currently the patch is kept minimal so as not to interfere with
other work being done on refactoring this driver, but at a later
point the defines using (prcmu_base + 0xnnn) need to be replaced
by pure offset defined for (0xnnn) and the base inlined with the
readl()/writel() and similar codepaths.
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch will make an early remapping of the PRCMU, to be
used when setting up the clocks, that will call down into parts
of the PRCMU driver before it is probed.

Going forward this will be removed like this:

- The mailbox subsystem need to be merged.
  http://marc.info/?l=linux-kernel&m=136314559201983&w=2

- At this point the PRCMU clock code can be moved over to the
  ux500 clock driver in drivers/clk/ux500/* and maintained
  there in a decentralized manner.

- This early initcall and PRCMU base parameters become part of
  the ux500_clk_init() call instead.

Cc: Suman Anna <s-anna@ti.com>
Cc: Loic Pallardy <loic.pallardy@st.com>
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 1d9d8639 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") fixed a crash when doing PEBS performance profiling
after resuming, but in using init_debug_store_on_cpu() to restore the
DS_AREA mtrr it also resulted in a new WARN_ON() triggering.

init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU
cross-calls to do the MSR update.  Which is not really valid at the
early resume stage, and the warning is quite reasonable.  Now, it all
happens to _work_, for the simple reason that smp_call_function_single()
ends up just doing the call directly on the CPU when the CPU number
matches, but we really should just do the wrmsr() directly instead.

This duplicates the wrmsr() logic, but hopefully we can just remove the
wrmsr_on_cpu() version eventually.
Reported-and-tested-by: NParag Warudkar <parag.lkml@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.

The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Atomic pool should always be allocated from DMA zone if such zone is
available in the system to avoid issues caused by limited dma mask of
any of the devices used for making an atomic allocation.
Reported-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Cc: Stable <stable@vger.kernel.org>	[v3.6+]

In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be
compared against __BYTE_ORDER in preprocessor conditionals where these are
exposed to userspace (that is they're not inside __KERNEL__ conditionals).

However, in the main kernel the norm is to check for
"defined(__XXX_ENDIAN)" rather than comparing against __BYTE_ORDER and
this has incorrectly leaked into the userspace headers.

The definition of struct stat64 in M32R's asm/stat.h is wrong in this way.
 Note that userspace will likely interpret the field order incorrectly as
the big-endian variant on little-endian machines - depending on header
inclusion order.

[!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
be better to fix the ordering of st_blocks and __pad4 in struct stat64.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The OpenRISC arch doesn't actually have the virt_to_bus methods
Signed-off-by: NJonas Bonn <jonas@southpole.se>

The recent move to GPIO descriptors breaks the OpenRISC build.  Requiring
gpiolib resolves this; using gpiolib exclusively is also the recommended
way forward for all arches by the developers working on these GPIO changes.
The non-gpiolib implementation for OpenRISC never worked anyway...
Signed-off-by: NJonas Bonn <jonas@southpole.se>

Fix regression introduced by commit d2323cf7 ("onewire: w1-gpio: add
ext_pullup_enable pin in platform data") which added a gpio entry to the
platform data, but did not add the required initialisers to the board
files using it. Consequently, the driver would request gpio 0 at probe,
which could break other uses of the corresponding pin.

On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for
instance, breaks SPI0 on at91sam9g20.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In commit 887cbce0 ("arch Kconfig: centralise ARCH_NO_VIRT_TO_BUS")
I introduced the config sybmol HAVE_VIRT_TO_BUS and selected that where
needed.  I am not sure what I was thinking.  Instead, just directly
select VIRT_TO_BUS where it is needed.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The definitions have move around recently, causing build errors
in spear3xx for all configurations:

spear3xx.c:47:5: error: 'PL080_BSIZE_16' undeclared here (not in a function)
spear3xx.c:47:23: error: 'PL080_CONTROL_SB_SIZE_SHIFT' undeclared here (not in a function)
spear3xx.c:48:22: error: 'PL080_CONTROL_DB_SIZE_SHIFT' undeclared here (not in a function)
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Alessandro Rubini <rubini@gnudd.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>

The ab8500 device is a child of the prcmu device, which is a memory mapped
bus device, whose children are addressable using physical memory addresses,
not using mailboxes, so a mailbox number in the ab8500 node cannot be
parsed by DT. Nothing uses this number, since it was only introduced
as part of the failed attempt to clean up prcmu mailbox handling, and
we can simply remove it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch adds #dma-cells property to PL330 DMA controller nodes for
supporting generic dma dt bindings on SOCFPGA platform. #dma-channels
and #dma-requests are not required now but added in advance.
Signed-off-by: NPadmavathi Venna <padma.v@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

When building a multiplatform kernel, we could end up with a smaller
number of GPIOs than the one required by the platform the kernel was
running on.

Sort the max GPIO number by descending order so that we always take the
highest number required.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Rob Herring has observed that c81611c4 "xen: event channel arrays are
xen_ulong_t and not unsigned long" introduced a compile failure when building
without CONFIG_AEABI:

/tmp/ccJaIZOW.s: Assembler messages:
/tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'

Will Deacon pointed out that this is because OABI does not require even base
registers for 64-bit values. We can avoid this by simply using the existing
atomic64_xchg operation and the same containerof trick as used by the cmpxchg
macros. However since this code is used on memory which is shared with the
hypervisor we require proper atomic instructions and cannot use the generic
atomic64 callbacks (which are based on spinlocks), therefore add a dependency
on !GENERIC_ATOMIC64. Since we already depend on !CPU_V6 there isn't much
downside to this.

While thinking about this we also observed that OABI has different struct
alignment requirements to EABI, which is a problem for hypercall argument
structs which are shared with the hypervisor and which must be in EABI layout.
Since I don't expect people to want to run OABI kernels on Xen depend on
CONFIG_AEABI explicitly too (although it also happens to be enforced by the
!GENERIC_ATOMIC64 requirement too).
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robherring2@gmail.com>
Acked-by: NStefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Commit f8c95fe6 (ARM: imx: support DEBUG_LL uart port selection for all
i.MX SoCs) had a typo that DEBUG_IMX50_IMX53_UART should be
DEBUG_IMX53_UART.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Commit 877c6856
("perf: Remove include of cgroup.h from perf_event.h") caused
this build failure if PERF_EVENTS is enabled:

   In file included from arch/s390/include/asm/perf_event.h:9:0,
                    from include/linux/perf_event.h:24,
                    from kernel/events/ring_buffer.c:12:
   arch/s390/include/asm/cpu_mf.h: In function 'qctri':
   arch/s390/include/asm/cpu_mf.h:61:12: error: 'EINVAL' undeclared (first use in this function)

cpu_mf.h had an implicit errno.h dependency, which was added
indirectly via cgroups.h but not anymore. Add it explicitly.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Tested-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NLi Zefan <lizefan@huawei.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Link: http://lkml.kernel.org/r/51385F79.7000106@huawei.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The tty below tty_port might get destroyed by the tty layer
while we hold a reference to it.
So we have to carry tty_port around...
Signed-off-by: NRichard Weinberger <richard@nod.at>

As we setup the SIGWINCH handler in tty_port_operations->activate
it makes sense to tear down it in ->destruct.
Signed-off-by: NRichard Weinberger <richard@nod.at>

arch/um/os-Linux/signal.c:18:8: error: conflicting types for 'sig_info'
In file included from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0:
arch/um/include/shared/as-layout.h:64:15: note: previous declaration of 'sig_info' was here
Signed-off-by: NSergei Trofimovich <slyfox@gentoo.org>
CC: Jeff Dike <jdike@addtoit.com>
CC: Richard Weinberger <richard@nod.at>
CC: "Martin Pärtel" <martin.partel@gmail.com>
CC: Al Viro <viro@zeniv.linux.org.uk>
CC: user-mode-linux-devel@lists.sourceforge.net
CC: user-mode-linux-user@lists.sourceforge.net
CC: linux-kernel@vger.kernel.org
Signed-off-by: NRichard Weinberger <richard@nod.at>

arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]
Signed-off-by: NSergei Trofimovich <slyfox@gentoo.org>
CC: Jeff Dike <jdike@addtoit.com>
CC: Richard Weinberger <richard@nod.at>
CC: Al Viro <viro@zeniv.linux.org.uk>
CC: user-mode-linux-devel@lists.sourceforge.net
CC: user-mode-linux-user@lists.sourceforge.net
CC: linux-kernel@vger.kernel.org
Signed-off-by: NRichard Weinberger <richard@nod.at>

This new version moves the skb_tx_timestamp in the main uml
driver. This should avoid the need to call this function in each
transport (vde, slirp, tuntap, ...). It also add support for ethtool
get_ts_info.
Signed-off-by: NPaul Chavent <paul.chavent@onera.fr>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

We always boot from PLL1, so let's have pll1_sys in the clks_init_on
list to have clk prepare/enable use count match the hardware status,
so that drivers managing pll1_sys like cpufreq can get the use count
right from the start.
Reported-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Commit ec221208 ("Disintegrate asm/system.h for Alpha") removed the
system.h include from boot/head.S, which puts the PAL_* asm constants
out of scope.

Include <asm/pal.h> so we can get building again.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Cc: David Rusling <david.rusling@linaro.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The orion5x-lacie-ethernet-disk-mini-v2.dts file was using
"marvell-orion5x-88f5182" as a compatible string, while it should have
been "marvell,orion5x-88f5182".
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

There is no need to have a #address-cells property in the MPIC Device
Tree node, and more than that, having it confuses the of_irq_map_raw()
logic, which will be used by the Marvell PCIe driver.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

During the system initialization, the orion_setup_cpu_mbus_target()
function reads the SDRAM address decoding registers to find out how
many chip-selects of SDRAM have been enabled, and builds a small array
with one entry per chip-select. This array is then used by device
drivers (XOR, Ethernet, etc.) to configure their own address decoding
windows to the SDRAM.

However, devices can only access the first 32 bits of the physical
memory. Even though LPAE is not supported for now, some Marvell boards
are now showing up with 8 GB of RAM, configured using two SDRAM
address decoding windows: the first covering the first 4 GB, the
second covering the last 4 GB. The array built by
orion_setup_cpu_mbus_target() has therefore two entries, and device
drivers try to set up two address decoding windows to the
SDRAM. However, in the device registers for the address decoding, the
base address is only 32 bits, so those two windows overlap each other,
and the devices do not work at all.

This patch makes sure that the array built by
orion_setup_cpu_mbus_target() only contains the SDRAM decoding windows
that correspond to the first 4 GB of the memory. To do that, it
ignores the SDRAM decoding windows for which the 4 low-order bits are
not zero (the 4 low-order bits of the base register are used to store
bits 32:35 of the base address, so they actually indicate whether the
base address is above 4 GB).

This patch allows the newly introduced armada-xp-gp board to properly
operate when it is mounted with more than 4 GB of RAM. Without that,
all devices doing DMA (for example XOR and Ethernet) do not work at
all.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Setting the reg-io-width to 1 byte represents more accurate
description of the HW.

This will fix an issue where UART driver causes kernel
panic during bootup. Gregory CLEMENT traced the issue to
autoconfig() in 8250.c, where the existence of FIFO is
checked from UART_IIR register. The register is now read as
32-bit value as the reg-io-width is set to 4-bytes. The
retuned value seems to contain bogus data for bits 31:8,
causing the issue.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The commit:

  48be9ac9 ARM: Dove: split legacy and DT setup

removed the RTC initialization.  This patch re-enables the RTC
via the DT.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

This patch modifies the Armada 370 Reference Design DTS file to enable
support for the two USB ports found on this board.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Commit 5b03df9a ("ARM: dove: switch to
DT clock providers") added "select COMMON_CLK_DOVE" to Marvell Dove's
Kconfig entry. But there's no Kconfig symbol COMMON_CLK_DOVE, which
makes this select statement a nop. It's probably a leftover of some
experimental code that never hit mainline. Drop it.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
driver clk_prepare_enable() this clock, otherwise there is a danger
the SoC will lockup when accessing RTC registers with the clock
disabled.
Reported-by: NSimon Baatz <gmbnomis@gmail.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NSimon Baatz <gmbnomis@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>