This is a helper to be used by the DMA mapping API to handle cache
maintenance for memory identified by a page structure instead of a
virtual address.  Those pages may or may not be highmem pages, and
when they're highmem pages, they may or may not be virtually mapped.
When they're not mapped then there is no L1 cache to worry about. But
even in that case the L2 cache must be processed since unmapped highmem
pages can still be L2 cached.
Signed-off-by: NNicolas Pitre <nico@marvell.com>

The kmap virtual area borrows a 2MB range at the top of the 16MB area
below PAGE_OFFSET currently reserved for kernel modules and/or the
XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
second-level page tables, or a single pmd entry as seen by the Linux
page table abstraction.  Because XIP kernels are unlikely to be seen
on systems needing highmem support, there shouldn't be any shortage of
VM space for modules (14 MB for modules is still way more than twice the
typical usage).

Because the virtual mapping of highmem pages can go away at any moment
after kunmap() is called on them, we need to bypass the delayed cache
flushing provided by flush_dcache_page() in that case.

The atomic kmap versions are based on fixmaps, and
__cpuc_flush_dcache_page() is used directly in that case.
Signed-off-by: NNicolas Pitre <nico@marvell.com>

This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.

We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000.  Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.

However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.

So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.

The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: NNicolas Pitre <nico@marvell.com>

Add swab.h to kbuild.asm and remove the individual entries from
each arch, mark as unifdef as some arches have some kernel-only
bits inside.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make VMAs per mm_struct as for MMU-mode linux.  This solves two problems:

 (1) In SYSV SHM where nattch for a segment does not reflect the number of
     shmat's (and forks) done.

 (2) In mmap() where the VMA's vm_mm is set to point to the parent mm by an
     exec'ing process when VM_EXECUTABLE is specified, regardless of the fact
     that a VMA might be shared and already have its vm_mm assigned to another
     process or a dead process.

A new struct (vm_region) is introduced to track a mapped region and to remember
the circumstances under which it may be shared and the vm_list_struct structure
is discarded as it's no longer required.

This patch makes the following additional changes:

 (1) Regions are now allocated with alloc_pages() rather than kmalloc() and
     with no recourse to __GFP_COMP, so the pages are not composite.  Instead,
     each page has a reference on it held by the region.  Anything else that is
     interested in such a page will have to get a reference on it to retain it.
     When the pages are released due to unmapping, each page is passed to
     put_page() and will be freed when the page usage count reaches zero.

 (2) Excess pages are trimmed after an allocation as the allocation must be
     made as a power-of-2 quantity of pages.

 (3) VMAs are added to the parent MM's R/B tree and mmap lists.  As an MM may
     end up with overlapping VMAs within the tree, the VMA struct address is
     appended to the sort key.

 (4) Non-anonymous VMAs are now added to the backing inode's prio list.

 (5) Holes may be punched in anonymous VMAs with munmap(), releasing parts of
     the backing region.  The VMA and region structs will be split if
     necessary.

 (6) sys_shmdt() only releases one attachment to a SYSV IPC shared memory
     segment instead of all the attachments at that addresss.  Multiple
     shmat()'s return the same address under NOMMU-mode instead of different
     virtual addresses as under MMU-mode.

 (7) Core dumping for ELF-FDPIC requires fewer exceptions for NOMMU-mode.

 (8) /proc/maps is now the global list of mapped regions, and may list bits
     that aren't actually mapped anywhere.

 (9) /proc/meminfo gains a line (tagged "MmapCopy") that indicates the amount
     of RAM currently allocated by mmap to hold mappable regions that can't be
     mapped directly.  These are copies of the backing device or file if not
     anonymous.

These changes make NOMMU mode more similar to MMU mode.  The downside is that
NOMMU mode requires some extra memory to track things over NOMMU without this
patch (VMAs are no longer shared, and there are now region structs).
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NMike Frysinger <vapier.adi@gmail.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>

Use the generic pci_common_swizzle() instead of arch-specific code.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The atomic_t type cannot currently be used in some header files because it
would create an include loop with asm/atomic.h.  Move the type definition
to linux/types.h to break the loop.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The original arch/arm/include/asm/hardware/vic.h was
written for the PL190 ARM VIC implementation, and as
such does not have any information about the PL192
version.

