do_IRQ: cannot handle IRQ -1 vector 0x20 cpu 0
	------------[ cut here ]------------
	kernel BUG at arch/x86/kernel/irq_32.c:219!

We're not ISA: we have a 1:1 mapping from vectors to irqs.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

dmi_scan_machine breaks under lguest:
	lguest: unhandled trap 14 at 0xc04edeae (0xffa00000)

This is because we use current_cr3 for the read_cr3() paravirt
function, and it isn't set until the first cr3 change.  We got away
with it until this happened.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

fix:

 arch/x86/kernel/cpu/common.c: In function 'early_identify_cpu':
 arch/x86/kernel/cpu/common.c:553: error: 'struct cpuinfo_x86' has no member named 'cpu_index'

as cpu_index is only available on SMP.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fix /proc/cpuinfo output on x86/Voyager

Ever since

| commit 92cb7612
| Author: Mike Travis <travis@sgi.com>
| Date:   Fri Oct 19 20:35:04 2007 +0200
|
|     x86: convert cpuinfo_x86 array to a per_cpu array

We've had an extra field in cpuinfo_x86 which is cpu_index.
Unfortunately, voyager has never initialised this, although the only
noticeable impact seems to be that /proc/cpuinfo shows all zeros for
the processor ids.

Anyway, fix this by initialising the boot CPU properly and setting the
index when the secondaries update.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: build fix on x86/Voyager

Given commits like this:

| Author: Suresh Siddha <suresh.b.siddha@intel.com>
| Date:   Tue Jul 29 10:29:19 2008 -0700
|
|     x86, xsave: enable xsave/xrstor on cpus with xsave support

Which deliberately expose boot cpu dependence to pieces of the system,
I think it's time to explicitly have a variable for it to prevent this
continual misassumption that the boot CPU is zero.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: allow /dev/mem mmaps on non-PAT CPUs/platforms

Fix mmap to /dev/mem when CONFIG_X86_PAT is off and CONFIG_STRICT_DEVMEM is
off

mmap to /dev/mem on kernel memory has been failing since the
introduction of PAT (CONFIG_STRICT_DEVMEM=n case).   Seems like
the check to avoid cache aliasing with PAT is kicking in even
when PAT is disabled. The bug seems to have crept in 2.6.26.

This patch makes sure that the mmap to regular
kernel memory succeeds if CONFIG_STRICT_DEVMEM=n and
PAT is disabled, and the checks to avoid cache aliasing
still happens if PAT is enabled.
Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
Tested-by: NTim Sirianni <tim@scalemp.com>
Cc: <stable@kernel.org>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fix build failure on x86/Voyager

Before:

| commit 329513a3
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date:   Wed Jul 2 18:54:40 2008 -0700
|
|     x86: move prefill_possible_map calling early

prefill_possible_mask() was hidden under CONFIG_HOTPLUG_CPU rendering
it invisitble to voyager.  Since this commit it's exposed, but not
provided by the voyager subarch, so add a dummy stub to fix the link
breakage.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fix x86/Voyager boot

CONFIG_SMP is used for features which work on *all* x86 boxes.
CONFIG_X86_SMP is used for standard PC like x86 boxes (for things like
multi core and apics)
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: boot up secondary CPUs as well on x86/Voyager systems

This commit:

| commit 3e970473
| Author: Glauber Costa <gcosta@redhat.com>
| Date:   Wed May 28 13:01:54 2008 -0300
|
|     x86: boot secondary cpus through initial_code

removed the use of initialize_secondary.  However, it didn't update
voyager, so the secondary cpus no longer boot.  Fix this by adding the
initial_code switch to voyager as well.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Glauber Costa <gcosta@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: include file dependency cleanup

Fix compile errors of files that include asm/uv/uv_hub.h but do
not include linux/timer.h.

[ such files are not mainline right now. ]
Signed-of-by: NMike Travis <travis@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

i2c_board_info array was filled incorrectly.
Due to circumstances, the way it is filled works.
This patch fills array properly.
Signed-off-by: NSergey Lapin <slapin@ossfans.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

