In pseries/lpar.c, fix some printf specifier mismatches, and add
a newline to one printk.

In pseries/rtasd.c add "rtasd" to some messages to make it clear
where they're coming from.

In pseries/scanlog.c remove the hand-rolled runtime debugging support
in there. This file has been largely unchanged for eons, if we need to
debug it in future we can recompile.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

On pseries LPAR we can call the udbg routines, and the udbg console very
early. So mark the udbg console as safe to call early in boot, and register
the udbg console as soon as the udbg routines are hooked up.

This allows platforms/pseries code to use printk() and pr_debug() rather
than needing to call udbg_printf() directly for early debugging. This is
nice because a) it's standard, b) it goes via the printk buffer, and c)
you can get printk time stamps.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The udbg console should be safe to call basically at any time after boot.
It does not need any per-cpu resources or for the cpu to be online, as
long as there is a udbg_putc routine hooked up it should work. So mark it
as CON_ANYTIME.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Because the udbg_console has CON_ENABLED set, it's possible that when we
register it with the console code the index won't be set. This leads to
slightly confusing boot messages like:

[    0.000000] console [udbg-1] enabled

We could remove CON_ENABLED, but we don't want to do that, we always
want the udbg console to be activated, even if the user specified some
other console on the command line.

The simplest fix seems to be just to set the index to 0 by hand. There
is no issue with duplicate udbg consoles, as we guard against registering
multiple times in register_early_udbg_console().
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds the required functionality to fill in all pacas at runtime.

With NR_CPUS=1024
text    data     bss     dec     hex filename
 137 1704032       0 1704169  1a00e9 arch/powerpc/kernel/paca.o :Before
 121 1179744  524288 1704153  1a00d9 arch/powerpc/kernel/paca.o :After

Also remove unneeded #includes from arch/powerpc/kernel/paca.c
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Currently all iSeries secondary CPUs spin directly on the cpu_start
field in their paca.  Make them spin on the global
__secondary_hold_spinloop until after the pacas have been initialised.

As Stephen Rothwell points out, this works at the moment because
__secondary_hold_spinloop is being set already, but iSeries isn't
looking at it :)
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Acked-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* Removed get_msr(), get_srr0(), and get_srr1() - not used anywhere
* Use STACK_FRAME_OVERHEAD instead of magic number
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Replace two open-coded occurences of the of_get_next_parent() logic.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

As BenH said the other day, it is an "accident" that prom_init.o is
linked with the rest of the kernel.  The truth is a little more
subtle, prom_init isn't truly bootloader, it does access kernel data
in a few places.

What we can do is discourage people from adding new code that accesses
data outside of prom_init.  And hence this patch; from the script:

 # This script checks prom_init.o to see what external symbols it
 # is using, if it finds symbols not in the whitelist it returns
 # an error. The point of this is to discourage people from
 # intentionally or accidentally adding new code to prom_init.c
 # which has side effects on other parts of the kernel.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* Removed TI_EXECDOMAIN define as its not used anywhere
* Use STACK_INT_FRAME_SIZE to allow common define of INT_FRAME_SIZE
* Define TI_CPU on both ppc32 & ppc64 (removes an ifdef).
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Use (31-THREAD_SHIFT) to get to thread_info from stack pointer.  This makes
the code a bit easier to read and more robust if we ever change THREAD_SHIFT.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Remove the inclusion of asm-offsets.h from stacktrace.c.  It isn't
supposed to be included in C code and it causes problems with multiple
definitions of things.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The fixmap code from x86 allows us to have compile time virtual addresses
that we change the physical addresses of at run time.

This is useful for applications like kmap_atomic, PCI config that is done
via direct memory map, kexec/kdump.

We got ride of CONFIG_HIGHMEM_START as we can now determine a more optimal
location for PKMAP_BASE based on where the fixmap addresses start and
working back from there.

Additionally, the kmap code in asm-powerpc/highmem.h always had debug
enabled.  Moved to using CONFIG_DEBUG_HIGHMEM to determine if we should
have the extra debug checking.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations and
kdump).  The support can be configured at compile time by setting
CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
desired.

