With the introduction of iomap changes platform init code
fails for emu.c if CONFIG_OMAP3_EMU is selected:

arch/arm/mach-omap2/emu.c:35:8: error:
'L4_EMU_34XX_BASE' undeclared here (not in a function)
Signed-off-by: NTony Lindgren <tony@atomide.com>

Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.

As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.

Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.

Also make sure the legacy omap1-keypad.c driver builds
if selected for 2420 based systems.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is needed to minimize io.h so the SoC specific io.h
for ARMs can removed.

Note that minimal driver changes for DSS and RNG are needed to
include cpu.h for SoC detection macros.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to have these defines in plat/io.h.

Note that we now need to ifdef omap_read/write calls
as they will be available for omap1 only.

While at it, clean up the includes to group them like
they typically are grouped.
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to have these in plat/io.h.

While at it, clean up the includes to group them
like they typically are grouped.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This way we can remove omap_read/write call from the GPIO driver
and remove include to linux/io.h.

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We don't want to keep it in io.h as we want to remove io.h
for omap2+ for the common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

These should be local to omap2/3/4.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove omap_{read,write}l() from the 24xx PM code.  The clocksource
code should now handle what this was supposed to do.

Tested on N800 -- but it's hard to say whether this fixes anything.
OMAP24xx static suspend path is currently broken, and this patch
doesn't change that.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rob Herring <robherring2@gmail.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Flag single_channel in struct omap2_mcspi_device_config is not used
by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h
and affected board files.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that most platforms don't need disable_fiq and arch_ret_to_user
macros, we can remove the empty macros or empty entry-macro.S files.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRyan Mallon <rmallon@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>

With the removal of disable_fiq on rpc and addition MULTI_IRQ_HANDLER,
entry-macro.S is no longer needed for platforms that select
MULTI_IRQ_HANDLER and the include of it can be conditional.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>

Only rpc uses disable_fiq macro. Change it to a run-time installed
default FIQ handler. The handler is installed before FIQ is enabled
so the behavior should be unchanged.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NNicolas Pitre <nico@linaro.org>

Only 3 platforms need arch_ret_to_user macro, so add ARCH_HAS_RET_TO_USER
kconfig option and make iop13xx, iop32x and iop33x select it.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NNicolas Pitre <nico@linaro.org>

Upstream commit d1fce9c1

   "ARM: restart: bcmring: use new restart hook"

breaks building of this platform, since what used to be the
last field of the MACHINE_START/END block didn't have a
trailing comma.  Once another field was added below, we get:

arch/arm/mach-bcmring/arch.c:198: error: request for member 'restart' in something not a structure or union
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NJiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Remove BCMRING DMA map code which is no longer used.

This also fixes a build error with dma.c introduced by
bfcd2ea6.
Signed-off-by: NJiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Enable use of the generic atomic64 implementation on AVR32 platforms.
Without this the kernel fails to build as the architecture does not
provide its version.
Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Defining memscan() as memchr() is wrong, because the return values of
memscan() and memchr() are different when the character is not found.  So
use the generic memscan() implementation to fix this.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

__kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
This is actually ok since the code in question is predicated on
CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
macro is probably better.
Acked-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Linux uses two PMD entries for a PTE with the classic page table format,
covering 2MB range. However, the __pte_free_tlb() function only adds a
single TLB flush corresponding to 1MB range covering 'addr'. On
Cortex-A15, level 1 entries can be cached by the TLB independently of
the level 2 entries and without additional flushing a PMD entry would be
left pointing at the wrong PTE. The patch limits the TLB flushing range
to two 4KB pages around the 1MB boundary within PMD.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added
empty NODE event definitions for the ARM PMU implementations. This was
merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
out on the original patch.

This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").

This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified.  This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.

This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware.  Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.

The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.

This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.

Thanks to Will Deacon for spotting this.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.

This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.

Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.

Cc: stable <stable@vger.kernel.org>
Tested-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This reverts commit 3c424f35.

Joachim Eastwood reports:
| "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
| Commit: 3c424f35 in Linus master
|
| Breaks booting on my custom AT91RM9200 board.
| There isn't any error messages or anything that indicates what goes
| wrong it just stops after; Uncompressing Linux... done, booting the
| kernel.
|
| Reverting it makes my board boot again.