Add details about the PL192 and PL190 specific registers
and any changes between the two units.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dma_supported() is supposed to indicate whether the system can support
the DMA mask it was passed, which depends on the maximal address which
can be returned for DMA allocations.  If the mask is smaller than that,
we are unable to guarantee that the driver can reliably obtain suitable
memory.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 8ec53663 ("[ARM] Improve
non-executable support") added support for detecting non-executable
stack binaries.  One of the things it does is to make READ_IMPLIES_EXEC
be set in ->personality if we are running on a CPU that doesn't support
the XN ("Execute Never") page table bit or if we are running a binary
that needs an executable stack.

This exposed a latent bug in ARM's asm/processor.h due to which we'll
end up placing the stack at a very low address, where it will bump into
the heap on any application that uses significant amount of stack or
heap or both, causing many interesting crashes.

Fix this by testing the ADDR_LIMIT_32BIT bit in ->personality instead
of testing for equality against PER_LINUX_32BIT.
Reviewed-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 0c65f459 intended to fix truncation issues with fls() on
ARMv5+ by renaming it to __fls() and wrapping it into a C function.
However that didn't take into account the fact that __fls() already
already had different semantics in the kernel.

Let's move the __fls() code into fls() function directly, and redefine
__fls() with the appropriate semantics.  While at it, bring a generic
__fls() definition for pre ARMv5 too.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

All the cases where the local timer for a CPU is accessed happen on the
corresponding current CPU, hence no need to access the per-CPU local
timer mappings.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

As Al did for Versatile in 2ad4f86b,
add a typesafe __io implementation for platforms to use.  Convert
platforms to use this new simple typesafe implementation.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

RiscPC is the only platform using the default setting for NR_IRQS,
so the default NR_IRQS doesn't really make sense; remove it and
make RiscPC provide such a definition.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... and fix those drivers that were incorrectly relying upon
that include.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This avoids confusion with platform specific DMA implementations in
mach/dma.h
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When ISA_DMA_API is unset, we're not implementing the ISA DMA API,
so there's no point in publishing the prototypes via asm/dma.h, nor
including the machine dependent parts of that API.

This allows us to remove a lot of mach/dma.h files which don't contain
any useful code.  Unfortunately though, some platforms put their own
private non-ISA definitions into mach/dma.h, so we leave these behind
and fix the appropriate #include statments.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move the definition of MAX_DMA_ADDRESS from mach/dma.h to mach/memory.h,
thereby placing it along side its relative, ISA_DMA_THRESHOLD.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Let's provide an overridable default instead of having every machine
class define __virt_to_bus and __bus_to_virt to the same thing.  What
most platforms are using is bus_addr == phys_addr so such is the default.

One exception is ebsa110 which has no DMA what so ever, so the actual
definition is not important except only for proper compilation.  Also
added a comment about the special footbridge bus translation.

Let's also remove comments alluding to set_dma_addr which is not
(and should not) be commonly used.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There is no machine class overriding this.  If non linear translations
are implemented again for some machines then this could be restored at
that time.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently there are two instances of struct meminfo: one in
kernel/setup.c marked __initdata, and another in mm/init.c with
permanent storage.  Let's keep only the later to directly populate
the permanent version from arm_add_memory().

Also move common validation tests between the MMU and non-MMU cases
into arm_add_memory() to remove some duplication.  Protection against
overflowing the membank array is also moved in there in order to cover
the kernel cmdline parsing path as well.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

For similar reasons as copy_user_page(), we want to avoid the
additional kmap_atomic if it's unnecessary.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We used to override the copy_user_page() function.  However, this
is not only inefficient, it also causes additional complexity for
highmem support, since we convert from a struct page to a kernel
direct mapped address and back to a struct page again.

Moreover, with highmem support, we end up pointlessly setting up
kmap entries for pages which we're going to remap.  So, push the
kmapping down into the copypage implementation files where it's
required.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add some generic infrastructure to assist looking up struct clks
for the ARM architecture.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The CLPS7500 platform has not built since 2.6.22-git7 and there
seems to be no interest in fixing it.  So, remove the platform
support.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As suggested by Andrew Morton, remove memzero() - it's not supported
on other architectures so use of it is a potential build breaking bug.
Since the compiler optimizes memset(x,0,n) to __memzero() perfectly
well, we don't miss out on the underlying benefits of memzero().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/arm/mm/dma-mapping.c: In function `dma_sync_sg_for_cpu':
arch/arm/mm/dma-mapping.c:588: warning: statement with no effect
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that the critical read back to flush the next descriptor address is
fixed we can downgrade some BUG_ONs that need only be enabled when testing
changes to the driver.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Mikael Pettersson reported:

   The 2.6.28-rc kernels fail to detect PCI device 0000:00:01.0
   (the first ethernet port) on my Thecus n2100 XScale box.

   There is however still a strange "ghost" device that gets partially
   detected in 2.6.28-rc2 vanilla.

The IOP321 manual says:

  The user designates the memory region containing the OCCDR as
  non-cacheable and non-bufferable from the IntelR XScaleTM core.
  This guarantees that all load/stores to the OCCDR are only of
  DWORD quantities.

Ensure that the OCCDR is so mapped.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like.  While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.

Tested on:
	OMAP34xx (ARMv7),
	OMAP24xx (ARMv6),
	OMAP16xx (ARM926T, ARMv5),
	PXA311 (Xscale3),
	PXA272 (Xscale),
	PXA255 (Xscale),
	IXP42x (Xscale),
	S3C2410 (ARM920T, ARMv4T),
	ARM720T (ARMv4T)
	StrongARM-110 (ARMv4)
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Tested-by: NMike Rapoport <mike@compulab.co.il>
Tested-by: NBen Dooks <ben-linux@fluff.org>
Tested-by: NAnders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As of 73bdf0a6, the kernel needs
to know where modules are located in the virtual address space.
On ARM, we located this region between MODULE_START and MODULE_END.
Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
Update ARM to use the same naming, so is_vmalloc_or_module_addr()
can work properly.  Also update the comment on mm/vmalloc.c to
reflect that ARM also places modules in a separate region from the
vmalloc space.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

In case of non-aliasing VIPT caches, there is no need to flush the whole
cache when new mapping is created. The patch introduces this condition
check. In the non-aliasing VIPT case flush_cache_vmap() needs a DSB
since the set_pte_at() function called from vmap_pte_range() does not
have such barrier (done usually via TLB flushing functions).
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Impact: build fix for non-ftrace architectures

Not all archs implement ftrace, and therefore do not have an asm/ftrace.h.
This patch corrects the problem.

The ftrace_nmi_enter/exit now must be defined for all archs that implement
dynamic ftrace. Currently, only x86 does.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: cleanup

This patch cleans up the NMI safe code for dynamic ftrace as suggested
by Andrew Morton.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fix crashes that can occur in NMI handlers, if their code is modified

Modifying code is something that needs special care. On SMP boxes,
if code that is being modified is also being executed on another CPU,
that CPU will have undefined results.

The dynamic ftrace uses kstop_machine to make the system act like a
uniprocessor system. But this does not address NMIs, that can still
run on other CPUs.

One approach to handle this is to make all code that are used by NMIs
not be traced. But NMIs can call notifiers that spread throughout the
kernel and this will be very hard to maintain, and the chance of missing
a function is very high.

The approach that this patch takes is to have the NMIs modify the code
if the modification is taking place. The way this works is that just
writing to code executing on another CPU is not harmful if what is
written is the same as what exists.

Two buffers are used: an IP buffer and a "code" buffer.

The steps that the patcher takes are:

 1) Put in the instruction pointer into the IP buffer
    and the new code into the "code" buffer.
 2) Set a flag that says we are modifying code
 3) Wait for any running NMIs to finish.
 4) Write the code
 5) clear the flag.
 6) Wait for any running NMIs to finish.

If an NMI is executed, it will also write the pending code.
Multiple writes are OK, because what is being written is the same.
Then the patcher must wait for all running NMIs to finish before
going to the next line that must be patched.

This is basically the RCU approach to code modification.

Thanks to Ingo Molnar for suggesting the idea, and to Arjan van de Ven
for his guidence on what is safe and what is not.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Those inline assembly segments using the umlal instruction must have
the & modifier so to be sure that a purely input register won't alias
one of the registers used as input+output.  In most cases, the inputs
are still used after the outputs are touched, and most binutil versions
insist on "rdhi, rdlo and rm must all be different" even for ARMv6+.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>