Add LPC32XX support in arch/arm/Kconfig and arch/arm/Makefile
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Platform support file for the PHY3250 mach id
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Misc support functions and prototypes used in the LPC32XX arch
and platforms
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Serial port setup support code
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Support for system suspend and resume
Signed-off-by: NKevin Wells <wellsk40@gmail.com>

Common drivers for the LPC32XX used on all platforms
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Clock driver for the LPC32XX architecture
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Debug (printascii) and IRQ handler macros for the LPC32XX
arch
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Header files for the LPC32xx arch
Signed-off-by: NKevin Wells <wellsk40@gmail.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

We should use perf_sample_data_init() to initialize struct
perf_sample_data.  As explained in the description of commit dc1d628a
("perf: Provide generic perf_sample_data initialization"), it is
possible for userspace to get the kernel to dereference data.raw,
so if it is not initialized, that means that unprivileged userspace
can possibly oops the kernel.  Using perf_sample_data_init makes sure
it gets initialized to NULL.

This conversion should have been included in commit dc1d628a, but it
got missed.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NKumar Gala <kumar.gala@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The Pstate transition latency check was added for broken F10h BIOSen
which wrongly contain a value of 0 for transition and bus master
latency. Fam11h and later, however, (will) have similar transition
latency so extend that behavior for them too.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The PCC cpufreq driver unmaps the mailbox address range if any CPUs fail to
initialise, but doesn't do anything to remove the registered CPUs from the
cpufreq core resulting in failures further down the line. We're better off
simply returning a failure - the cpufreq core will unregister us cleanly if
we end up with no successfully registered CPUs. Tidy up the failure path
and also add a sanity check to ensure that the firmware gives us a realistic
frequency - the core deals badly with that being set to 0.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Prevent double freeing on error path.
Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The pcc specification documents an _OSC method that's incompatible with the
one defined as part of the ACPI spec. This shouldn't be a problem as both
are supposed to be guarded with a UUID. Unfortunately approximately nobody
(including HP, who wrote this spec) properly check the UUID on entry to the
_OSC call. Right now this could result in surprising behaviour if the pcc
driver performs an _OSC call on a machine that doesn't implement the pcc
specification. Check whether the PCCH method exists first in order to reduce
this probability.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch fixes a build failure [1-4] in the atmel_serial code introduced by
patch the patch ARM: 6092/1: atmel_serial: support for RS485
communications (e8faff73)

The build failure was caused by missing struct field and missing defines
for the avr32 board - the patch fixes this.

[1] http://kisskb.ellerman.id.au/kisskb/buildresult/2575242/ - first failure in linux-next, may 11th
[2] http://kisskb.ellerman.id.au/kisskb/buildresult/2816418/ - still exists as of today
[3] http://kisskb.ellerman.id.au/kisskb/buildresult/2617511/ - first failure in Linus' tree - May 20th - did really no one notice this?!
[4] http://kisskb.ellerman.id.au/kisskb/buildresult/2813956/ - still exists in Linus' tree as of today
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Several MIPS platforms don't set pci_controller::io_map_base for their
PCI bridges.  This results in a panic in pci_iomap().  (The panic is
conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI
MIPS systems.)
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: linux-mips@linux-mips.org
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: 584784@bugs.debian.org
Patchwork: https://patchwork.linux-mips.org/patch/1377/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Currently, the eth devices are probed in the inverse order, first
au1xxx_eth1_device and then au1xxx_eth0_device. On the GPR board,
this makes trouble:

  # ifconfig|grep HWaddr
  eth0      Link encap:Ethernet  HWaddr 00:50:C2:0C:30:01
  eth1      Link encap:Ethernet  HWaddr 66:22:01:80:38:10

A bogous ethernet hwaddr is assigned to the first device and
au1xxx_eth0_device is mapped to eth1, which even does not work
properly. With this patch, the problems are gone:

  # ifconfig|grep HWaddr
  eth0      Link encap:Ethernet  HWaddr 66:22:11:32:38:10
  eth1      Link encap:Ethernet  HWaddr 66:22:11:32:38:11
Signed-off-by: NWolfgang Grandegger <wg@denx.de>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1473/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This SoC has only one ethernet MAC, so prevent registration of a second one.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1482/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

For 64-bit, we must use DADDU and DSUBU.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1483/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

As a relativly new ABI N32 should only have received the getdents64(2) but
instead it only had getdents(2).  This was noticed as a performance anomaly
in glibc.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch fixes a regression introduced by commit "MIPS: Alchemy: MTX-1:
Use linux gpio api." (bb706b28) which broke
PCI bus operation. The problem is caused by alchemy_gpio2_enable() which
resets the GPIO2 block. Two PCI signals (PCI_SERR and PCI_RST) are connected
to GPIO2 and they obviously do not to like the reset. Since GPIO2 is
correctly initialized by the boot monitor (YAMON) it is not necessary to
call this function, so just remove it.

Also replace gpio_set_value() with alchemy_gpio_set_value() to avoid
problems in case gpiolib gets initialized after PCI. And since alchemy
gpio_set_value() calls au_sync() we don't have to au_sync() again later.
Signed-off-by: NBruno Randolf <br1@einfach.org>
To: linux-mips@linux-mips.org
To: manuel.lauss@googlemail.com
Patchwork: https://patchwork.linux-mips.org/patch/1448/Tested-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Quoting from Jiri Slaby's patch of a similar nature for x86:

    When initrd is in use and a driver does request_module() in its
    module_init (i.e. __initcall or device_initcall), a modprobe
    process is created with VDSO mapping. But VDSO is inited even in
    __initcall, i.e. on the same level (at the same time), so it may
    not be inited yet (link order matters).

