The Gemini has no need of a <mach/gpio.h> header as this is only
used by the machine-local gpio.c gpiochip driver, which is also
only using the irq_to_gpio() macro. Delete the file, move the single
macro into the driver and remove the NEED_MACH_GPIO_H flag.

Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The local <mach/gpio.h> file on the w90x900 is completely unused
and the platform does not define NEED_MACH_GPIO_H.

Cc: Wan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now that these custom GPIO accessors are only used from the
gpio chip in this machine, move the code out of the include
file and right next to the gpiochip implementation.

Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This dangerous function is not used in the kernel, so let's
just delete it.

Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

A few call sites inside mach-ixp4xx were still using the custom
ixp4xx GPIO API with gpio_line_* accessors, convert all these
to use the standard gpiolib functions instead. Also attempt to
request and label all GPIOs before use. Move the GPIO requests
to per-machine device_initcalls() so we are not dependent on the
GPIO chip to be available at machine_init time.

Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The PXA sub-architecture appears to have a custom <mach/gpio.h>
for no reason whatsoever. The file became completely empty
after Haojian removed the remaining content in
commit 157d2644
"ARM: pxa: change gpio to platform device".

That commit added these two lines:

However it seems like deleting the file has no effect
whatsoever on the kernel compilation.

Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The MMP sub-architecture appears to have a custom <mach/gpio.h>
for no reason whatsoever. The file became completely empty
after Haojian removed the remaining content in
commit 157d2644
"ARM: pxa: change gpio to platform device".

Cc: Eric Miao <eric.y.miao@gmail.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This alters the IOP platforms to pass a physical base for their
GPIO blocks and alters the driver to remap it when probing
instead of relying on the virtual addresses to be used.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This converts the IOP32x and IOP33x platforms to pass their
base address offset by a resource attached to a platform device
instead of using static offset macros implicitly passed
through <linux/gpio.h> including <mach/gpio.h>. Delete the
local <mach/gpio.h> and <asm/hardware/iop3xx-gpio.h> headers
and remove the selection of NEED_MACH_GPIO_H.

Pass the virtual address as a resource in the platform device
at this point for bisectability, next patch will pass the
physical address as is custom.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The kernel will now only use gpiolib to access GPIOs, so remove
the complex GPIO flag and the custom implementation.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Refrain from using the custom gpio_line_get() to read the power
key on the N2100, use the gpiolib function gpio_get() instead.
Also request the line in the GPIOs initicall, and move the poll
timer setup to that inicall so the gpio chip is available before
we request this GPIO and start to poll it.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As the IOP GPIO driver supports gpiolib we can use the standard
GPIO calls to issue a reset of the machine instead of using the
custom gpio_line_set/config calls. Also request the GPIO when
initializing the machine.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Move the IOP GPIO driver to live with its siblings in the
GPIO subsystem.

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

After the last architecture switched to generic hard irqs the config
options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
for !CONFIG_GENERIC_HARDIRQS can be removed.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Unlike global OOM handling, memory cgroup code will invoke the OOM killer
in any OOM situation because it has no way of telling faults occuring in
kernel context - which could be handled more gracefully - from
user-triggered faults.

Pass a flag that identifies faults originating in user space from the
architecture-specific fault handlers to generic code so that memcg OOM
handling can be improved.
Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Reviewed-by: NMichal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: azurIt <azurit@pobox.sk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Kernel faults are expected to handle OOM conditions gracefully (gup,
uaccess etc.), so they should never invoke the OOM killer.  Reserve this
for faults triggered in user context when it is the only option.

Most architectures already do this, fix up the remaining few.
Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Reviewed-by: NMichal Hocko <mhocko@suse.cz>
Acked-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: azurIt <azurit@pobox.sk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Keep arch/arm/Kconfig select statements sorted alphabetically.  I've
added a comment at the bottom of the main bank for CONFIG_ARM to this
effect so hopefully this will keep things more in order.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The A20-olinuxino-micro has the EMAC wired in. Enable it in the DT so
that we can use it.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The Cubieboard2, just like its A10 counterpart, has the Ethernet wired
in. Enable it in the DT.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The A20 has several muxing options for the EMAC. Yet, the currently
supported boards only use one set of them. Add that pin set to the DTSI.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The Allwinner A20 SoC also have the EMAC found on the A10 and A10s.
Enable the support for it in the DTSI.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Currently hugepage migration works well only for pmd-based hugepages
(mainly due to lack of testing,) so we had better not enable migration of
other levels of hugepages until we are ready for it.

Some users of hugepage migration (mbind, move_pages, and migrate_pages) do
page table walk and check pud/pmd_huge() there, so they are safe.  But the
other users (softoffline and memory hotremove) don't do this, so without
this patch they can try to migrate unexpected types of hugepages.

To prevent this, we introduce hugepage_migration_support() as an
architecture dependent check of whether hugepage are implemented on a pmd
basis or not.  And on some architecture multiple sizes of hugepages are
available, so hugepage_migration_support() also checks hugepage size.
Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Rik van Riel <riel@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Olof Johansson reports that the tests against HZ_FIXED seem
non-functional.  Fix this by using '0' as a sentinel for "not
specified" and test against that instead.
Reported-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes the following build error:

/tmp/cce439dZ.s: Assembler messages:
/tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb '
/tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb '
/tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb '
/tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb '
/tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb '
/tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb '
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

