Re: [PATCH 0/5] ARM: at91: fix irq_pm_install_action WARNING

[Thomas Gleixner]

On Tue, 16 Dec 2014, Boris Brezillon wrote:
> On Tue, 16 Dec 2014 11:03:55 +0100 (CET)
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > That avoids the whole flag, action, whatever business for the price of
> > a really trivial demux mechanism. Everything just works. Even the irq
> > storm detector will just disable the parent interrupt once all
> > handlers return NONE often enough.
> 
> Still have one question regarding the spurious interrupt detection code.
> AFAIU, it disables a specific IRQ handler if it triggers to often with
> an IRQ_NONE return, right ?
> 
> In this dumb demuxer I can't tell which child interrupt should be
> handled (there is no interrupt cause register), thus I call
> generic_handle_irq on all unmasked IRQs.
> Isn't there a risk to get some of my child interrupts disabled because
> they always return IRQ_NONE (which is a normal use case for
> IRQF_SHARED: we're only expecting at least one handler to return
> IRQ_HANDLED or IRQ_WAKE_THREAD, not all of them) ?

Good point. I missed that aspect.

Another good reason to make that core infrastructure.

So what you need is the following:

void dumb_demux_handler(....)
{
	irq_return ret = IRQ_NONE:
	int i;

	for_each_demux_irq(i)
		ret |= handle_dumb_demux_irq(base + i);

	note_interrupt(demuxirq, ret);
}   

So that disables the demux irq if all sub handlers return NONE 100k
times in a row. Otherwise if one of them handles it, you're fine.

That more or less resembles the shared action magic.

So yes, that wants to be core functionality which can be instantiated
from an affected irq chip for this particular case of HW insanity.

Thanks,

	tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/