mx31ads_defconfig compilation failed with

arch/arm/mach-mx3/mx31ads.c: In function 'mxc_init_imx_uart':
arch/arm/mach-mx3/mx31ads.c:102: error: 'mxc_uart_device0' undeclared (first use in this function)
arch/arm/mach-mx3/mx31ads.c:102: error: (Each undeclared identifier is reported only once
arch/arm/mach-mx3/mx31ads.c:102: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-mx3/mx31ads.o] Error 1

Add missing include
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The Data register holds the value we have written to a gpio. To
get the input value we must read the Pad Status Register MX3 (or Sample
Status register in MX1/2 terms)
Signed-off-by: NDarius Augulis <augulis.darius@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The internal devices of the MX3 Processor have to be mapped
MT_DEVICE_NONSHARED devices, otherwise cache corruptions occur.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

It was only used by this one SGI platform which recently was converted to
RTC_LIB and with RTC_LIB enabled the legacy drivers are no more selectable.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

It was only used by two SGI platforms which recently were converted to
RTC_LIB and with RTC_LIB enabled the legacy drivers are no more selectable.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>

As noticed by David Daney <ddaney@caviumnetworks.com>, the old long switch
statement did not comply with the Linux C coding style.  It was also yet
another place of code to be changed when adding a new processor type
leading to annoying bugs for example in /proc/cpuinfo.

Fixed by moving the setting of the CPU type string into the core of the
probing code and a few BUG_ON() test to ensure the CPU probing code indeed
did its job and removing multiple now redundant tests.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Acked-by: NDavid Daney <ddaney@caviumnetworks.com>

Arguably using the address error handler has always been ugly.  But with
processors that handle unaligned loads and stores in hardware the
current mechanism ceases to work so switch it to a BREAK instruction and
allocate break code 514 to the FPU emulator.

Yoichi Yuasa provided a build fix for CONFIG_BUG=n.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>

A system isn't necessarily booted on physical processor 0 as this code
assumes.  Also the array happens to be allocated in .bss so it's zero
initialized anyway.  Systems which need to override this can do so in
their mp_ops->smp_setup() method.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

It just so happens to be zero on all currently supported systems so this
hasn't bitten yet ...

