[parisc-linux-cvs] linux-2.6 willy

[Grant Grundler]

On Sun, Jan 02, 2005 at 08:19:34PM +0000, Matthew Wilcox wrote:
> > IMHO - this is wrong by design. It means one driver can mess
> > with the behavior of another driver. e.g. shutting down one NIC
> > could disable the interrupt for another NIC.
> 
> Well, that's the disadvantage of sharing interrupts -- disabling the
> interrupt prevents other drivers receiving the interrupt if it's for them.
> I don't see a way around this -- if you just disable the interrupt handler
> for this card, you might get a screaming interrupt.
> In the case of shutting down a card, the driver should stop the card
> from generating interrupts.  If it doesn't, it's buggy.

Yes - I agree. unhandled interrupts are less of a problem (in general) than
having to nest disable/enable calls and have drivers interfer with
each other. While the former is a nasty problem, it's alot easier
to debug/diagnose.

> If you see this as a real problem, I encourage you to fix the generic IRQ
> code ... that way it'll benefit x86, ia64 and (soon) parisc.  It'd even
> count as an Assigned Task, right?  ;-)

Let me think about how I might "sell" this change upstream.

Most HP HW does NOT share IRQ lines.
It would be a stretch to call it an Assigned Task.

> If you're sharing an interrupt between two devices, each device driver
> can call disable_irq() on the same interrupt.  The interrup shouldn't
> be re-enabled until both drivers have called enable_irq().

Agreed - I was thinking if only the handler was disabled for a shared IRQ.

> Sure.  For the moment, I'm just making them look similar.  That's an
> advantage all by itself, even if we never end up merging them.

ok. BIOS differences (ie acquisition and format of IRQ routing table)
will probably be the last ugly bit to reconcile.

grant