and further debugging reveals:

ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
ioremap: found: addr fef74000 => fed73000 => fed73400

Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
0xfffff.  This happens because the changed if statement becomes:

                if (0x00200 > 0xfffff ||
                    0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
and therefore:
                if (0x00200 > 0xfffff ||
                    0x000003ff > 0x00203fff)

The if condition fails, and so we _believe_ that the SRAM mapping fits
our request.  Clearly that's totally bogus.

Moreover, the original premise of the 'fix' patch was wrong:
|    The condition checking boundaries of the requested and existing
|    mappings didn't take in-page offset into consideration though,
|    which lead to obscure and hard to debug problems when requested
|    mapping crossed end of the static one.

as the code immediately above this loop does:

        size = PAGE_ALIGN(offset + size);

so 'size' already contains the requested offset into the page.

So, revert the broken 'fix'.
Acked-by: NNicolas Pitre <nico@linaro.org>

Both sparc 32-bit's software divide assembler and MPILIB provide
clz_tab[] with identical contents.

Break it out into a seperate object file and select it when
SPARC32 or MPILIB is set.
Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJames Morris <jmorris@namei.org>

Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Return to behaviour perf MSR had before introducing vPMU in case vPMU
is disabled. Some guests access those registers unconditionally and do
not expect it to fail.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:

    [bits 32]
    global _start
    SECTION .text
    _start: syscall

(I tested it with winxp and linux - both always crashed)

    Disassembly of section .text:

    00000000 <_start>:
       0:   0f 05                   syscall

The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)

Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.

Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.

[mtosatti: cleanup/beautify code]
Signed-off-by: NStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.

[mtosatti: cleanup/beautify code]
Signed-off-by: NStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

commit 43db595e
(sh: switch to GENERIC_PCI_IOMAP)
failed to take into account the PCI channels's
io_map_base for mapping IO BARs.
This also caused a new warning on sh.

Fix this, without re-introducing code duplication,
by setting NO_GENERIC_PCI_IOPORT_MAP
and supplying a sh-specific __pci_ioport_map.
Reported-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

commit eab90291
(mips: switch to GENERIC_PCI_IOMAP)
failed to take into account the PCI controller's
io_map_base for mapping IO BARs.
This also caused a new warning on mips.

Fix this, without re-introducing code duplication,
by setting NO_GENERIC_PCI_IOPORT_MAP
and supplying a mips-specific __pci_ioport_map.
Reported-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit d761f0c5.

Patch: "cpu: Register a generic CPU device on architectures that currently do not"
(sha1: 9f13a1fd)

selects GENERIC_CPU_DEVICES for Microblaze which register cpu.
My patch was done in the same time that's why cpu was registered twice which
caused this warning log:

------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb0/0xdc()
sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0'
Modules linked in:
...
Signed-off-by: NMichal Simek <monstr@monstr.eu>

This commit removes the reboot quirk originally added by commit
e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").

Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
6.5.102) revealed the following regarding the reboot hang
problem:

- v2.6.37 reboot=bios was needed.

- v2.6.38-rc1: behavior changed, reboot=acpi is needed,
  reboot=kbd and reboot=bios results in system hang.

- v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
  VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
  patch sets a quirk for VersaLogic Menlow boards that forces the use
  of reboot=bios, which doesn't work anymore.

- v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method
  preferences") changed the default reboot method to acpi prior to
  v3.0-rc1, which means the default behavior is appropriate for the
  Ocelot.  No VersaLogic quirk is required.

The Ocelot board used for testing can successfully reboot w/out
having to pass any reboot= arguments for all 3 current versions
of the BIOS.
Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Skip DMI checks for vendor specific reboot quirks if the user
passed in a reboot= arg on the command line - we should never
override user choices.
Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Smatch complains that we have some inconsistent NULL checking.

If "task" were NULL then it would lead to a NULL dereference
later. We can remove this test because earlier on in the
function we have:

 if (!task)
	task = current;
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Clemens Ladisch <clemens@ladisch.de>
Link: http://lkml.kernel.org/r/20120128105246.GA25092@elgon.mountainSigned-off-by: NIngo Molnar <mingo@elte.hu>

Since commit 576d2f25 "ARM: add
generic ioremap optimization by reusing static mappings" ioremap()
is trying to reuse existing static mapping when possible.

The condition checking boundaries of the requested and existing
mappings didn't take in-page offset into consideration though,
which lead to obscure and hard to debug problems when requested
mapping crossed end of the static one.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 5a05a820 ("davinci_emac:
use an unique MDIO bus name") introduced during the v3.3 merge
window updated the davinci mdio bus name to make it unique.

Update the bus name in board files which use DaVinci MDIO bus
to match the new name. Without this PHY is not detected with
error like:

PHY 0:01 not found
net eth0: could not connect to phy 0:01

Tested on DM365 and DA850 EVMs.

Cc: Florian Fainelli <florian@openwrt.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
    when != iounmap(e)
*if (...)
   { ... when != iounmap(e)
     return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NTony Lindgren <tony@atomide.com>

pdata needs to be freed before leaving the function in an error case.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NTony Lindgren <tony@atomide.com>