[Ralf: Original patch from Cavium; handling of set_uncached_handler() and
de-ifdef'ed trap_init() implementation by me.]
Signed-off-by: NTomaso Paoletti <tpaoletti@caviumnetworks.com>
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

cpu_has_mips_r is true if a processor is MIPS32 or MIPS64, any architecture
revision.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix location of ethernet adddress when booted from external ROM.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

According to the documentation gpio_free should only be called from task
context only.  To make this more explicit add a might sleep to all
implementations.

This patch changes the gpio_free implementations for the arm architecture.
 DaVinci is skipped on purpose to simplify the merge process for patches
switching it over to use gpiolib as per request by David Brownell.
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: Andrew Victor <linux@maxim.org.za>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix compilation of sharpsl_pm when CONFIG_PM in unselected.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Impact: cleanup

To the unsuspecting user it is quite annoying that this broken and
inconsistent with x86-64 definition still exists.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The internal devices of the MX3 Processor have to be mapped
MT_DEVICE_NONSHARED devices, otherwise cache corruptions occur.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Impact: remove incorrect WARN_ON(1)

Gets rid of dmesg spam created during physical memory hot-add which
will very likely confuse users.  The change removes what appears to
be debugging code which I assume was unintentionally included in:

  x86: arch/x86/mm/init_64.c printk fixes
  commit 10f22ddeSigned-off-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: some new sparse warnings in e820.c etc, but no functional change.

As with regular ioremap, iounmap etc, annotate with __iomem.

Fixes the following sparse warnings, will produce some new ones
elsewhere in arch/x86 that will get worked out over time.

arch/x86/mm/ioremap.c:402:9: warning: cast removes address space of expression
arch/x86/mm/ioremap.c:406:10: warning: cast adds address space to expression (<asn:2>)
arch/x86/mm/ioremap.c:782:19: warning: Using plain integer as NULL pointer
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fewer sparse warnings, no functional changes

arch/x86/kernel/vsmp_64.c:87:14: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:87:14:    expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:87:14:    got void *[assigned] address
arch/x86/kernel/vsmp_64.c:88:22: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:88:22:    expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:88:22:    got void *
arch/x86/kernel/vsmp_64.c:100:23: warning: incorrect type in argument 2 (different address spaces)
arch/x86/kernel/vsmp_64.c:100:23:    expected void volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:100:23:    got void *
arch/x86/kernel/vsmp_64.c:101:23: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:101:23:    expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:101:23:    got void *
arch/x86/mm/gup.c:235:6: warning: incorrect type in argument 1 (different base types)
arch/x86/mm/gup.c:235:6:    expected void const volatile [noderef] <asn:1>*<noident>
arch/x86/mm/gup.c:235:6:    got unsigned long [unsigned] [assigned] start
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

corgi_lcd has symbol conflict with corgi_bl driver.
Fix it by renaming common symbol in new corgi_lcd driver.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

On spitz configure SPI CS GPIOs as outputs to unbreak spi chip selection.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Impact: change over-mapping to precise mapping, fix /proc/meminfo output

v2: fix less than 1G ram system handling

when gart aperture is 0xdc000000 - 0xe0000000
it return 0xc0000000 - 0xe0000000

that is not right.

this patch fix that will get exact mapping

on 256g sytem with that aperture after patch
LBSuse:~ # cat /proc/meminfo
MemTotal:       264742432 kB
MemFree:        263920628 kB
Buffers:            1416 kB
Cached:            24468 kB
...
DirectMap4k:      5760 kB
DirectMap2M:   3205120 kB
DirectMap1G:  265289728 kB

it is consistent to
LBSuse:~ # cat /sys/kernel/debug/kernel_page_tables
..
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000200000           2M     RW             GLB x  pte
0xffff880000200000-0xffff880040000000        1022M     RW         PSE GLB x  pmd
0xffff880040000000-0xffff8800c0000000           2G     RW         PSE GLB NX pud
0xffff8800c0000000-0xffff8800d7e00000         382M     RW         PSE GLB NX pmd
0xffff8800d7e00000-0xffff8800d7fa0000        1664K     RW             GLB NX pte
0xffff8800d7fa0000-0xffff8800d8000000         384K                           pte
0xffff8800d8000000-0xffff8800dc000000          64M                           pmd
0xffff8800dc000000-0xffff8800e0000000          64M     RW         PSE GLB NX pmd
0xffff8800e0000000-0xffff880100000000         512M                           pmd
0xffff880100000000-0xffff880800000000          28G     RW         PSE GLB NX pud
0xffff880800000000-0xffff880824600000         582M     RW         PSE GLB NX pmd
0xffff880824600000-0xffff8808247f0000        1984K     RW             GLB NX pte
0xffff8808247f0000-0xffff880824800000          64K     RW     PCD     GLB NX pte
0xffff880824800000-0xffff880840000000         440M     RW         PSE GLB NX pmd
0xffff880840000000-0xffff884000000000         223G     RW         PSE GLB NX pud
0xffff884000000000-0xffff884028000000         640M     RW         PSE GLB NX pmd
0xffff884028000000-0xffff884040000000         384M                           pmd
0xffff884040000000-0xffff888000000000         255G                           pud
0xffff888000000000-0xffffc20000000000       58880G                           pgd
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: fix AMD Family 11h boot hangs / USB device problems

The AMD Fam11h CPUs have a K8 northbridge. This northbridge is different
from other family's because it lacks GART support (as I just learned).

But the kernel implicitly expects a GART if it finds an AMD northbridge.

Fix this by removing the Fam11h northbridge id from the scan list of K8
northbridges. This patch also changes the message in the GART driver
about missing K8 northbridges to tell that the GART is missing which is
the correct information in this case.
Reported-by: NJouni Malinen <jkmalinen@gmail.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

so users are not confused with memhole causing big total ram

we don't need to worry about 32 bit, because memhole is always
above max_low_pfn.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>