Every architecture using the GIC has a gic_cpu_base_addr pointer for
GIC 0 for their entry assembly code to use to decode the cause of the
current interrupt.  Move this into the common GIC code.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Tested-by: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We don't need to re-pass the base address for the CPU interfaces to the
GIC for secondary CPUs, as it will never be different from the boot CPU
- and even if it was, we'd overwrite the boot CPU's base address.

Get rid of this argument, and rename to gic_secondary_init().
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Tested-by: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Provide gic_init() which initializes the GIC distributor and current
CPU's GIC interface for the boot (or single) CPU.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Tested-by: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Common GIC entry macro for omap
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the GIC demux code in asm/hardware/entry-macro-gic.S
on the Versatile Express subarchitecture.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the GIC demux code in asm/hardware/entry-macro-gic.S
on the UX500 subarchitecture.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the GIC demux code in asm/hardware/entry-macro-gic.S
on the Tegra subarchitecture.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the GIC demux code in asm/hardware/entry-macro-gic.S
on the Realview subarchitecture.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the GIC demux code in asm/hardware/entry-macro-gic.S
on the CNS3XXX subarchitecture.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch is the identical GIC demux implementation
merge V3. Instead of implementing same code over and
over simply share it in entry-macro-gic.S. The shared
code is based on the realview implementation.

