Added the mpc85xx family of dts files to the powerpc tree
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* Fix IRQ support in the 85xx CDS boards so it uses the new
  generic stuff
* Fix PCI IRQ mapping to use the device tree
* Disabled i8259 support to allow the CDS to boot.  This will be
  fixed soon, but the current code doesn't even compile, so this
  is a vast improvement
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* Fixed 8540 ADS support for the new irq layer
* Fixed 8540 ADS support for mapping PCI interrupts
* Updated 8540 ADS to use device tree for interrupt assignment
  and sense values
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Add 'linux,phandle' entry to i8259@4d0 node.
Signed-off-by: NZhang Wei <wei.zhang@freescale.com>
Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Also fix 80-column run-over.
Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

As per list discussion, let's add device tree source files
under powerpc/boot/dts.  If nothing else, it is a starting point.
Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Also accept "local-mac-address".  However the old "address"
is now obsolete, but accepted for backwards compatibility.
It should be removed after all device trees have been
converted to use "mac-address".
Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Clear HID0[en_attn] at CPU init time on PPC970.  Closes CVE-2006-4093.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The code for using the radix tree for reverse mapping of interrupts has
a typo that causes it to create incorrect mappings if the software and
hardware numbers happen to be different. This would, among others, cause
the IDE interrupt to fail on js20's. This fixes it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

- On archs that have no-exec support, we vmalloc() a executable scratch
area of PAGE_SIZE and divide it up into an array of slots of maximum
instruction size for that arch
- On a kprobe registration, the original instruction is copied to the
first available free slot, so if multiple kprobes are registered, chances
are, they get contiguous slots
- On POWER4, due to not having coherent icaches, we could hit a situation
where a probe that is registered on one processor, is hit immediately on
another. This second processor could have fetched the stream of text from
the out-of-line single-stepping area *before* the probe registration
completed, possibly due to an earlier (and a different) kprobe hit and
hence would see stale data at the slot.

Executing such an arbitrary instruction lead to a problem as reported
in LTC bugzilla 23555.

The correct solution is to call flush_icache_range() as soon as the
instruction is copied for out-of-line single-stepping, so the correct
instruction is seen on all processors.

Thanks to Will Schmidt who tracked this down.
Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
Acked-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

To compile kexec on 32-bit we need a few more bits and pieces. Rather
than add empty definitions, we can make crash.c work on 32-bit, with
only a couple of kludges.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

We're missing a few functions for kexec to compile on 32-bit. There's
nothing really 64-bit specific about the 64-bit versions, so make them
generic rather than adding empty definitions for 32-bit.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Updating the defconfigs for iseries, pseries, and G5.   Sticking with
the defaults, with the following exceptions:  I've turned off HW_RANDOM
for all three configs.   For G5, I've enabled SND_AOA and friends as
modules; this includes the FABRIC_LAYOUT, ONYX, TAS, TOONIE and
SOUNDBUS* config options.
Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

In the case of a system hang, the user will invoke soft-reset to
initiate the kdump boot.  If xmon is enabled, the CPU(s) enter into the
xmon debugger.   Unfortunately, the secondary CPU(s) will return to the
hung state when they exit from the debugger (returned from die() ->
system_reset_exception()).  This causes a problem in kdump since the
hung CPU(s) will not respond to the IPI sent from kdump.  This patch
fixes the issue by calling crash_kexec_secondary() directly from
system_reset_exception() without returning to the previous state.  These
secondary CPUs wait 5ms until the kdump boot is started by the primary
CPU.   In the case we exited from the debugger to "recover" (command 'x'
in xmon) the primary and the secondary CPUs will all return from die()
-> system_reset_exception() ->crash_kexec_secondary() wait 5ms, then
return to the previous state.  A kdump boot is not started in this case.
Signed-off-by: NHaren Myneni <haren@us.ibm.com>
Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Noticing the following might_sleep warning (dump_stack()) during kdump
testing when CONFIG_DEBUG_SPINLOCK_SLEEP is enabled. All secondary CPUs
will be calling rtas_set_indicator with interrupts disabled to remove
them from global interrupt queue.

