Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()

Arjan van de Ven
2006-06-04T09:34:25Z

On Sat, 2006-06-03 at 18:34 -0400, Steven Rostedt wrote:
> On Sat, 2006-06-03 at 17:53 -0400, Alan Cox wrote:
> > On Sat, Jun 03, 2006 at 10:37:01AM -0400, Steven Rostedt wrote:
> > > Couldn't it be possible to have the misrouted irq function mark the
> > > DISABLED_IRQ handlers as IRQ_PENDING? Then have the enable_irq that
> > > actually enables the irq to call the handlers with interrupts disabled
> > > if the IRQ_PENDING is set?
> >
> > We still have the ambiguity with disable_irq. Really we need to have
> > disable_irq_handler(irq, handler)
>
> Yeah, that does make sense, but I think the IRQ_PENDING idea works too.
> This way disable_irq_handler doesn't need to mask the interrupt even
> without the irqpoll and irqfixup. Let the interrupt happen and just
> skip those handlers that that are disabled. Then when the handler is
> re-enabled, then we can call the handler. Of course we would need a
> enable_irq_handler too.
>
> This would make the vortex card's disable_irq not hurt all the other
> devices that share the irq with it.
can't do that; if you get an irq anyway from the hardware you now have a
screamer...... which is why vortex really needs to disable the irq at
the hardware level.