As of 8d3214c4 ("sh_eth: remove 'register_type' field from 'struct
sh_eth_plat_data'") is is no longer necessary or correct to use the
'register_type' field from 'struct sh_eth_plat_data' and doing so results
in a build error.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit a6e56c28 (ARM: pxa: ssp: add DT bindings) causes warnings
when built:

arch/arm/plat-pxa/ssp.c: In function 'pxa_ssp_probe':
arch/arm/plat-pxa/ssp.c:145:17: warning: 'dma_spec.args[0]' may be used
	uninitialized in this function [-Wmaybe-uninitialized]

Resolve by checking return values and aborting when lookups fail.

Cc: Daniel Mack <zonque@gmail.com>
Cc: Mark Brown <broonie@linaro.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 01956597 introduced a NEON accelerated version of the xor_blocks()
function, but it needs the changes in this patch to allow it to be built
as a module rather than statically into the kernel.

This patch creates a separate module xor-neon.ko which exports the NEON
inner xor_blocks() functions depended upon by the regular xor.ko if it
is built with CONFIG_KERNEL_MODE_NEON=y
Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When linux is running as dom0, Xen doesn't show the physical cpu but a
virtual CPU.
On some ARM SOC (for instance the exynos 5250), linux registers callbacks
for cpuidle and cpufreq. When these callbacks are called, they will modify
directly the physical cpu not the virtual one. It can impact the whole board
instead of only dom0.
Signed-off-by: NJulien Grall <julien.grall@linaro.org>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen_pm_init was unconditionally setting pm_power_off and arm_pm_restart
function pointers. This breaks multi-platform kernels. Make this
conditional on running as a Xen guest and make it a late_initcall to
ensure it is setup after platform code for Dom0.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: stable@vger.kernel.org

Since pwm-samsung bindings require at least one clock to be specified,
this patch adds the missing clocks and clock-names properties to specify
clocks used by PWM block on Exynos4 SoCs.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The SMAP register offsets in the versatile PCI controller code were
all off by four.  (This didn't have any observable bad effects
because on this board PHYS_OFFSET is zero, and (a) writing zero to
the flags register at offset 0x10 has no effect and (b) the reset
value of the SMAP register is zero anyway, so failing to write SMAP2
didn't matter.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: stable@vger.kernel.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

The versatile PCI controller code was confused between the
PCI I/O window (at 0x43000000) and the first PCI memory
window (at 0x44000000). Pass the correct base address to
pci_remap_io() so that PCI I/O accesses work.

Since the first PCI memory window isn't used at all (it's
an odd size), rename the associated variables and labels
so that it's clear that it isn't related to the I/O window.

This has been tested and confirmed to fix PCI I/O accesses
both on physical PB926+PCI backplane hardware and on QEMU.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: stable@vger.kernel.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

The PCI controller code for the Versatile board has never had the
correct IRQ mapping for hardware.  For many years it had an odd
mapping ("all interrupts are int 27") which aligned with the
equivalent bug in QEMU.  However as of commit 1bc39ac5
the mapping changed and no longer matched either hardware or QEMU,
with the result that any PCI card beyond the first in QEMU would
not have functioning interrupts; for example a boot with a SCSI
controller would time out as follows:

 ------------
 sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92
 sym0: SCSI BUS has been reset.
 scsi0 : sym-2.2.3
 [...]
 scsi 0:0:0:0: ABORT operation started
 scsi 0:0:0:0: ABORT operation timed-out.
 scsi 0:0:0:0: DEVICE RESET operation started
 scsi 0:0:0:0: DEVICE RESET operation timed-out.
 scsi 0:0:0:0: BUS RESET operation started
 scsi 0:0:0:0: BUS RESET operation timed-out.
 scsi 0:0:0:0: HOST RESET operation started
 sym0: SCSI BUS has been reset
 ------------

Fix the mapping so that it matches real hardware (checked against the
schematics for PB926 and backplane, and tested against the hardware).
This allows PCI cards using interrupts to work on hardware for the
first time; this change will also work with QEMU 1.5 or later, where
the equivalent bugs in the modelling of the hardware have been fixed.

Although QEMU will attempt to autodetect whether the kernel is
expecting the long-standing "everything is int 27" mapping or the one
hardware has, for certainty we force it into "definitely behave like
hardware mode"; this will avoid unexpected surprises later if we
implement sparse irqs. This is harmless on hardware.

Thanks to Paul Gortmaker for bisecting the problem and finding an initial
solution, to Russell King for providing the correct interrupt mapping,
and to Guenter Roeck for providing an initial version of this patch
and prodding me into relocating the hardware and retesting everything.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: stable@vger.kernel.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

Manual trigger for events missed as a result of splitting a
scatter gather list and DMA'ing it in batches. Add a helper
function to trigger a channel incase any such events are missed.
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Second UART doesn't have modem interface, so any attempt to use set_mctrl() it
produce unwanted garbage on the line. There's no such 0x100 register offset
for the second UART either.
Signed-off-by: NPetr Štetiar <ynezz@true.cz>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRyan Mallon <rmallon@gmail.com>

This is almost cosmetic: we achieve a bit of consistency with
other clocksource drivers by using the CLOCKSOURCE_OF_DECLARE
macro for the boilerplate code.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>

Signed-off-by: NDan Aloni <alonid@stratoscale.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Support UART0 debug ll on Hisilicon Hi3620 SoC & Hi3716 SoC.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that we support a timer-backed delay loop, I'm quickly getting sick
and tired of people complaining that their beloved bogomips value has
decreased. You know who you are!

This patch removes the bogomips line from /proc/cpuinfo, based on the
reasoning that any program parsing this is already broken and, as such,
won't be further broken if the field is removed.
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>