Impact: cleanup, futureproof

In fact, all cpumask ops will only be valid (in general) for bit
numbers < nr_cpu_ids.  So use that instead of NR_CPUS in various
places.

This is always safe: no cpu number can be >= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>
Acked-by: NIngo Molnar <mingo@elte.hu>

Impact: use new API

Use the accessors rather than frobbing bits directly.  Most of this is
in arch code I haven't even compiled, but is straightforward.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>

Impact: use new API

Use the accessors rather than frobbing bits directly.  Most of this is
in arch code I haven't even compiled, but it is mostly straightforward.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>

We're weaning the core code off handing cpumask's around on-stack.
This introduces arch_send_call_function_ipi_mask(), and by defining
it, the old arch_send_call_function_ipi is defined by the core code.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Impact: Use new API

Change smp_call_function_mask() callers to smp_call_function_many().
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>

Based upon a report by Meelis Roos.

Sparc64 SBUS and PCI controllers use a combination of IMAP and ICLR
registers to manage device interrupts.

The IMAP register contains the "valid" enable bit as well as CPU
targetting information.  Whereas the ICLR register is written with
zero at the end of handling an interrupt to reset the state machine
for that interrupt to IDLE so it can be sent again.

For PCI slot and SBUS slot devices we can have multiple interrupts
sharing the same IMAP register.  There are individual ICLR registers
but only one IMAP register for managing those.

We represent each shared case with individual virtual IRQs so the
generic IRQ layer thinks there is only one user of the IRQ instance.

In such shared IMAP cases this is wrong, so if there are multiple
active users then a free_irq() call will prematurely turn off the
interrupt by clearing the Valid bit in the IMAP register even though
there are other active users.

Fix this by simply doing nothing in sun4u_disable_irq() and checking
IRQF_DISABLED during IRQ dispatch.

This situation doesn't exist in the hypervisor sun4v cases, so I left
those alone.
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Return was missing for the case where there is no dimm
info match.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is an implementation of a suggestion made by Chris Torek:
--------------------
Something else I noticed in passing: the EX and EX_LD/EX_ST macros
scattered throughout the various .S files make a fair bit of .fixup
code, all of which does the same thing.  At the cost of one symbol
in copy_in_user.S, you could just have one common two-instruction
retl-and-mov-1 fixup that they all share.
--------------------

The following is with a defconfig build:

   text	   data	    bss	    dec	    hex	filename
3972767	 344024	 584449	4901240	 4ac978	vmlinux.orig
39688877	 344024	 584449	4897360	 4aba50	vmlinux
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They can't be used for profiling and NMI watchdog currently
since they lack the counter overflow interrupt.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When we're idling in NOHZ mode, timer interrupts are not running.

Evidence of processing timer interrupts is what the NMI watchdog
uses to determine if the CPU is stuck.

On Niagara, we'll yield the cpu.  This will make the cpu, at
worst, hang out in the hypervisor until an interrupt arrives.
This will prevent the NMI watchdog timer from firing.

However on non-Niagara we just loop executing instructions
which will cause the NMI watchdog to keep firing.  It won't
see timer interrupts happening so it will think the cpu is
stuck.

Fix this by touching the NMI watchdog in the cpu idle loop
on non-Niagara machines.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It all lives in the oprofile support code currently and we will need
to share this stuff with NMI watchdog and perf_counter support.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we do a userspace access from kernel mode, and get a
data access exception, we need to check the exception
table just like a normal fault does.

The spitfire DAX handler was doing this, but such logic
was missing from the sun4v DAX code.
Reported-by: NDennis Gilmore <dgilmore@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is only one clock board, so use -1 as the 'id' so we get just
the base name as the LED device name string.

There are multiple FHC boards potentially in a system so use the board
number as the 'id' value for that case.
Reported-by: NMeelis Roos <mroos@linux.ee>
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Meelis reported that on his box /proc/cpuinfo started
to reported "Unknow CPU" and the same did the boot messages.

It was a stupid bug I introduced when merging
cpu.c for 32 and 64 bit.

The code did an array reference where it had to search
for the right index.
Reported-by: NMeelis Roos <mroos@linux.ee>
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove __attribute__((weak)) from common code sys_pipe implemantation.
IA64, ALPHA, SUPERH (32bit) and SPARC (32bit) have own implemantations
with the same name. Just rename them.
For sys_pipe2 there is no architecture specific implementation.

Cc: Richard Henderson <rth@twiddle.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

This way it matches the generic system call name convention.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

sparc_ksyms_64.c includes asm/spinlock.h directly, which is
a no-no.

Even better, none of these exports are even necessary.  All
of these functions are inlines.

Reported by Meelis Roos and Alexander Beregalov.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move all applicable EXPORT_SYMBOL()s to the file where the respective
symbol is defined.

Removed all the includes that are no longer needed in sparc_ksyms_64.c

Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_64.c
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Additions by Julian Calaby:
* Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
* Made some minor cleanups to the includes and comments of sparc_ksyms_64.c
* Updated and tidied commit message.
* Rebased patch over sparc-2.6.git HEAD.
* Ensured that all modified files have the correct includes.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move all applicable EXPORT_SYMBOL()s to the file where the respective
symbol is defined.

Removed all the includes that are no longer needed in sparc_ksyms_32.c

Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_32.c

Two symbols are shared with sparc64 thus the exports were removed from
the sparc_ksyms_64.c too, along with the include their ommission made
redundant.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Additions by Julian Calaby:
* Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
* Made some minor cleanups to the includes and comments of sparc_ksyms_32.c
* Made another subtraction from sparc_ksyms_64.c
* Updated and tidied commit message.
* Rebased patch over sparc-2.6.git HEAD.
* Ensured that all modified files have the correct includes.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sparc: Create a new file lib/ksyms.c and add export of all symbols defined in assembler in lib/ to this file.

