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