linux-toradex.git/kernel/irq, branch v2.6.36-rc7

irq: Add new IRQ flag IRQF_NO_SUSPEND

2010-07-29T11:24:57+00:00

A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not timer interrupts.

Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
__IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.

Signed-off-by: Ian Campbell 
Cc: Jeremy Fitzhardinge 
Cc: Dmitry Torokhov 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Grant Likely 
Cc: xen-devel@lists.xensource.com
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner

genirq: Deal with desc->set_type() changing desc->chip

2010-06-09T15:05:08+00:00

The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq. 

The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.

The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.

But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.

It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.

Reported-by: Esben Haabendal 
Signed-off-by: Thomas Gleixner 
Cc: Benjamin Herrenschmidt 
Cc: linuxppc-dev 
Cc: stable@kernel.org

genirq: Clear CPU mask in affinity_hint when none is provided

2010-05-12T09:23:34+00:00

When an interrupt is disabled and torn down, the CPU mask returned
through affinity_hint right now is all CPUs. Also, for drivers that
don't provide an affinity_hint mask, this can be misleading. There
should be no hint at all, meaning an empty CPU mask.

[ tglx: use zalloc_cpumask_var instead of clearing it under the lock ]

Signed-off-by: Peter P Waskiewicz Jr 
Cc: davem@davemloft.net
Cc: arjan@linux.jf.intel.com
Cc: bhutchings@solarflare.com
LKML-Reference: <20100505205638.5426.87189.stgit@ppwaskie-hc2.jf.intel.com>
Signed-off-by: Thomas Gleixner

genirq: Add CPU mask affinity hint

2010-05-03T09:50:57+00:00

This patch adds a cpumask affinity hint to the irq_desc structure,
along with a registration function and a read-only proc entry for each
interrupt.

This affinity_hint handle for each interrupt can be used by underlying
drivers that need a better mechanism to control interrupt affinity.
The underlying driver can register a cpumask for the interrupt, which
will allow the driver to provide the CPU mask for the interrupt to
anything that requests it.  The intent is to extend the userspace
daemon, irqbalance, to help hint to it a preferred CPU mask to balance
the interrupt into.

[ tglx: Fixed compile warnings, added WARN_ON, made SMP only ]

Signed-off-by: Peter P Waskiewicz Jr 
Cc: davem@davemloft.net
Cc: arjan@linux.jf.intel.com
Cc: bhutchings@solarflare.com
LKML-Reference: <20100430214445.3992.41647.stgit@ppwaskie-hc2.jf.intel.com>
Signed-off-by: Thomas Gleixner

genirq: Remove IRQF_DISABLED from core code

2010-04-13T14:36:40+00:00

Remove all code which is related to IRQF_DISABLED from the core kernel
code. IRQF_DISABLED still exists as a flag, but becomes a NOOP and
will be removed after a grace period. That way we can easily revert to
the previous behaviour by just restoring the core code.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Alan Cox 
Cc: Andi Kleen 
Cc: David Miller 
Cc: Greg Kroah-Hartman 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
LKML-Reference: <20100326000405.991244690@linutronix.de>

genirq: Run irq handlers with interrupts disabled

2010-04-13T14:36:40+00:00

Running interrupt handlers with interrupts enabled can cause stack
overflows. That has been observed with multiqueue NICs delivering all
their interrupts to a single core. We might band aid that somehow by
checking the interrupt stacks, but the real safe fix is to run the irq
handlers with interrupts disabled.

Drivers for whacky hardware still can reenable them in the handler
itself, if the need arises. (They do already due to lockdep)

The risk of doing this is rather low:

 - lockdep already enforces this
 - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
 - time keeping is not longer sensitive to the timer interrupt being delayed

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Alan Cox 
Cc: Andi Kleen 
Cc: David Miller 
Cc: Greg Kroah-Hartman 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
LKML-Reference: <20100326000405.758579387@linutronix.de>

genirq: Introduce request_any_context_irq()

2010-04-13T14:36:39+00:00

Now that we enjoy threaded interrupts, we're starting to see irq_chip
implementations (wm831x, pca953x) that make use of threaded interrupts
for the controller, and nested interrupts for the client interrupt. It
all works very well, with one drawback:

Drivers requesting an IRQ must now know whether the handler will
run in a thread context or not, and call request_threaded_irq() or
request_irq() accordingly.

The problem is that the requesting driver sometimes doesn't know
about the nature of the interrupt, specially when the interrupt
controller is a discrete chip (typically a GPIO expander connected
over I2C) that can be connected to a wide variety of otherwise perfectly
supported hardware.

This patch introduces the request_any_context_irq() function that mostly
mimics the usual request_irq(), except that it checks whether the irq
level is configured as nested or not, and calls the right backend.
On success, it also returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED.

[ tglx: Made return value an enum, simplified code and made the export
  	of request_any_context_irq GPL ]

Signed-off-by: Marc Zyngier 
Cc: 
LKML-Reference: <927ea285bd0c68934ddae1a47e44a9ba@localhost>
Signed-off-by: Thomas Gleixner

Merge branch 'linus' into irq/core

2010-04-13T12:12:17+00:00

Reason: Get the upstream IRQF_DISABLED related changes.

Signed-off-by: Thomas Gleixner

Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2010-04-06T20:03:22+00:00

* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  genirq: Force MSI irq handlers to run with interrupts disabled

genirq: Force MSI irq handlers to run with interrupts disabled

2010-03-31T13:48:38+00:00

Network folks reported that directing all MSI-X vectors of their multi
queue NICs to a single core can cause interrupt stack overflows when
enough interrupts fire at the same time.

This is caused by the fact that we run interrupt handlers by default
with interrupts enabled unless the driver reuqests the interrupt with
the IRQF_DISABLED set. The NIC handlers do not set this flag, so
simultaneous interrupts can nest unlimited and cause the stack
overflow.

The only safe counter measure is to run the interrupt handlers with
interrupts disabled. We can't switch to this mode in general right
now, but it is safe to do so for MSI interrupts.

Force IRQF_DISABLED for MSI interrupt handlers.

Signed-off-by: Thomas Gleixner 
Cc: Andi Kleen 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Alan Cox 
Cc: David Miller 
Cc: Greg Kroah-Hartman 
Cc: Arnaldo Carvalho de Melo 
Cc: stable@kernel.org