BUG: sleeping function called from invalid context at
arch/powerpc/kernel/rtas.c:463
in_atomic():1, irqs_disabled():1
Call Trace:
[C00000000FFFB970] [C000000000010234] .show_stack+0x68/0x1b0 (unreliable)
[C00000000FFFBA10] [C000000000059354] .__might_sleep+0xd8/0xf4
[C00000000FFFBA90] [C00000000001D1BC] .rtas_busy_delay+0x20/0x5c
[C00000000FFFBB20] [C00000000001D8A8] .rtas_set_indicator+0x6c/0xcc
[C00000000FFFBBC0] [C000000000048BF4] .xics_teardown_cpu+0x118/0x134
[C00000000FFFBC40] [C00000000004539C]
.pseries_kexec_cpu_down_xics+0x74/0x8c
[C00000000FFFBCC0] [C00000000002DF08] .crash_ipi_callback+0x15c/0x188
[C00000000FFFBD50] [C0000000000296EC] .smp_message_recv+0x84/0xdc
[C00000000FFFBDC0] [C000000000048E08] .xics_ipi_dispatch+0xf0/0x130
[C00000000FFFBE50] [C00000000009EF10] .handle_IRQ_event+0x7c/0xf8
[C00000000FFFBF00] [C0000000000A0A14] .handle_percpu_irq+0x90/0x10c
[C00000000FFFBF90] [C00000000002659C] .call_handle_irq+0x1c/0x2c
[C00000000058B9C0] [C00000000000CA10] .do_IRQ+0xf4/0x1a4
[C00000000058BA50] [C0000000000044EC] hardware_interrupt_entry+0xc/0x10
 --- Exception: 501 at .plpar_hcall_norets+0x14/0x1c
   LR = .pseries_dedicated_idle_sleep+0x190/0x1d4
[C00000000058BD40] [C00000000058BDE0] 0xc00000000058bde0 (unreliable)
[C00000000058BDF0] [C00000000001270C] .cpu_idle+0x10c/0x1e0
[C00000000058BE70] [C000000000009274] .rest_init+0x44/0x5c

To fix this issue, rtas_set_indicator_fast() is added so that will not
wait for RTAS 'busy' delay and this new function is used for kdump (in
xics_teardown_cpu()) and for CPU hotplug ( xics_migrate_irqs_away() and
xics_setup_cpu()).

Note that the platform architecture spec says that set-indicator
on the indicator we're using here is not permitted to return the
busy or extended busy status codes.
Signed-off-by: NHaren Myneni <haren@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

We should not be calling power4_enable_pmcs() in
pseries_lpar_enable_pmcs(); just doing the hypercall is sufficient.
Prior to 2.6.15 we did not call power4_enable_pmcs() for an lpar.

power4_enable_pmcs() tries to read the hid0 register which is no
longer legal for an lpar in newer Power processors.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Clean up proc file removal in sq module for superh arch.  currently on a
failed module load or on module unload a proc file is left registered which
can cause a random memory execution or oopses if read after unload.  This
patch cleans up that deregistration.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The uncached allocator has a function, uncached_get_new_chunk(), that needs
to be serialized on a per node basis. It also has a global variable,
allocated_granules, which should be defined on a per node basis and protected
by that serialization. Additionally, all error returns from functions called
(like ia64_pal_mc_drain()) should be handled appropriately.
Signed-off-by: NDean Nelson <dcn@sgi.com>
Acked-by: NJes Sorenson <jes@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

contig.c (FLATMEM) requires the same optimization as in discontig.c for show_mem
when VIRTUAL_MEM_MAP is in use. Otherwise FLATMEM has softlockup timeouts.
This was boot tested for memory configuration: SPARSEMEM,
DISCONTIG+VIRTUAL_MEM_MAP, FLATMEM, FLATMEM+VIRTUAL_MEM_MAP and
FLATMEM+VIRTUAL_MEM_MAP with largest memory gap less than LARGE_GAP by
using boot parameter "mem=".

