The BAST support code is calling s3c_i2c0_set_platdata() from
the map_io() entry, instead of the bast_init() code. This causes
the registration to fail due to kmalloc() not being available
at the time.

This fixes the following error:
s3c_i2c0_set_platdata: no memory for platform data
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fix unused code warning in arch/arm/plat-s3c24xx/dma.c if there
is no PM support enabled. The function to_dma_chan() should
be marked inline so that the compiler will eliminate it without
warning if it isn't used.

arch/arm/plat-s3c24xx/dma.c:1239: warning: 'to_dma_chan' defined but not used
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fix compilation bug when debug was enabled
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Cleanup arm/plat-s3c64xx/include/plat/gpio-bank-h.h include file.
Using shift-left operation with value >32 is a bad habit.
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

The symbol 'floatx80_is_nan' prototype was defined
locally in fpa11_cprt.c when it was built outside the
file in softfloat-specialisze.

Move this into softfloat.h to fix the following sparse
warning:

softfloat-specialize:276:6: warning: symbol 'floatx80_is_nan' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Add header file decleration for 'ExtendedCPDO' in fpa11.h
to stop the following sparse warning:

extended_cpdo.c:90:14: warning: symbol 'ExtendedCPDO' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Lockdep reports the warning below when Li tries to offline one cpu:

[  110.835487] =================================
[  110.835616] [ INFO: inconsistent lock state ]
[  110.835688] 2.6.30-rc4-00336-g8c9ed899 #52
[  110.835757] ---------------------------------
[  110.835828] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[  110.835908] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  110.835982]  (cmci_discover_lock){?.+...}, at: [<ffffffff80236dc0>] cmci_clear+0x30/0x9b

cmci_clear() can be called via smp_call_function_single().

It is better to disable interrupt while holding cmci_discover_lock,
to turn it into an irq-safe lock - we can deadlock otherwise.

[ Impact: fix possible deadlock in the MCE code ]
Reported-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4A03ED38.8000700@jp.fujitsu.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Reported-by: Shaohua Li<shaohua.li@intel.com>

The Xen pagetables are no longer implicitly reserved as part of the other
i386_start_kernel reservations, so make sure we explicitly reserve them.
This prevents them from being released into the general kernel free page
pool and reused.

[ Impact: fix Xen guest crash ]
Also-Bisected-by: NBryan Donlan <bdonlan@gmail.com>
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <4A032EEC.30509@goop.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Tim Starling reported that crashdump will panic with kernel compiled
with CONFIG_KEXEC_JUMP due to null pointer deference in
machine_kexec_32.c: machine_kexec(), when deferencing
kexec_image. Refering to:

http://bugzilla.kernel.org/show_bug.cgi?id=13265

This patch fixes the BUG via replacing global variable reference:
kexec_image in machine_kexec() with local variable reference: image,
which is more appropriate, and will not be null.

Same BUG is in machine_kexec_64.c too, so fixed too in the same way.

[ Impact: fix crash on kexec ]
Reported-by: NTim Starling <tstarling@wikimedia.org>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
LKML-Reference: <1241751101.6259.85.camel@yhuang-dev.sh.intel.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

With the introduction of the .brk section, special care must be taken
that no unused page table entries remain if _brk_end and _end are
separated by a 2M page boundary. cleanup_highmap() runs very early and
hence cannot take care of that, hence potential entries needing to be
removed past _brk_end must be cleared once the brk allocator has done
its job.

[ Impact: avoids undesirable TLB aliases ]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

If the first non-reserved (sub-)range doesn't fit the size requested,
an endless loop will be entered. If a range returned from
find_e820_area_size() turns out insufficient in size, the range must
be skipped before calling the function again.

[ Impact: fixes boot hang on some platforms ]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.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>

As per commit 284901a9, use
DMA_BIT_MASK(n)
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

[ Impact: printk message cleanup ]
Signed-off-by: NNikanth Karthikesan <knikanth@suse.de>
LKML-Reference: <200905040908.27299.knikanth@suse.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The mem= option will truncate the memory map at a specified address so
it's not possible to register nodes with memory beyond the e820 upper
bound.

unparse_node() is only called when then node had memory associated with
it, although with the mem= option it is no longer addressable.

[ Impact: fix boot hang on certain (large) systems ]
Reported-by: N"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Acked-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <alpine.DEB.2.00.0905051248150.20021@chino.kir.corp.google.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

- drivers/xen/events.c did not compile
- xen_setup_hook caused a modpost section warning
- the use of u64 (instead of unsigned long long) together with a %llu
  in drivers/xen/balloon.c caused a compiler warning
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The i.MX31 ARM11 core is not a v6K core. Disable this option as it
is incompatible with non v6K cores.
Signed-off-by: NMagnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Before this patch I got the following line in my dmesg:

	[    0.000000] BUG: mapping for 0xd4000000 at 0xeb000000 overlaps vmalloc space

VMALLOC_END is 0xf4000000 and there are the following other mappings
defined for mx27ads:

	(0xa0500000,+0x00001000) maps to 0xffff0000
	(0x10000000,+0x00100000) maps to 0xf4000000
	(0x80000000,+0x00100000) maps to 0xf4100000
	(0xd8000000,+0x00100000) maps to 0xf4200000

So map PBC to 0xf4300000.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

On i.MX31 I sometimes get spurious interrupts. There is no need
to crash the whole system when this happens. Instead, silently
ignore it.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

We want to have a mx31_defconfig file that builds a kernel that is able
to boot on all support mx31 systems and thus also can be better tested
by automatic build scripts. For these reasons, this config file is not
needed anymore.
Signed-off-by: NValentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

