linux-stable.git/include/linux/irq.h, branch v3.15.4

genirq: x86: Ensure that dynamic irq allocation does not conflict

2014-04-28T10:20:00+00:00

On x86 the allocation of irq descriptors may allocate interrupts which
are in the range of the GSI interrupts. That's wrong as those
interrupts are hardwired and we don't have the irq domain translation
like PPC. So one of these interrupts can be hooked up later to one of
the devices which are hard wired to it and the io_apic init code for
that particular interrupt line happily reuses that descriptor with a
completely different configuration so hell breaks lose.

Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
except for a few usage sites which have not yet blown up in our face
for whatever reason. But for drivers which need an irq range, like the
GPIO drivers, we have no limit in place and we don't want to expose
such a detail to a driver.

To cure this introduce a function which an architecture can implement
to impose a lower bound on the dynamic interrupt allocations.

Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
the end of the hardwired interrupt space, so all dynamic allocations
happen above.

That not only allows the GPIO driver to work sanely, it also protects
the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
htirq code. They need to be cleaned up as well, but that's a separate
issue.

Reported-by: Jin Yao 
Signed-off-by: Thomas Gleixner 
Tested-by: Mika Westerberg 
Cc: Mathias Nyman 
Cc: Linus Torvalds 
Cc: Grant Likely 
Cc: H. Peter Anvin 
Cc: Rafael J. Wysocki 
Cc: Andy Shevchenko 
Cc: Krogerus Heikki 
Cc: Linus Walleij 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner

genirq: Allow forcing cpu affinity of interrupts

2014-04-17T21:36:27+00:00

The current implementation of irq_set_affinity() refuses rightfully to
route an interrupt to an offline cpu.

But there is a special case, where this is actually desired. Some of
the ARM SoCs have per cpu timers which require setting the affinity
during cpu startup where the cpu is not yet in the online mask.

If we can't do that, then the local timer interrupt for the about to
become online cpu is routed to some random online cpu.

The developers of the affected machines tried to work around that
issue, but that results in a massive mess in that timer code.

We have a yet unused argument in the set_affinity callbacks of the irq
chips, which I added back then for a similar reason. It was never
required so it got not used. But I'm happy that I never removed it.

That allows us to implement a sane handling of the above scenario. So
the affected SoC drivers can add the required force handling to their
interrupt chip, switch the timer code to irq_force_affinity() and
things just work.

This does not affect any existing user of irq_set_affinity().

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Reported-and-tested-by: Krzysztof Kozlowski 
Signed-off-by: Thomas Gleixner 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tomasz Figa ,
Cc: Daniel Lezcano ,
Cc: Kukjin Kim 
Cc: linux-arm-kernel@lists.infradead.org,
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.de
Signed-off-by: Thomas Gleixner

genirq: Add a new IRQCHIP_EOI_THREADED flag

2014-03-14T12:43:33+00:00

The flag is necessary for interrupt chips which require an ACK/EOI
after the handler has run. In case of threaded handlers this needs to
happen after the threaded handler has completed before the unmask of
the interrupt.

The flag is only unseful in combination with the handle_fasteoi_irq
flow control handler.

It can be combined with the flag IRQCHIP_EOI_IF_HANDLED, so the EOI is
not issued when the interrupt is disabled or in progress.

Tested-by: Hans de Goede 
Reviewed-by: Hans de Goede 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-sunxi@googlegroups.com
Cc: Maxime Ripard 
Link: http://lkml.kernel.org/r/1394733834-26839-2-git-send-email-hdegoede@redhat.com
Signed-off-by: Thomas Gleixner

genirq: Document IRQCHIP_ONESHOT_SAFE flag

2014-03-14T12:43:33+00:00

Add missing documentation of the flag.

Signed-off-by: Thomas Gleixner

genirq: Provide irq_request/release_resources chip callbacks

2014-03-12T15:00:24+00:00

For certain irq types, e.g. gpios, it's necessary to request resources
before starting up the irq.

