Re: probe_irq_{on,off}

Philip Blundell (philb@gnu.org)
Sun, 23 Aug 1998 12:30:41 +0100


>1. Currently, probe_irq_on() returns a mask of interrupts currently
> enabled for a probe. This is then passed to probe_irq_off(),
> to identify which IRQ has been triggered.
>
> Does this information have to be passed this way, or can the
> architecture IRQ code keep a mask? (eg, if you have 64 or more
> interrupts/sparse interrupt numbers etc).

Since it doesn't make any sense to have two probes active concurrently, it
seems to me that it's probably OK for the architecture to store a mask.

> 1) Drivers using autoirq_report have a horrible bug in them
> that can lead to -ve interrupt numbers being requested
> (but that request_irq will trap).

The way to fix that one is just to kill auto_irq.c altogether and fix the
drivers to use the probe_irq interface instead.

>I propose introducing a new kernel macro, NO_IRQ, to contain an
>architecture defined value which can be used in drivers and
>probe_irq_off() to indicate either failure or no interrupt.

That sounds reasonable. Updating all the drivers is going to be a pain but it
shouldn't be particularly difficult, just tedious.

>The return method for probe_irq_off() could be changed as well,
>such that it returns either success/failure, and returns the
>probed interrupt number via a pointer thus:

Given the above I don't really see what this buys us.

p.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html