This was boot tested and "echo m >/proc/sysrq-trigger" output evaluated for
: FLATMEM, FLATMEM+VIRTUAL_MEM_MAP, DISCONTIGMEM+VIRTUAL_MEM_MAP and
SPARSEMEM.
Signed-off-by: NBob Picco <bob.picco@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Assure that vmem_map's high endpoint is MAX_ORDER aligned. Not doing so violates
the buddy allocator algorithm. Also anyone using mem=XXX on boot line and
not aligned to MAX_ORDER requires this patch in order to satisfy buddy
allocator. vmem_map always starts at pfn 0. The potentially large MAX_ORDER
on ia64 (due to hugetlbfs) requires that the end of vmem_map be aligned
to MAX_ORDER_NR_PAGES.

This was boot tested for: FLATMEM, FLATMEM+VIRTUAL_MEM_MAP,
DISCONTIGMEM+VIRTUAL_MEM_MAP and SPARSEMEM.
Signed-off-by: NBob Picco <bob.picco@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

CONFIG_MD_RAID5 became CONFIG_MD_RAID456 in drivers/md/Kconfig.  Make
the same change in arch/ia64
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NAron Griffis <aron@hp.com>
Acked-by: NJes Sorenson <jes@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

If CONFIG_IOMMU_DEBUG is set force_iommu defaults to 1. In the case
where no HW IOMMU is present in the machine and we end up using nommu,
leaving force_iommu set to 1 causes dma_alloc_coherent to do the wrong
thing. Therefore, if we end up using nommu, make sure force_iommu is
0.
Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Re-add backlink for old style unwinder to stack switching.  Add proper
stack frame and CFI annotations to call_softirq

This prevents a oops when backtracing with fallback through the
interrupt stack top.

Suggested by Jan Beulich and Herbert Xu wanted it in 2.6.18.

Cc: jbeulich@novell.com
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I think ia64_switch_mode_phys and ia64_switch_mode_virt
does not need to alloc an empty frame.
An empty frame is required by loadrs but flushrs
does not need that.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

We found an issue in pal.S.

According to the software runtime SPEC,
The caller's output registers do not need to be preserved for
caller. The callee may reuse input registers for any other
purpose within the procedure.

in ia64_pal_call_phys_stacked,

input registers are copied to output registers before call
into ia64_switch_mode_phys, then used to call into PAL. This
assumes output registers are preserved in ia64_switch_mode_phys,
which may not be true.

In this particular case, ia64_switch_mode_phys alloc a null frame
, and mask off psr.i.
If an interrupt comes at this small window,
or an MCA comes inside the procedure, output registers
maybe changed,
then the pal call may got some staled input registers.

This patch moves the copies from input to output
after ia64_switch_mode_phys to follow the software
runtime convention.

It  also removed some unused labels in
ia64_pal_call_phys_stacked.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Fix some sparse warnings on ia64.  Large constants that should be long
instead of int.  Use NULL instead of 0.  Add some missing __iomem
casts.  Replace a non-C99 structure assignment.
Signed-off-by: NKeith Owens <kaos@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Patch from David Brownell

ARM genirq cleanups/updates:

    - Start switching platforms to newer APIs
        * use "irq_chip" name, not "irqchip"
        * providing irq_chip.name

    - Show irq_chip.name in /proc/interrupts, like on x86.

This update a bit more than half of the ARM code.  The irq_chip.name
values were chosen to match docs (if I have them) or be otherwise
obvious ("FPGA", "CPLD", or matching the code).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Note how any error from acpi_processor_preregister_performance is ignored.

From: bert hubert <bert.hubert@netherlabs.nl>
Signed-off-by: NDave Jones <davej@redhat.com>

This table is only used by Ezra-T CPUs currently, and has values
for some other CPU. Fix them to match the values used by that CPU,
and for now make it clearer by renaming the variable.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This is changing "always true" test to something usefull.
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

I lost very important line in do_powersaver
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch makes the needlessly global longhaul_walk_callback() static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>

It seems commit 32ee8c3e accidentially
reverted cdc9cc1d, IOW, it reintroduced
the following compile error with CONFIG_PCI=n:

<--  snip  -->