This might fail so we cannot use the irq_startup() callback because we
might call the irq_set_type() callback before that which does not make
sense when the resource is not available. Calling irq_startup() before
irq_set_type() can lead to spurious interrupts which is not desired
either.

Signed-off-by: Thomas Gleixner 
Cc: Jean-Jacques Hiblot 
Cc: Grant Likely 
Cc: linux-arm-kernel@lists.infradead.org 
Reviewed-by: Linus Walleij 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1403080857160.18573@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner

genirq: Prevent spurious detection for unconditionally polled interrupts

2013-11-13T15:03:02+00:00

On a 68k platform a couple of interrupts are demultiplexed and
"polled" from a top level interrupt. Unfortunately there is no way to
determine which of the sub interrupts raised the top level interrupt,
so all of the demultiplexed interrupt handlers need to be
invoked. Given a high enough frequency this can trigger the spurious
interrupt detection mechanism, if one of the demultiplex interrupts
returns IRQ_NONE continuously. But this is a false positive as the
polling causes this behaviour and not buggy hardware/software.

Introduce IRQ_POLLED which can be set at interrupt chip setup time via
irq_set_status_flags(). The flag excludes the interrupt from the
spurious detector and from all core polling activities.

Reported-and-tested-by: Michael Schmitz 
Cc: Geert Uytterhoeven 
Cc: linux-m68k@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311061149250.23353@ionos.tec.linutronix.de

Remove GENERIC_HARDIRQ config option

2013-09-13T13:09:52+00:00

After the last architecture switched to generic hard irqs the config
options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
for !CONFIG_GENERIC_HARDIRQS can be removed.

Signed-off-by: Martin Schwidefsky

genirq: Add irq_get_trigger_type() to get IRQ flags

2013-06-25T09:48:24+00:00

Drivers that want to get the trigger edge/level type flags for a given
interrupt have to call irq_get_irq_data(irq) to get the struct
irq_data and then irqd_get_trigger_type(irq_data) to obtain the IRQ
flags.

This is not only error prone but also unnecessary exposes the struct
irq_data to callers.

It's better to have an irq_get_trigger_type() function to obtain the
edge/level flags for an IRQ.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Grant Likely 
Cc: Linus Walleij 
Cc: Samuel Ortiz 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Link: http://lkml.kernel.org/r/1371228049-27080-2-git-send-email-javier.martinez@collabora.co.uk
Signed-off-by: Thomas Gleixner

genirq: irqchip: Add mask to block out invalid irqs

2013-05-29T08:57:11+00:00

Some controllers have irqs that aren't wired up and must never be used.
For the generic chip attached to an irq_domain this provides a mask that
can be used to block out particular irqs so that they never get mapped.

Signed-off-by: Grant Likely 
Link: http://lkml.kernel.org/r/1369793454-19197-2-git-send-email-grant.likely@linaro.org
Signed-off-by: Thomas Gleixner

genirq: Generic chip: Add linear irq domain support

2013-05-29T08:57:11+00:00

Provide infrastructure for irq chip implementations which work on
linear irq domains.

- Interface to allocate multiple generic chips which are associated to
  the irq domain.

- Interface to get the generic chip pointer for a particular hardware
  interrupt in the domain.

- irq domain mapping function to install the chip for a particular
  interrupt.

Note: This lacks a removal function for now.

[ Sebastian Hesselbarth: Mask cache and pointer math fixups ]

Signed-off-by: Thomas Gleixner 
Cc: Thomas Petazzoni 
Cc: Andrew Lunn 
Cc: Russell King - ARM Linux 
Cc: Jason Cooper 
Cc: Arnd Bergmann 
Cc: Jean-Francois Moine 
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Rob Herring 
Cc: Jason Gunthorpe 
Cc: Gregory Clement 
Cc: Gerlando Falauto 
Cc: Rob Landley 
Acked-by: Grant Likely 
Cc: Maxime Ripard 
Cc: Ezequiel Garcia 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Sebastian Hesselbarth 
Link: http://lkml.kernel.org/r/20130506142539.450634298@linutronix.de
Signed-off-by: Thomas Gleixner