Messages in this thread | | | Subject | Re: probe_irq_{on,off} | Date | Sun, 23 Aug 1998 12:30:41 +0100 | From | Philip Blundell <> |
| |
>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
| |