linux-toradex.git/kernel/irq/resend.c, branch v4.2.7

genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD

2015-07-17T09:29:34+00:00

The resend mechanism happily calls the interrupt handler of interrupts
which are marked IRQ_NESTED_THREAD from softirq context. This can
result in crashes because the interrupt handler is not the proper way
to invoke the device handlers. They must be invoked via
handle_nested_irq.

Prevent the resend even if the interrupt has no valid parent irq
set. Its better to have a lost interrupt than a crashing machine.

Reported-by: Uwe Kleine-König 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org

genirq: Provide means to retrigger parent

2012-11-01T11:11:31+00:00

Attempts to retrigger nested threaded IRQs currently fail because they
have no primary handler. In order to support retrigger of nested
IRQs, the parent IRQ needs to be retriggered.

To fix, when an IRQ needs to be resent, if the interrupt has a parent
IRQ and runs in the context of the parent IRQ, then resend the parent.

Also, handle_nested_irq() needs to clear the replay flag like the
other handlers, otherwise check_irq_resend() will set it and it will
never be cleared.  Without clearing, it results in the first resend
working fine, but check_irq_resend() returning early on subsequent
resends because the replay flag is still set.

Problem discovered on ARM/OMAP platforms where a nested IRQ that's
also a wakeup IRQ happens late in suspend and needed to be retriggered
during the resume process.

[khilman@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]

Reported-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1350425269-11489-1-git-send-email-khilman@deeprootsystems.com
Signed-off-by: Thomas Gleixner

genirq: Allow check_wakeup_irqs to notice level-triggered interrupts

2012-05-04T21:38:50+00:00

Level triggered interrupts do not cause IRQS_PENDING to be set when
they fire while "disabled" as the 'pending' state is always present in
the level - they automatically refire where re-enabled.

However the IRQS_PENDING flag is also used to abort a suspend cycle -
if any 'is_wakeup_set' interrupt is PENDING, check_wakeup_irqs() will
cause suspend to abort. Without IRQS_PENDING, suspend won't abort.

Consequently, level-triggered interrupts that fire during the 'noirq'
phase of suspend do not currently abort suspend.

So set IRQS_PENDING even for level triggered interrupts, and make sure
to clear the flag in check_irq_resend.

[ Changelog by courtesy of Neil ]

Tested-by: NeilBrown 
Signed-off-by: Thomas Gleixner

genirq: Remove compat code

2011-03-29T12:48:19+00:00

Signed-off-by: Thomas Gleixner

genirq: Mirror irq trigger type bits in irq_data.state

2011-02-19T11:58:20+00:00

That's the data structure chip functions get provided. Also allow them
to signal the core code that they updated the flags in irq_data.state
by returning IRQ_SET_MASK_OK_NOCOPY. The default is unchanged.

The type bits should be accessed via:

val = irqd_get_trigger_type(irqdata);
and
irqd_set_trigger_type(irqdata, val);

Coders who access them directly will be tracked down and slapped with
stinking trouts.

Signed-off-by: Thomas Gleixner

genirq: Move IRQ_PENDING flag to core

2011-02-19T11:58:17+00:00

Keep status in sync until all users are fixed.

Signed-off-by: Thomas Gleixner

genirq: Move IRQ_REPLAY and IRQ_WAITING to core

2011-02-19T11:58:16+00:00

No users outside of core.

Signed-off-by: Thomas Gleixner

genirq: Consolidate IRQ_DISABLED

2011-02-19T11:58:11+00:00

Handle IRQ_DISABLED consistent.

Signed-off-by: Thomas Gleixner

genirq: Consolidate disable/enable

2011-02-19T11:58:10+00:00

Create irq_disable/enable and use them to keep the flags consistent.

Signed-off-by: Thomas Gleixner

genirq: Prevent access beyond allocated_irqs bitmap

2011-02-19T11:10:51+00:00

Lars-Peter Clausen pointed out:

   I stumbled upon this while looking through the existing archs using
   SPARSE_IRQ.  Even with SPARSE_IRQ the NR_IRQS is still the upper
   limit for the number of IRQs.

   Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with
   IRQ_BOARD_START being the number of IRQs used by the core.

   In various machine files the nr_irqs field of the ARM machine
   defintion struct is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".

   As a result "nr_irqs" will greater then NR_IRQS which then again
   causes the "allocated_irqs" bitmap in the core irq code to be
   accessed beyond its size overwriting unrelated data.

The core code really misses a sanity check there.

This went unnoticed so far as by chance the compiler/linker places
data behind that bitmap which gets initialized later on those affected
platforms.

So the obvious fix would be to add a sanity check in early_irq_init()
and break all affected platforms. Though that check wants to be
backported to stable as well, which will require to fix all known
problematic platforms and probably some more yet not known ones as
well. Lots of churn.

A way simpler solution is to allocate a slightly larger bitmap and
avoid the whole churn w/o breaking anything. Add a few warnings when
an arch returns utter crap.

Reported-by: Lars-Peter Clausen 
Signed-off-by: Thomas Gleixner 
Cc: stable@kernel.org # .37
Cc: Haojian Zhuang 
Cc: Eric Miao 
Cc: Peter Zijlstra