iop32x_defconfig:

In file included from include/linux/elf.h:7,
                 from kernel/elfcore.c:1:
arch/arm/include/asm/elf.h:101: warning: "struct task_struct" declared inside parameter list
arch/arm/include/asm/elf.h:101: warning: its scope is only this definition or declaration, which is probably not what you want
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

2.6.34-rc1 added kernel/elfcore.c which includes <asm/elf.h>.
On ARM, this results in:

In file included from include/linux/elf.h:7,
                 from kernel/elfcore.c:1:
/tmp/linux-2.6.34-rc1/arch/arm/include/asm/elf.h:101: warning: 'struct task_struct' declared inside parameter list
/tmp/linux-2.6.34-rc1/arch/arm/include/asm/elf.h:101: warning: its scope is only this definition or declaration, which is probably not what you want

Including <linux/sched.h> seems a bit heavyweight, so this patch just
adds a tentative declaration of struct task_struct in <asm/elf.h>.
Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently all architectures but microblaze unconditionally define
USE_ELF_CORE_DUMP.  The microblaze omission seems like an error to me, so
let's kill this ifdef and make sure we are the same everywhere.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: <linux-arch@vger.kernel.org>
Cc: Michal Simek <michal.simek@petalogix.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Defines ELF_CORE_COPY_TASK_REGS so that CPU register information
of every thread is included in coredump. Without this, only the faulting
thread is coredumped.

Cc: Roger Quadros <ext-roger.quadros@nokia.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Modules compiled to Thumb-2 have two additional relocations needing to
be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
(+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
(MODULES_END - 8MB) for the Thumb-2 compiled kernel.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

From: Bruce Ashfield <bruce.ashfield@windriver.com>

To fully support the armv7-a instruction set/optimizations, support
for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is
required.

The MOVW and MOVT are both load-immediate instructions, MOVW loads 16
bits into the bottom half of a register, and MOVT loads 16 bits into the
top half of a register.

The relocation information for these instructions has a full 32 bit
value, plus an addend which is stored in the 16 immediate bits in the
instruction itself.  The immediate bits in the instruction are not
contiguous (the register # splits it into a 4 bit and 12 bit value),
so the addend has to be extracted accordingly and added to the value.
The value is then split and put into the instruction; a MOVW uses the
bottom 16 bits of the value, and a MOVT uses the top 16 bits.
Signed-off-by: NDavid Borman <david.borman@windriver.com>
Signed-off-by: NBruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It would seem when building kernel modules with modern binutils
(required by modern GCC) for ARM v4T targets (specifically observed
with the Samsung 24xx SoC which is an 920T) R_ARM_V4BX relocations
are emitted for function epilogues.

This manifests at module load time with an "unknown relocation: 40"
error message.

The following patch adds the R_ARM_V4BX relocation to the ARM kernel
module loader. The relocation operation is taken from that within the
binutils bfd library.
Signed-off-by: NSimtec Linux Team <linux@simtec.co.uk>
Signed-off-by: NVincent Sanders <vince@simtec.co.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds ELF section parsing for the unwinding tables in loadable
modules together with the PREL31 relocation symbol resolving.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The SET_PERSONALITY macro is always called with a second argument of 0.
Remove the ibcs argument and the various tests to set the PER_SVR4
personality.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Add support for detecting non-executable stack binaries, and adjust
permissions to prevent execution from data and stack areas.  Also,
ensure that READ_IMPLIES_EXEC is enabled for older CPUs where that
is true, and for any executable-stack binary.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

asm code really wants asm/hwcap.h, so include that instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move platform independent header files to arch/arm/include/asm, leaving
those in asm/arch* and asm/plat* alone.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

asm/elf.h, asm/page.h and asm/user.h don't export to userspace now, so we can
drop #ifdef __KERNEL__ for them.

[k.shutemov@gmail.com: remove #ifdef __KERNEL_]
Signed-off-by: NKirill A. Shutemov <k.shutemov@gmail.com>
Reviewed-by: NDavid Woodhouse <dwmw2@infradead.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NKirill A. Shutemov <k.shutemov@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While bisecting an iop13xx compile failure I noticed that
include/asm-arm/hwcap.h should be included from include/asm-arm/elf.h
outside #ifndef __ASSEMBLY__ since hwcap.h has its own __ASSEMBLY__
protections.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The patch moves the HWCAP definitions and the extern elf_hwcap
declaration to the hwcap.h header file.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add HWCAP_CRUNCH so that the dynamic linker knows whether it can
use Crunch-optimised libraries or not.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

XScale cores either have a DSP coprocessor (which contains a single
40 bit accumulator register), or an iWMMXt coprocessor (which contains
eight 64 bit registers.)

Because of the small amount of state in the DSP coprocessor, access to
the DSP coprocessor (CP0) is always enabled, and DSP context switching
is done unconditionally on every task switch.  Access to the iWMMXt
coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
first issued, and iWMMXt context switching is done lazily.

CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
have iWMMXt support', but boards are supposed to select this config
symbol by hand, and at least one pxa27x board doesn't get this right,
so on that board, proc-xscale.S will incorrectly assume that we have a
DSP coprocessor, enable CP0 on boot, and we will then only save the
first iWMMXt register (wR0) on context switches, which is Bad.

This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
might have iWMMXt support, and we will enable iWMMXt context switching
if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
state over context switches, and running a CONFIG_IWMMXT=y kernel on a
non-iWMMXt capable CPU will still do DSP context save/restore.

These changes should make iWMMXt work on PXA3xx, and as a side effect,
enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
as well as setting and using HWCAP_IWMMXT properly.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move HWCAP_* definitions into asm/elf.h, where they should belong.
Since userspace wants to get at these definitions by including
asm/procinfo.h, include asm/elf.h from this file if __KERNEL__
is not defined, and issue a warning suggesting to fix the program
up to use asm/elf.h instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Prepare elf.h so that assembly code can include this file.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Sanitise the ARM headers exported to userspace.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Move kernel-only #includes into #ifdef __KERNEL__, so that
headers_install target can be used on ARM.
Signed-off-by: NRalph Siemsen <ralphs@netwinder.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Patch from Daniel Jacobowitz

Handle new EABI relocations when loading kernel modules.  This is
necessary for CONFIG_AEABI kernels, and also for some broken
(since fixed) old ABI toolchains.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Daniel Jacobowitz

Thread flags are inherited on fork().  In order for a binary which has
the iWMMXt coprocessor enabled to run a binary which needs the FPA
emulation, we need to explicitly clear TIF_USING_IWMMXT if we are not
going to set it.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Mike Frysinger

the ELF_DATA define in both arm asm subdirs of linux/include/ contain a
semicolon at the end.  this of course will cause any code that tries to use
ELF_DATA in assignment or comparison to fail.  no other arch has a semicolon
in their ELF_DATA defines.

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

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!