...
  CC      arch/i386/kernel/cpu/cpufreq/gx-suspmod.o
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c: In function ‘gx_detect_chipset’:
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: error: implicit declaration of function ‘pci_match_id’
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: warning: comparison between pointer and integer
make[3]: *** [arch/i386/kernel/cpu/cpufreq/gx-suspmod.o] Error 1

<--  snip  -->

This patch therefore re-adds the dependency of X86_GX_SUSPMOD on PCI.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>

Without this longhaul will always fail when compiled into kernel,
as it needs to initialise after the ACPI processor module.

I lost this when I was splitting patches. Sorry.
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

There is no need to worry about local APIC.
There is need to worry about I/O APIC, because I/O APIC
is replacing good old 8259. According to Nehemiah datasheet VIA is
using 3-wire bus to connect local APIC to I/O APIC.

"[...] When IA32_APIC_BASE[11] is set to 0, processor APICs based on the 3-wire APIC
 bus cannot be generally re-enabled until a system hardware reset. The 3-wire bus
 looses track of arbitration that would be necessary for complete re-enabling. Certain
 (local) APIC functionality can be enabled. [...]"

So we must set disable bit for each interrupt in I/O APIC registers.
Same situation as for PIC - we must poke registers direcly.
How to do this? I don't know. So at the moment it is better to fail.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

Minimal change necessary for hardware support.

Changes in longhaul.c:
- most important - now C3 state is causing transition,
- code responsible for clearing "bus master" bit removed,
- protect bcr2 transition in the same way as longhaul.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch fixes several problems:
- The legacy backlight value might be set at interrupt time. Introduced
  a worker to prevent it from directly calling the backlight code.
- via-pmu allows the backlight to be grabbed, in which case we need to
  prevent other kernel code from changing the brightness.
- Don't send PMU requests in via-pmu-backlight when the machine is about
  to sleep or waking up.
- More Kconfig fixes.
Signed-off-by: NMichael Hanselmann <linux-kernel@hansmi.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

CFA needs to be adjusted upwards for push, and downwards for pop.
arch/i386/kernel/entry.S gets it wrong in one place.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NJan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The latest toolchains can produce a new ELF section in DSOs and
dynamically-linked executables.  The new section ".gnu.hash" replaces
".hash", and allows for more efficient runtime symbol lookups by the
dynamic linker.  The new ld option --hash-style={sysv|gnu|both} controls
whether to produce the old ".hash", the new ".gnu.hash", or both.  In some
new systems such as Fedora Core 6, gcc by default passes --hash-style=gnu
to the linker, so that a standard invocation of "gcc -shared" results in
producing a DSO with only ".gnu.hash".  The new ".gnu.hash" sections need
to be dealt with the same way as ".hash" sections in all respects; only the
dynamic linker cares about their contents.  To work with older dynamic
linkers (i.e.  preexisting releases of glibc), a binary must have the old
".hash" section.  The --hash-style=both option produces binaries that a new
dynamic linker can use more efficiently, but an old dynamic linker can
still handle.

The new section runs afoul of the custom linker scripts used to build vDSO
images for the kernel.  On ia64, the failure mode for this is a boot-time
panic because the vDSO's PT_IA_64_UNWIND segment winds up ill-formed.

This patch addresses the problem in two ways.

First, it mentions ".gnu.hash" in all the linker scripts alongside ".hash".
 This produces correct vDSO images with --hash-style=sysv (or old tools),
with --hash-style=gnu, or with --hash-style=both.

Second, it passes the --hash-style=sysv option when building the vDSO
images, so that ".gnu.hash" is not actually produced.  This is the most
conservative choice for compatibility with any old userland.  There is some
concern that some ancient glibc builds (though not any known old production
system) might choke on --hash-style=both binaries.  The optimizations
provided by the new style of hash section do not really matter for a DSO
with a tiny number of symbols, as the vDSO has.  If someone wants to use
=gnu or =both for their vDSO builds and worry less about that
compatibility, just change the option and the linker script changes will
make any choice work fine.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Andi Kleen <ak@muc.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>