Yeah, sorry. Any request_irq(SA_INTERRUPT|SA_SHIRQ) call will do this.
The problem is that when an SA_INTERRUPT handler shares with a
non-SA_INTERRUPT one, the result is basically meaningless. The SA_INTERRUPT
handler may (or may not) get executed with interrupts off.
So the intent was to drop a warning saying "hey, someone is being silly
here".
And it _is_ silly, because what the caller is saying is "I want my handler to
run with interrupts disabled, but I am also prepared to share the IRQ with
damn near any other interrupt handler in the kernel".
That warning has to go. My current thinking is as follows:
- Each time a handler is registered or removed from the chain, we walk the
IRQ chain and propogate some accumulated info into the controlling
irq_desc_t.
- If all handlers in the chain are SA_INTERRUPT then the entire chain is
run with irqs disabled.
- If _any_ handler is !SA_INTERRUPT then all handlers are run with IRQs
enabled.
This gives sane and documentable semantics. It also means that any
SA_INTERRUPT handler which is also SA_SHIRQ _must_ be prepared to be called
with irq's enabled. That is already the case: it is merely being formalised.
If a handler MUST be run with interrupts disabled (for atomicity reasons,
say) then it cannot share. That's the caller's responsibility.
(One might argue that if any handlers in the chain are SA_INTERRUPT then all
handlers should run with irq's off. Problem is, the !SA_INTERRUPT handlers
could easily be doing foo_lock_irq()/foo_unlock_irq(), because they think
they were called with irq's enabled).
It's all a bit murky.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/