[parisc-linux-cvs] linux-2.6 willy

[Grant Grundler]

On Mon, Jan 03, 2005 at 10:35:19AM -0600, James Bottomley wrote:
> I didn't say we don't call all handlers for an irq.  What I do assert is
> that on our first unhandled interrupt, the line remains asserted and now
> all interrupts from the other cards are lost because we have no choice
> but to shut the line down to allow the machine to make forward progress.

We do have more choices:
o We can irritate the user with dmesg output that indicates buggy HW
o we can poll the remaining handlers for that IRQ to guarantee forward progress.

"we" above means the generic interrupt support.

> Perhaps I should clarify what disable_irq() is actually for:  you only
> call it from your interrupt routine when you know you're taking a course
> of action which will lead to the interrupt you were trying to handle
> being still asserted. There's no case (except a driver bug) where we
> should be calling disable_irq() speculatively without the line asserted.

hrm...thanks for the clarification.
drivers/net has the lion's share of disable_irq() usage.
Looking at drivers, I see drivers/net/natsemi.c effectively uses
disable_irq()/spinlock() in place of spinlock_irqsave().
Maybe natsemi is a bad example? (or good example of abuse)

In drivers/scsi, the esp (NCR53c9x) drivers seem to use disable_irq()
like you describe. e.g. esp->dma_ints_off() usage in esp_intr() is
what I was looking at.

> So if we didn't shut the line down, it would loop with an unhandled
> interrupt and get shut down anyway.  That's why (2) is marginally better
> than (1).

Yes - that makes sense if one wants to keep the interrupt support simple
despite broken HW. And I'm not rabidly in favor of changing the current scheme.

thanks,
grant