Move init_vdso up to subsys_initcall to avoid the issue.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Patchwork: http://patchwork.linux-mips.org/patch/1386/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

In addition to being useless, it was mis-spelled.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Cc: David Daney <ddaney@caviumnetworks.com>
Patchwork: http://patchwork.linux-mips.org/patch/1385/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The 4600 family code reads registers to differentiate between two ASIC
variants, but this was being done prior to the register setup. This moves
register setup before the reading code.
Signed-off-by: NDavid VomLehn <dvomlehn@cisco.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1392/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 3fea6026 ("Input: twl40300-keypad - fix handling of "all
ground" rows") broke compilation as I managed to use non-existent
keycodes.
Reported-by: NArjan van de Ven <arjan@infradead.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

qnap_tsx1x_register_flash is only called by qnap_ts219_init and
qnap_ts41x_init which both live in .init.text, too.  So the move is OK.

This fixes the following warning in kirkwood_defconfig:
	WARNING: vmlinux.o(.text+0x9334): Section mismatch in reference from the function qnap_tsx1x_register_flash() to the variable .init.data:qnap_tsx1x_spi_slave_info
	The function qnap_tsx1x_register_flash() references
	the variable __initdata qnap_tsx1x_spi_slave_info.
	This is often because qnap_tsx1x_register_flash lacks a __initdata
	annotation or the annotation of qnap_tsx1x_spi_slave_info is wrong.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

the different putc variants used an initialized local static variable
which is broken since

	5de813b6 (ARM: Eliminate decompressor -Dstatic= PIC hack)

This needs to be initialized at runtime and so needs to be global.
While at it give it a better name.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We need mach/hardware.h for CLPS7111_VIRT_BASE.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We need a waituart macro.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

mov rx, =<immediate> isn't valid, use #<immediate> instead.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We need asm/memory.h for NS9XXX_CSxSTAT_PHYS (via mach/memory.h).
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

IO_BASE shoule be IO_VIRT, and IO_START should be IO_PHYS. We also need
mach/hardware.h for these definitions.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 2a6b6976
(ACPI: Store NVS state even when entering suspend to RAM) caused the
ACPI suspend code save the NVS area during suspend and restore it
during resume unconditionally, although it is known that some systems
need to use acpi_sleep=s4_nonvs for hibernation to work.  To allow
the affected systems to avoid saving and restoring the NVS area
during suspend to RAM and resume, introduce kernel command line
option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its
alias temporarily (add acpi_sleep=s4_nonvs to the feature removal
file).

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 .
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Ntomas m <tmezzadra@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

hpet_disable is called unconditionally on machine reboot if hpet support
is compiled in the kernel.
hpet_disable only checks if the machine is hpet capable but doesn't make
sure that hpet has been initialized.

[ tglx: Made it a one liner and removed the redundant hpet_address check ]
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NVenkatesh Pallipadi <venki@google.com>
LKML-Reference: <alpine.DEB.2.00.1007211726240.22235@kaball-desktop>
Cc: stable@kernel.org
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

We don't need more than a page, and vmalloc() is slower (much
slower recently due to a regression).
Signed-off-by: NAvi Kivity <avi@redhat.com>

In no-direct mapping, we mark sp is 'direct' when we mapping the
guest's larger page, but its access is encoded form upper page-struct
entire not include the last mapping, it will cause access conflict.

For example, have this mapping:
        [W]
      / PDE1 -> |---|
  P[W]          |   | LPA
      \ PDE2 -> |---|
        [R]

P have two children, PDE1 and PDE2, both PDE1 and PDE2 mapping the
same lage page(LPA). The P's access is WR, PDE1's access is WR,
PDE2's access is RO(just consider read-write permissions here)

When guest access PDE1, we will create a direct sp for LPA, the sp's
access is from P, is W, then we will mark the ptes is W in this sp.

Then, guest access PDE2, we will find LPA's shadow page, is the same as
PDE's, and mark the ptes is RO.

So, if guest access PDE1, the incorrect #PF is occured.

Fixed by encode the last mapping access into direct shadow page
Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Oooops... we missed these. We incorrectly converted strings
used when parsing the device-tree on pseries, thus breaking
access to drconf memory and hotplug memory.

While at it, also revert some variable names that represent
something the FW calls "lmb" and thus don't need to be converted
to "memblock".
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---

This adds some debug output to our MMU hash code to print out some
useful debug data if the hypervisor refuses the insertion (which
should normally never happen).
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---

There's a couple of nasty bugs lurking in our huge page hashing code.

First, we don't check the access permission atomically with setting
the _PAGE_BUSY bit, which means that the PTE value we end up using
for the hashing might be different than the one we have checked
the access permissions for.

We've seen cases where that leads us to try to use an invalidated
PTE for hashing, causing all sort of "interesting" issues.

Then, we also failed to set _PAGE_DIRTY on a write access.

Finally, a minor tweak but we should return 0 when we find the
PTE busy, in order to just re-execute the access, rather than 1
which means going to do_page_fault().
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---