Add default config for Emerson KSI8560 board.
Signed-off-by: NAlexandr Smirnov <asmirnov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Add boot wrapper for Emerson KSI8560 board.
Signed-off-by: NAlexandr Smirnov <asmirnov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The KSI8560 is a single compact, mid-, or full-size Advanced Mezzanine Card
(AdvancedMC™) based on the Freescale™ Semiconductor MPC8560 PowerQUICC III™
microprocessor. This product will serve in data and signaling applications such
as signaling gateways (SGW) and softswitch signaling interface cards.

The board has altera maxii CPLD, that is used to obtain and manage board
configuration. Also there are two SCC UART serial consoles and FCC ethernet,
that is routed to the front panel, while other ethernet controlers (TSEC's) are
routed to the backplane.
Signed-off-by: NAlexandr Smirnov <asmirnov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

scanlog_init() could use some love.

* properly return -ENODEV if this system doesn't support scan-log-dump
* don't printk if scan-log-dump not present; only older systems have it
* convert from create_proc_entry() to preferred proc_create()
* allocate zeroed data buffer
* fix potential memory leak of ent->data on failed create_proc_entry()
* simplify control flow
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds /sys/kernel/phyp_dump_active so that kdump init scripts may
look for it and take appropriate action if this file is found.  This
file is only created when phyp_dump has been registered.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds a kernel command line option "phyp_dump", which takes a 0/1
value for disabling/ enabling phyp_dump at boot time.  Kdump can use
this on cmdline (phyp_dump=0) to disable phyp-dump during boot when
enabling itself.  This will ensure only one dumping mechanism is active
at any given time.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Add hypervisor-assisted dump to kernel config.
Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This tracks the size freed.  For now it does a simple rudimentary
calculation of the ranges freed.  The idea is to keep it simple at the
external shell script level and send in large chunks for now.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds routines to
a. invalidate dump
b. calculate region that is reserved and needs to be freed.  This is
   exported through sysfs interface.

Unregister has been removed for now as it wasn't being used.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Provide some basic debugging support.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Set up the actual dump header, register it with the hypervisor.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Check to see if there actually is data from a previously
crashed kernel waiting.  If so, allow user-space tools to
grab the data (by reading /proc/kcore).  When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,

  echo "0x40000000 0x10000000" > /sys/kernel/release_region

will release 256MB starting at the 1GB.  The released memory
becomes free for general use.
Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Initial patch for reserving memory in early boot, and freeing it
later.  If the previous boot had ended with a crash, the reserved
memory would contain a copy of the crashed kernel data.
Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

These items in asm-offsets.c are not used anywhere.  This removes them.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The functions time_before, time_before_eq, time_after, and
time_after_eq are more robust for comparing jiffies against other
values.

This implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly.
Signed-off-by: NS.Çağlar Onur <caglar@pardus.org.tr>
Acked-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The hypervisor can look at the value in the wait_state_cycles field of
the VPA for an estimate of how busy dedicated processors are.
Currently, as the kernel never touches this field, we appear to be
100% busy.  This records the duration the kernel is in powersave and
passes that to the HV to provide a reasonable indication of
utilisation.
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The PT_DTRACE flag is meaningless and obsolete.
Don't touch it.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

It was being protected by CONFIG_PPC32, but we want to export it on
64-bit also.  This moves it out of the ifdef.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Some machines supported by the maple platform have an Obsidian
controller which can't be used without enabling CONFIG_IPR and the
options on which it depends.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This function has been a no-op for about 18 months; it's there in
the history should anyone need to resurrect it.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Prevailing practice for define_machine() in powerpc is to use the
platform name when the platform has only one define_machine()
statement, but maple uses "maple_md".  This caused me some
head-scratching when writing some new code that uses
machine_is(maple).

Use "maple" instead of "maple_md".  There should not be any behavioral
change -- fixup_maple_ide() calls machine_is(maple) but the body of
the function is ifdef'd out.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Print out 'model' property of '/' node as a machine name
in generic show_cpuinfo() routine.
Signed-off-by: NMarian Balakowicz <m8@semihalf.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The MDIO node in the lite5200b.dts file needs to also claim compatibility
with the older mpc5200 chip.  Otherwise the driver won't find the device.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

It appears that 64-bit PCI resources cannot possibly ever have worked on
x86-32 even when the RESOURCES_64BIT config option was set, because any
driver that tried to [pci_]ioremap() the resource would have been unable
to do so because the high 32 bits would have been silently dropped on
the floor by the ioremap() routines that only used "unsigned long".

Change them to use "resource_size_t" instead, which properly encodes the
whole 64-bit resource data if RESOURCES_64BIT is enabled.
Acked-by: NH. Peter Anvin <hpa@kernel.org>
Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The "bestcomm-core" driver defines its of_match table as follows

static struct of_device_id mpc52xx_bcom_of_match[] = {
	{ .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
	{ .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
	{},
};

so while registering the driver, the driver's probe function won't be
called, because the device tree node doesn't have a device_type
property.  Thus the driver's bcom_engine structure won't be allocated.
Referencing this structure later causes observed Oops.

Checking bcom_eng pointer for NULL before referencing data pointed
by it prevents oopsing, but fec driver still doesn't work (because
of the lost bestcomm match and resulted task allocation failure).
Actually the compatible property exists and should match and so
the fec driver should work.

This removes .type = "dma-controller" from the bestcomm driver's
mpc52xx_bcom_of_match table to solve the problem.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

If the bestcomm initialization fails, calls to the task allocate
function should fail gracefully instead of oopsing with a NULL deref.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL
if ipic_init() fails, which will happen on machines that don't have an
ipic interrupt controller.  init_ipic_sysfs() will crash in that case.
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

On pSeries, the hypervisor doesn't let us map in the eHEA ethernet
adapter using 64k pages, and thus the ehea driver will fail if 64k
pages are configured.  This works around the problem by always
using 4k pages for ioremap on pSeries (but not on other platforms).
A better fix would be to check whether the partition could ever
have an eHEA adapter, and only force 4k pages if it could, but this
will do for 2.6.25.

This is based on an earlier patch by Tony Breeds.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The PT_DTRACE flag is meaningless and obsolete.
Don't touch it.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Revert

commit f62f1fc9
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Fri Mar 7 15:02:50 2008 -0800

    x86: reserve dma32 early for gart

The patch has a dependency on bootmem modifications which are not .25
material that late in the -rc cycle. The problem which is addressed by
the patch is limited to machines with 256G and more memory booted with
NUMA disabled. This is not a .25 regression and the audience which is
affected by this problem is very limited, so it's safer to do the
revert than pulling in intrusive bootmem changes right now.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Currently kernel images are limited to 8MB in size, and this causes
problems especially when enabling features that take up a lot of
kernel image space such as lockdep.

The code now will align the kernel image size up to 4MB and map that
many locked TLB entries.  So, the only practical limitation is the
number of available locked TLB entries which is 16 on Cheetah and 64
on pre-Cheetah sparc64 cpus.  Niagara cpus don't actually have hw
locked TLB entry support.  Rather, the hypervisor transparently
provides support for "locked" TLB entries since it runs with physical
addressing and does the initial TLB miss processing.

Fully utilizing this change requires some help from SILO, a patch for
which will be submitted to the maintainer.  Essentially, SILO will
only currently map up to 8MB for the kernel image and that needs to be
increased.

Note that neither this patch nor the SILO bits will help with network
booting.  The openfirmware code will only map up to a certain amount
of kernel image during a network boot and there isn't much we can to
about that other than to implemented a layered network booting
facility.  Solaris has this, and calls it "wanboot" and we may
implement something similar at some point.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

so use nodedata_phys directly.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

fix the bug reported here:

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

use update_memory_range() instead of add_memory_range() directly
to avoid closing the gap.

( the new code only affects and runs on systems where the MTRR
  workaround triggers. )
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

we have seen a little problem in rebooting Dell Optiplex 745 with the
0KW626 board. Here is a small patch enabling reboot with this board,
which forces the default reboot path it into the BIOS reboot mode.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The fault_msg text is not explictly nul terminated now in startup
assembly. Do so by converting .ascii to .asciz.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

aperture_64.c takes a piece of memory and makes it into iommu
window... but such window may not be saved by swsusp -- that leads to
oops during hibernation.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

this patch allows hpet=force on nVidia nForce 430 southbridge.
This patch was tested by me on my old Asus A8N-VM CSM (where bios does not
support hpet and does not advertise it via acpi entry). My nForce430 version:
lspci -nn | grep LPC
00:0a.0 ISA bridge [0601]: nVidia Corporation MCP51 LPC Bridge [10de:0260]
(rev a2)

Kernel 2.6.24.3 after patching and using hpet=force reports this:
dmesg | grep -i hpet
Kernel command line: root=/dev/sda8 ro vga=773 video=vesafb:mtrr:4,ywrap
vt.default_utf8=0 hpet=force
Force enabled HPET at base address 0xfed00000
hpet clockevent registered
Time: hpet clocksource has been installed.

grep -i hpet /proc/timer_list
Clock Event Device: hpet
 set_next_event: hpet_legacy_next_event
 set_mode:       hpet_legacy_set_mode

grep Clock /proc/timer_list (before patching)
Clock Event Device: pit
Clock Event Device: lapic

grep Clock /proc/timer_list (after patching)
Clock Event Device: hpet
Clock Event Device: lapic
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

a system with 256 GB of RAM, when NUMA is disabled crashes the
following way:

Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Cannot allocate aperture memory hole (ffff8101c0000000,65536K)
Kernel panic - not syncing: Not enough memory for aperture
Pid: 0, comm: swapper Not tainted 2.6.25-rc4-x86-latest.git #33

Call Trace:
 [<ffffffff84037c62>] panic+0xb2/0x190
 [<ffffffff840381fc>] ? release_console_sem+0x7c/0x250
 [<ffffffff847b1628>] ? __alloc_bootmem_nopanic+0x48/0x90
 [<ffffffff847b0ac9>] ? free_bootmem+0x29/0x50
 [<ffffffff847ac1f7>] gart_iommu_hole_init+0x5e7/0x680
 [<ffffffff847b255b>] ? alloc_large_system_hash+0x16b/0x310
 [<ffffffff84506a2f>] ? _etext+0x0/0x1
 [<ffffffff847a2e8c>] pci_iommu_alloc+0x1c/0x40
 [<ffffffff847ac795>] mem_init+0x45/0x1a0
 [<ffffffff8479ff35>] start_kernel+0x295/0x380
 [<ffffffff8479f1c2>] _sinittext+0x1c2/0x230

the root cause is : memmap PMD is too big,
[ffffe200e0600000-ffffe200e07fffff] PMD ->ffff81383c000000 on node 0
almost near 4G..., and vmemmap_alloc_block will use up the ram under 4G.

solution will be:
1. make memmap allocation get memory above 4G...
2. reserve some dma32 range early before we try to set up memmap for all.
and release that before pci_iommu_alloc, so gart or swiotlb could get some
range under 4g limit for sure.

the patch is using method 2.
because method1 may need more code to handle SPARSEMEM and SPASEMEM_VMEMMAP

will get
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
Memory: 264245736k/268959744k available (8484k kernel code, 4187464k reserved, 4004k data, 724k init)
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>