Each GIC demux instance still has to setup the base address
of the controller using the get_irqnr_preamble macro. The
rest of the GIC specific code can be shared.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 0ea12930 ("arm: return both physical and virtual addresses
from addruart") took out the test for MMU on/off but didn't switch the
ldr instructions to no longer be conditionals based on said test.

Fix that.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NColin Cross <ccross@android.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gic_set_cpu will directly use irq_desc[]. If CONFIG_SPARSE_IRQ is
enabled, there is no irq_desc[]. So we need use irq_to_desc(irq) to
get the descriptor for irq.
Signed-off-by: NChao Xie <chao.xie@marvell.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The generic conversion eliminates the spurious no_ack and no_end
routines, converts all the cascaded handlers to handle_simple_irq() and
makes iosapic use a modified handle_percpu_irq() to become the same as
the CPU irq's.  This isn't an essential change, but it eliminates the
mask/unmask overhead of handle_level_irq().
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
Tested-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

The essential problem we're currently having is that dino (and gsc) is a
cascaded CPU interrupt.  Under the old __do_IRQ() handler, our CPU
interrupts basically did an ack followed by an end.  In the new scheme,
we replaced them with level handlers which do a mask, an ack and then an
unmask (but no end).  Instead, with the renaming of end to eoi, we
actually want to call the percpu flow handlers, because they actually
have all the characteristics we want.

This patch does the conversion and gets my C360 booting again.
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Include sched.h to ensure sched_clock() has the notrace
annotation, and mark any functions it calls as notrace
too.
Include sched.h to ensure sched_clock() has the notrace
annotation, and mark any functions it calls as notrace
too.
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The existing code invokes the syscall with rubbish in r7,
due to what looks like an incorrect literal load idiom.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Implement asm/syscall.h for the MN10300 arch.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

se7724 board does not have FSI/B.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

On stock 2.6.37-rc4, running:

  # mount lilith:/export /mnt/lilith
  # find  /mnt/lilith/ -type f -print0 | xargs -0 file

crashes the machine fairly quickly under Xen.  Often it results in oops
messages, but the couple of times I tried just now, it just hung quietly
and made Xen print some rude messages:

    (XEN) mm.c:2389:d80 Bad type (saw 7400000000000001 != exp
    3000000000000000) for mfn 1d7058 (pfn 18fa7)
    (XEN) mm.c:964:d80 Attempt to create linear p.t. with write perms
    (XEN) mm.c:2389:d80 Bad type (saw 7400000000000010 != exp
    1000000000000000) for mfn 1d2e04 (pfn 1d1fb)
    (XEN) mm.c:2965:d80 Error while pinning mfn 1d2e04

Which means the domain tried to map a pagetable page RW, which would
allow it to map arbitrary memory, so Xen stopped it.  This is because
vm_unmap_ram() left some pages mapped in the vmalloc area after NFS had
finished with them, and those pages got recycled as pagetable pages
while still having these RW aliases.

Removing those mappings immediately removes the Xen-visible aliases, and
so it has no problem with those pages being reused as pagetable pages.
Deferring the TLB flush doesn't upset Xen because it can flush the TLB
itself as needed to maintain its invariants.

When unmapping a region in the vmalloc space, clear the ptes
immediately.  There's no point in deferring this because there's no
amortization benefit.

The TLBs are left dirty, and they are flushed lazily to amortize the
cost of the IPIs.

This specific motivation for this patch is an oops-causing regression
since 2.6.36 when using NFS under Xen, triggered by the NFS client's use
of vm_map_ram() introduced in 56e4ebf8 ("NFS: readdir with vmapped
pages") .  XFS also uses vm_map_ram() and could cause similar problems.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Bryan Schumaker <bjschuma@netapp.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Alex Elder <aelder@sgi.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Early after being resumed we need to unplug again the emulated devices.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

When remapping MSIs into pirqs for PV on HVM guests, qemu is responsible
for doing the actual mapping and unmapping.
We only give qemu the desired pirq number when we ask to do the mapping
the first time, after that we should be reading back the pirq number
from qemu every time we want to re-enable the MSI.

This fixes a bug in xen_hvm_setup_msi_irqs that manifests itself when
trying to enable the same MSI for the second time: the old MSI to pirq
mapping is still valid at this point but xen_hvm_setup_msi_irqs would
try to assign a new pirq anyway.
A simple way to reproduce this bug is to assign an MSI capable network
card to a PV on HVM guest, if the user brings down the corresponding
ethernet interface and up again, Linux would fail to enable MSIs on the
device.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

This follows the ARM change c0177800
("ARM: 6379/1: Assume new page cache pages have dirty D-cache") for the
same rationale:

    There are places in Linux where writes to newly allocated page
    cache pages happen without a subsequent call to flush_dcache_page()
    (several PIO drivers including USB HCD). This patch changes the
    meaning of PG_arch_1 to be PG_dcache_clean and always flush the
    D-cache for a newly mapped page in update_mmu_cache().

This addresses issues seen with executing binaries from MMC, in
addition to some of the other HCDs that don't explicitly do cache
management for their pipe-in buffers.
Requested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

for the epson frambuffer support it's CONFIG_FB_S1D13XXX
not CONFIG_FB_S1D135XX
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

as based on http://www.picotux.com/pt200/picotux200.pdf
these board does not have such I/O
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

to be a few more concistant with the other boards

as ek is for evaluation kit and dk for development kit
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Convert the following AT91RM9200-based boards to the new-style UART
initialization:
  - Ajeco 1ARM Single Board Computer
  - Sperry-Sun KAFA board
  - picotux 200

Remove the deprecated at91_init_serial
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Currently, the kprobes implementation for ARM only supports the ARM
instruction set, so it only works if CONFIG_THUMB2_KERNEL is not
enabled.

Until kprobes is updated to work with Thumb-2, turning it on will
cause horrible things to happen, so this patch disables it for now.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a
result, using these directives in code sections can result in
misaligned data words when building a Thumb-2 kernel
(CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to
assume that fundamental types of word size or above are word-
aligned when accessing them from C.  If the data is not really
word-aligned, this can cause impaired performance and stray
alignment faults in some circumstances.

In general, the following rules should be applied when using
data word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned data
words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume that
fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned, this
can cause impaired performance and stray alignment faults in some
circumstances.

In general, the following rules should be applied when using data word
declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The 32-bit conditional branches in Thumb-2 have a shorter range
(+/-512K) than their ARM counterparts (+/-32MB).  The linker does
not currently generate trampolines to extend the range of these
Thumb-2 conditional branches, resulting in link errors when vmlinux
is sufficiently large, e.g.:

head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19

This patch forces the longer-range, unconditional branch encoding
by use of an explicit IT instruction.  The resulting branches are
triggered on the same conditions as before.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The code which makes up the zImage header intends to leave a
32-byte gap followed by a branch to the real entry point, a magic
number, and a word containing the absolute entry point address.

This gets messed up with with CONFIG_THUMB2_KERNEL, because the
size of the initial padding NOPs changes.

Instead, the header can be made fully compatible by restoring it to
ARM.

In the Thumb-2 case, we can replace the initial NOPs with a
sequence which switches to Thumb and jumps to the real entry point.

As a consequence, the zImage entry point is now always ARM, so no
special magic is needed any more for the uImage rules in the
Thumb-2 case.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some instruction operand combinations are used here which are nor
permitted in Thumb-2.

In particular, most uses of pc as an operand are disallowed in
Thumb-2, and deprecated in ARM from ARMv7 onwards.

The modified code introduced by this patch should be compatible
with all architecture versions >= v3, with or without
CONFIG_THUMB2_KERNEL.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

In this specific case, we can achieve the desired alignment by
forcing a 32-bit branch instruction using the W() macro, since the
assembler location counter is already 32-bit aligned in this case.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>