Cast to (void *) in request_irq() argument is stupid and
only hides problems...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

missed irq handler in sys_titan and forgotten prototype update.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

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

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

We should pass "wait_event_interruptible()" the wait-queue itself, not
the pointer to it. The magic macro will pointerize it internally.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] Cleanup unnecessary <asm/ptrace.h> inclusions.
  [MIPS] DEC: pt_regs fixes for buserror handlers
  [MIPS] Fix return type of gt64120_irq.
  [MIPS] Ocelot C: Build fix - ll_mv64340_irq takes no more regs argument.
  [MIPS] Jazz defconfig file.
  [MIPS] Jazz: build fix - include <linux/screen_info.h>
  [MIPS] Jazz: Remove warning.  After 7 years probably somebody test this ;)
  [MIPS] Jazz: Fix I/O port resources.
  [MIPS] DEC: pt_regs fixes for dec_intr_halt.
  handle_sysrq lost its pt_regs * argument

Manual conflict resolved in arch/um/drivers/mconsole_kern.c

Real fix for UML pt_regs stuff.  Note set_irq_regs() logics in there...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

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

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

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

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

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

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

struct resource members were shuffeled a while ago.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

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

This reverts commit 41550c51.

Quoth Ben Herrenschmidt:
 "Please revert this one for now.  It seems to break G5s :( Looks like
  PCI cells inside Apple IO ASICs don't have a PCI_INTERRUPT_LINE set.
  I need to figure out a better fix."
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Commit ca4aa096 fixed waiting for the
structure to get initialised, but it is also possible to break out of
the loop while still in TASK_INTERRUPTIBLE.

Replace the whole thing by wait_event_interruptible, which is much more
readable, and doesn't suffer from these problems.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

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

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

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

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

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

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

titan_dispatch_irqs() always gets get_irq_regs() as argument; kill
the argument and collapse set_irq_regs() in body.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

do set_irq_regs() in caller, kill pt_regs argument.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

isa_no_iack_sc_device_interrupt() always gets get_irq_regs() as
argument; kill that argument.

All but two callers of handle_irq() pass get_irq_regs() as argument;
convert the remaining two, kill set_irq_regs() inside handle_irq().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

callers of ->device_interrupt() do set_irq_regs() now; pt_regs argument
removed, remaining uses of regs in instances of ->device_interrupt()
are switched to get_irq_regs() and will be gone in the next patch.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fallout from previous patch:
 - actually add include/asm-m68k/irq_regs.h
 - missed the prototype of sun3_sched_init()

NB: git diff without argumentgs sucks when you've added
some files...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

read_trylock() is broken on sparc32 (doesn't build and didn't work
right, actually).  Proposed fix:

 - make "writer holds lock" distinguishable from "reader tries to grab
   lock"

 - have __raw_read_trylock() try to acquire the mutex (in LSB of lock),
   terminating spin if we see that there's writer holding it.  Then do
   the rest as we do in read_lock().

Thanks to Ingo for discussion...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

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

Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  ieee1394: nodemgr: fix startup of knodemgrd

* 'irq-fixes' of git://git.parisc-linux.org/git/linux-2.6:
  [PARISC] More pt_regs removal
  [PARISC] pdc_init no longer exists
  [PARISC] Make firmware calls irqsafe-ish...
  [PA-RISC] Fix boot breakage
  [PARISC] Use set_irq_regs

The problem we can't take advantage of lowest priority delivery mode if
the vectors are allocated for only one cpu at a time.  Nor can we work
around hardware that assumes lowest priority delivery mode is always
used with several cpus.

So this patch introduces the concept of a vector_allocation_domain.  A
set of cpus that will receive an irq on the same vector.  Currently the
code for implementing this is placed in the genapic structure so we can
vary this depending on how we are using the io_apics.

This allows us to restore the previous behaviour of genapic_flat without
removing the benefits of having separate vector allocation for large
machines.

This should also fix the problem report where a hyperthreaded cpu was
receving the irq on the wrong hyperthread when in logical delivery mode
because the previous behaviour is restored.

This patch properly records our allocation of the first 16 irqs to the
first 16 available vectors on all cpus.  This should be fine but it may
run into problems with multiple interrupts at the same interrupt level.
Except for some badly maintained comments in the code and the behaviour
of the interrupt allocator I have no real understanding of that problem.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Acked-by: NMuli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Which vector an irq is assigned to now varies dynamically and is
not needed outside of io_apic.c.  So remove the possibility
of accessing the information outside of io_apic.c and remove
the silly macro that makes looking for users of irq_vector
difficult.

The fact this compiles ensures there aren't any more pieces
of the old CONFIG_PCI_MSI weirdness that I failed to remove.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In commit ace80ab7 I removed the weird
logic that used the vector number as the irq number when MSI was
defined.  However pci_enable_irq was using a different test in the
io_apic_assign_irqs path and I missed it :(

This patch removes the wrong code so no one hits this problem.

This code is only active when a specific set of boot command line
parameters is specified which likely explains why no one has notices
this earlier.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>