Re: [patch 3/5] MIPS: Octeon: Simplify irq_cpu_on/offline irq chip functions

[David Daney <david.s.daney@gmail.com>]

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