Remove the duplicate entries from kernel/sparc_ksyms_*.c

The rationale behind this is that the EXPORT_SYMBOL() should be close to
their definition and we cannot add designate a symbol to be exported in
assembler so at least put it in a file in the same directory.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Additions by Julian Calaby:
* Rebased over sparc-2.6.git HEAD
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

arch/sparc/kernel/unaligned_64.c: In function 'handle_lddfmna':
arch/sparc/kernel/unaligned_64.c:592: warning: 'second' may be used uninitialized in this function
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reported by Robert Reif.

Fallout from 'swap' changes.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After conversion to use unsigned long long for u64
I saw following warnings:

  CC      arch/sparc/kernel/psycho_common.o
arch/sparc/kernel/psycho_common.c: In function `psycho_check_stc_error':
arch/sparc/kernel/psycho_common.c:104: warning: long long unsigned int format, long unsigned int arg (arg 4)
arch/sparc/kernel/psycho_common.c:104: warning: long long unsigned int format, long unsigned int arg (arg 5)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 4)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 5)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 6)
arch/sparc/kernel/psycho_common.c:114: warning: long long unsigned int format, long unsigned int arg (arg 7)
arch/sparc/kernel/psycho_common.c: In function `psycho_dump_iommu_tags_and_data':
arch/sparc/kernel/psycho_common.c:187: warning: long long unsigned int format, long unsigned int arg (arg 8)
arch/sparc/kernel/psycho_common.c:193: warning: long long unsigned int format, long unsigned int arg (arg 6)
arch/sparc/kernel/psycho_common.c: In function `psycho_pcierr_intr':
arch/sparc/kernel/psycho_common.c:333: warning: long long unsigned int format, long unsigned int arg (arg 3)
arch/sparc/kernel/psycho_common.c:333: warning: long long unsigned int format, long unsigned int arg (arg 4)

This is due to different integer promotion in my 32 bit hosted gcc.
The fix is to force a few constants to ULL.

The following stands out from the rest:
+#define  PSYCHO_IOMMU_TAG_VPAGE         0x7ffffULL
+#define  PSYCHO_IOMMU_DATA_PPAGE 0xfffffffULL

They were needed otherwise the expression:

    (data_val & PSYCHO_IOMMU_DATA_PPAGE) << IOMMU_PAGE_SHIFT)

were promoted to a unsigned long and not a unsigned long long as expected.

I tried the alternative solution and made IOMMU_PAGE_SHIFT an ULL but that did not help.
The only way gcc would make this expression an unsigned long long was to
define PSYCHO_IOMMU_DATA_PPAGE as ULL. The alternative to add a cast was
not considered a valid solution.

We had this issue in two places and this were the only places the above
two constants are used.

A small coding style diff sneaked in too. 
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In preparation for the introduction of a generic swap() macro.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As reported by Sam Ravnborg, Gcc-3.4.5 does not handle:

	if (get_user() || get_user())

with the new branch tracer enabled.

Just seperate it out into seperate statements for now
so people can get work done.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Andrew Morton wrote:

    People keep on doing

            printk("%llu", some_u64);

    testing it only on x86_64 and this generates a warning storm on
    powerpc, sparc64, etc.  Because they use `long', not `long long'.

    Quite a few 64-bit architectures are using `long' for their
    s64/u64 types.  We should convert them all to `long long'.

Update types.h so we use unsigned long long for u64 and
fix all warnings in sparc64 code.
Tested with an allnoconfig, defconfig and allmodconfig builds.

This patch introduces additional warnings in several drivers.
These will be dealt with in separate patches.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The sparc64 allmodconfig build broke due to enabling of the
branch_tracer that does some very clever things with
all if conditions. This caused my gcc 3.4.5 to be so confused that
it emitted a warning:

arch/sparc/kernel/viohs.c: In function `vio_control_pkt_engine':
arch/sparc/kernel/viohs.c:335: warning: 'nver' might be used uninitialized in this function

And with -Werror this broke the build.

Refactor code so it:
1) becomes more readable
2) no longer emit a warning with the branch_tracer enabled
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Impact: clean up

The code in process_ver_nack is a little obfuscated. This change
makes it a bit more readable by humans. It removes the complex
if statement and replaces it with a cleaner flow of control.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- (better, more, bigger ...) then -> (...) than
Signed-off-by: NFrederik Schwarzer <schwarzerf@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When CONFIG_PROC_FS is unset, include/linux/interrupt.h defines
init_irq_proc() as an empty function.

arch/sparc/kernel/irq_32.c defines this function unconditionally.

Fix the latter so that it only defines this function when CONFIG_PROC_FS
is set.

This fixes the following error:
arch/sparc/kernel/irq_32.c:672: error: redefinition of 'init_irq_proc'
include/linux/interrupt.h:461: error: previous definition of
'init_irq_proc' was here

This was found using randconfig builds.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

prom_nextprop() and prom_firstprop() have slightly different calling
conventions in 32 and 64 bit SPARC.

prom_common.c uses a ifdef guard to ensure that these functions are
called correctly.

Adjust code to eliminate this ifdef by using a calling convention that
is compatible with both 32 and 64 bit SPARC.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Renaming a few types to contain a 32 suffix makes the
type names compatible with sparc64 and thus makes sharing
between the two a lot easier.

Note: None of these definitions are expected part of the
stable ABI towards userspace.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed by Geert Uytterhoeven.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>