On 03/27/2011 02:41 PM, Thomas Gleixner wrote:
On Sun, 27 Mar 2011, Thomas Gleixner wrote:
On Sun, 27 Mar 2011, David Daney wrote:
On 03/27/2011 09:22 AM, Thomas Gleixner wrote:
Make use of the IRQCHIP_ONOFFLINE_ENABLED flag and remove the
wrappers. Use irqd_irq_disabled() instead of desc->status, which will
go away.
I rewrote my patch set and was testing it. Interesting that I came up with a
function with almost the same name and purpose.
However my function told us if the irq was masked *or* disabled. The idea
being a function that returns true if the irq could fire. We cannot be
enabling the interrupt in the controller if it is masked.
For example I need to test this when adjusting affinity, and taking CPUs on
and off line.
I don't think your genirq changes can tell the me information I really need in
their current state. I think we need to consider how the masked state
interacts with IRQCHIP_ONOFFLINE_ENABLED and irqd_irq_disabled().
So you want to know whether the core code masked the interrupt or
not. In your case that's equivivalent to the irqd_irq_disabled check
simply because you provide a irq_disable() callback which prevents the
lazy disable mechanism.
CPU1 CPU2
handle_edge_irq()
handle_irq_event()
.
.
.
enable_interrupts
.
handle_edge_irq()
mask
set_affinity()
enable
the irq on some CPU1.
interrupt fires again (incorrectly)
In my set affinity code I want to know if it is masked, so I don't
inadvertently re-enable it.
David Daney