Alternatively, the kernel build can set CONFIG_RELOCATABLE.  Setting this
config option causes the kernel to determine at runtime the physical
addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START.  If
CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning.
However, CONFIG_PHYSICAL_START will always be used to set the LOAD program
header physical address field in the resulting ELF image.

Currently we are limited to running at a physical address that is a
multiple of 256M.  This is due to how we map TLBs to cover
lowmem.  This should be fixed to allow 64M or maybe even 16M alignment
in the future.  It is considered an error to try and run a kernel at a
non-aligned physical address.

All the magic for this support is accomplished by proper initialization
of the kernel memory subsystem and use of ARCH_PFN_OFFSET.

The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings.
ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET.

/dev/mem continues to allow access to any physical address in the system
regardless of how CONFIG_PHYSICAL_START is set.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Commit 0119536c added an assembly
version of strncmp to PowerPC.  However, it changed a common header
file between arch/ppc and arch/powerpc without adding strncmp to
arch/ppc.  This fixes that omission so that arch/ppc links again.
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The MPSC driver and prpmc2800.dts have been modified to use property
'cell-index' as the serial port number, but the early serial console
driver for the mv64x60 has not been modified to use this new property.
This fixes it.

Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
Acked-by: NDale Farnsworth <dale@farnsworth.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized.

This changes the code to display an error and continue the
initialization.

Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
Signed-off-by: NPaul Mackerras <paulus@samba.org>

I2C parameters freq_m and freq_n are assigned defaults in the code,
but if properties for those parameters are not found in the open
firmware description the init routine returns an error and doesn't
create the platform device.

This changes the code so that it doesn't return an error if the
properties are not found but instead uses the default values.

Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
Acked-by: NDale Farnsworth <dale@farnsworth.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.

However, when using 64K pages, the stack is smaller than a page,
so we use kmalloc to allocate it, but that doesn't provide the
alignment guarantee we need.

It appeared to work so far... until one enables SLUB debugging
which then returns unaligned pointers.  Ooops...

This fixes it by using a slab cache with enforced alignment.  It
relies on my previous patch that adds a thread_info_cache_init()
callback.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

os-area.c requires routines declared in linux/of.h, so should include it.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