All i.MX platforms support <linux/clk.h> calls and should select HAVE_CLK.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

On MX2 platforms imx_dma_request() calls request_irq() which may sleep
with interrupts disabled.
Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The sequence
	imx_dma_request()
	imx_dma_enable()
	imx_dma_free()
left the dma channel in_use mode and did not release the timer.
Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: NNicolas Pitre <nico@marvell.com>

Signed-off-by: NNicolas Pitre <nico@marvell.com>

Signed-off-by: NNicolas Pitre <nico@marvell.com>

Commit 7ad728f9
(cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
changed the output of /proc/cpuinfo for siblings:

Example on an AMD Phenom:

  physical id   : 0
  siblings : 1
  core id	   : 3
  cpu cores  : 4

Before that commit it was:

  physical id	: 0
  siblings : 4
  core id	   : 3
  cpu cores  : 4

Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
This is due to the following hunk of above commit:

|  --- a/arch/x86/kernel/cpu/proc.c
|  +++ b/arch/x86/kernel/cpu/proc.c
|  @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
|          if (c->x86_max_cores * smp_num_siblings > 1) {
|                  seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
|                  seq_printf(m, "siblings\t: %d\n",
|  -                          cpus_weight(per_cpu(cpu_core_map, cpu)));
|  +                          cpumask_weight(cpu_sibling_mask(cpu)));
|                  seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
|                  seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
|                  seq_printf(m, "apicid\t\t: %d\n", c->apicid);

This was a mistake, because the impact line shows that this side-effect
was not anticipated:

   Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y

So revert the respective hunk to restore the old behavior.

[ Impact: fix sibling-info regression in /proc/cpuinfo ]
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The feature bits should be set via bitmasks, not via feature IDs.

[ Impact: fix feature enabling in newer IOMMU versions ]
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
LKML-Reference: <20090504102028.GA30307@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The powerpc kernel always requires an Open Firmware like device tree
to supply device information.  On systems without OF, this comes from
a flattened device tree blob.  This blob is usually generated by dtc,
a tool which compiles a text description of the device tree into the
flattened format used by the kernel.  Sometimes, the bootwrapper makes
small changes to the pre-compiled device tree blob (e.g. filling in
the size of RAM).  To do this it uses the libfdt library.

Because these are only used on powerpc, the code for both these tools
is included under arch/powerpc/boot (these were imported and are
periodically updated from the upstream dtc tree).

However, the microblaze architecture, currently being prepared for
merging to mainline also uses dtc to produce device tree blobs.  A few
other archs have also mentioned some interest in using dtc.
Therefore, this patch moves dtc and libfdt from arch/powerpc into
scripts, where it can be used by any architecture.

The vast bulk of this patch is a literal move, the rest is adjusting
the various Makefiles to use dtc and libfdt correctly from their new
locations.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some drivers using of_register_platform_driver() wrapper break on sparc
because the wrapper isn't in the header file.  This patch moves it from
Microblaze and PowerPC implementations and makes it common code.

Fixes this sparc64 allmodconfig build error (at least):

drivers/leds/leds-gpio.c: In function `gpio_led_init':
drivers/leds/leds-gpio.c:295: error: implicit declaration of function `of_register_platform_driver'
drivers/leds/leds-gpio.c: In function `gpio_led_exit':
drivers/leds/leds-gpio.c:311: error: implicit declaration of function `of_unregister_platform_driver'
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This fixes the problem introduced by commit 3bfacef4 (get rid of
special-casing the /sbin/loader on alpha): osf/1 ecoff binary segfaults
when binfmt_aout built as module.  That happens because aout binary
handler gets on the top of the binfmt list due to late registration, and
kernel attempts to execute the binary without preparatory work that must
be done by binfmt_loader.

Fixed by changing the registration order of the default binfmt handlers
using list_add_tail() and introducing insert_binfmt() function which
places new handler on the top of the binfmt list.  This might be generally
useful for installing arch-specific frontends for default handlers or just
for overriding them.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Exception fixups for sections other than .text (like one in futex_init())
break the natural ordering of fixup entries, so sorting is required.

Without that the result of the exception table search depends on phase of
the moon.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These platforms got broken after u64 => 'long long' conversion.

Apparently that change was compile-tested with 'make allmodconfig', but it
doesn't include systems that depend on !ALPHA_LEGACY_START_ADDRESS.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Replace #x with __stringify(x).
Also, #ifndef __STR is removed and undefine __STR macro at the beginning.

The __STR() macro is still remained, because the assembler.h might be
included from assembly codes as well as C codes.
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

This patch fixes the following build error of 2.6.30-rc3-git2:

      AS      arch/m32r/kernel/head.o
    In file included from /include/linux/init.h:7,
                     from /arch/m32r/kernel/head.S:11:
    /include/linux/stringify.h:9: error: syntax error in macro parameter list
    /include/linux/stringify.h:10: error: syntax error in macro parameter list

This build error was caused at __HEAD macro in arch/m32r/kernel/head.S,
which uses __stringify() macro.

Remove -traditional option from EXTRA_AFLAGS for the m32r,
because the __stringify() macro depends on the gcc's variadic macro
extension function, due to commit:

    Make __stringify support variable argument macros too
    commit: 8f7c2c37Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

commit db949bba (x86-32: use non-lazy
io bitmap context switching) broke ioperm for 32bit because it removed
the lazy initialization of io_bitmap_base and did not set it to the
real bitmap offset.

[ Impact: fix non-working sys_ioperm() on 32-bit kernels ]
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NJohn Linn <john.linn@xilinx.com>
Signed-off-by: NMichal Simek <monstr@monstr.eu>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NMichal Simek <monstr@monstr.eu>