numa.c requires routines declared in linux/of.h, so should include it.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This reverts commit e4cc5894, as
requested by Roland McGrath, because compat_ptrace_request (added in
commit e16b2781, "ptrace:
compat_ptrace_request siginfo") now handles this case.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Move XPC and XPNET from arch/ia64/sn/kernel to drivers/misc/sgi-xp.
Signed-off-by: NDean Nelson <dcn@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

- remove unused 'irq' argument from pfm_do_interrupt_handler()

- remove pointless cast to void*

- add KERN_xxx prefix to printk()

- remove braces around singleton C statement

- in tioce_provider.c, start tioce_dma_consistent() and
  tioce_error_intr_handler() function declarations in column 0

This change's main purpose is to prepare for the patchset in
jgarzik/misc-2.6.git#irq-remove, that explores removal of the
never-used 'irq' argument in each interrupt handler.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

There are many notify_die() and almost all take same style with
ia64_mca_spin().  This patch defines macros and replace them all,
to reduce lines and to improve readability.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

There are 3 hooks in MCA handler, but this DIE_MCA_MONARCH_PROCESS
event does not notified other than for the first monarch.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

While testing with CONFIG_VIRT_CPU_ACCOUNTING=y, I found that
I occasionally get very huge system time in some threads.

So I dug the issue and finally noticed that it was caused
because of an interrupt which interrupt in the following window:

> [arch/ia64/kernel/entry.S: (!CONFIG_PREEMPT && CONFIG_VIRT_CPU_ACCOUNTING)]
>
> ENTRY(ia64_leave_syscall)
>    :
> (pUStk) rsm psr.i
>         cmp.eq pLvSys,p0=r0,r0          // pLvSys=1: leave from syscall
> (pUStk) cmp.eq.unc p6,p0=r0,r0          // p6 <- pUStk
> .work_processed_syscall:
>         adds r2=PT(LOADRS)+16,r12
> (pUStk) mov.m r22=ar.itc                        // fetch time at leave
>         adds r18=TI_FLAGS+IA64_TASK_SIZE,r13
>         ;;
> <<< window: from here >>>
> (p6)    ld4 r31=[r18]  // load current_thread_info()->flags
>         ld8 r19=[r2],PT(B6)-PT(LOADRS)
>         adds r3=PT(AR_BSPSTORE)+16,r12
>         ;;
>         mov r16=ar.bsp
>         ld8 r18=[r2],PT(R9)-PT(B6)
> (p6)    and r15=TIF_WORK_MASK,r31  // any work other than TIF_SYSCALL_TRACE?
>         ;;
>         ld8 r23=[r3],PT(R11)-PT(AR_BSPSTORE)
> (p6)    cmp4.ne.unc p6,p0=r15, r0               // any special work pending?
> (p6)    br.cond.spnt .work_pending_syscall
>         ;;
>         ld8 r9=[r2],PT(CR_IPSR)-PT(R9)
>         ld8 r11=[r3],PT(CR_IIP)-PT(R11)
> (pNonSys) break 0 // bug check: we shouldn't be here if pNonSys is TRUE!
>         ;;
>         invala
> <<< window: to here >>>
>         rsm psr.i | psr.ic // turn off interrupts and interruption collection

If pUStk is true, it means we are going to return user mode, hence we fetch
ar.itc to get time at leave from system.
It seems that it is not possible to interrupt the window if pUStk is true,
because interrupts are disabled early.  And also disabling interrupt makes
sense because it is safe for referring current_thread_info()->flags.

However interrupting the window while pUStk is true was possible.
The route was:
ia64_trace_syscall
-> .work_pending_syscall_end
-> .work_processed_syscall
Only in case entering the window from this route, interrupts are enabled
during in the window even if pUStk is true.  I suppose interrupts must be
disabled here anyway if pUStk is true.
I'm not sure but afraid that what kind of bad effect were there, other
than crazy system time which I found.

FYI, there was a commit 6f6d7582 that
points out a bug at same point(exit of ia64_trace_syscall) in 2006.
It can be said that there was an another bug.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch removes the no longer used export of kmap_atomic_to_page.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NJesper Juhl <jesper.juhl@gmail.com>

As per Documentation/feature-removal-schedule.txt
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on.  This patch fixes
it by making sure all FP registers have been properly initialized at kernel
boot.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We have a board port in arch/powerpc so we dont need this one anymore.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We have a board port in arch/powerpc so we dont need this one anymore.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Use the generic pci_enable_resources() instead of the arch-specific code.

Unlike this arch-specific code, the generic version:
    - checks PCI_NUM_RESOURCES (11), not DEVICE_COUNT_RESOURCE (12), resources
    - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
    - skips ROM resources unless IORESOURCE_ROM_ENABLE is set
    - checks for resource collisions with "!r->parent"
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: NKyle McMartin <kyle@mcmartin.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the generic pci_enable_resources() instead of the arch-specific code.

Unlike this arch-specific code, the generic version:
    - checks PCI_NUM_RESOURCES (11), not 6, resources
    - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
    - skips ROM resources unless IORESOURCE_ROM_ENABLE is set
    - checks for resource collisions with "!r->parent", not IORESOURCE_UNSET
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the generic pci_enable_resources() instead of the arch-specific code.
The generic version is functionally equivalent, but uses dev_printk.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the generic pci_enable_resources() instead of the arch-specific code.

Unlike this arch-specific code, the generic version:
    - does not check for a NULL dev pointer
    - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the generic pci_enable_resources() instead of the arch-specific code.

Unlike this arch-specific code, the generic version:
    - skips resources unless requested in "mask"
    - skips ROM resources unless IORESOURCE_ROM_ENABLE is set
    - checks for resource collisions with "!r->parent"
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the generic pci_enable_resources() instead of the arch-specific code.

Unlike this arch-specific code, the generic version:
    - checks for resource collisions with "!r->parent"
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The "pci=routeirq" option was added in 2004, and I don't get any valid
reports anymore.  The option is still mentioned in kernel-parameters.txt.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>