Messages in this thread | | | From | Russell King <> | Subject | probe_irq_{on,off} | Date | Sun, 23 Aug 1998 11:27:12 +0100 (BST) |
| |
Hi All,
First of all, I'm not subscribed to linux-kernel, so please CC: your replies to me.
I've been looking at the probe_irq_{on,off} interface recently wrt mainly the ARM architecture, but the other architectures as well, and have come to the conclusion that the interface is not as clean as it ought to be. I have a question and a proposal:
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).
2. probe_irq_off() is expected to return the following values: 0 - no interrupt detected -irq - first interrupt detected, but others were triggered +irq - single interrupt detected
Looking at the driver code, it seems that:
1) All drivers that use probe_irq_off() detect failure by checking for <= 0 from this routine.
2) Drivers that use autoirq_report detect failure by checking for 0. (auto_irq return value is the same as probe_irq_off().
This leads me to two things:
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).
2) The general case is that all drivers assume a return value of <= 0 is a failed probe.
3) The use of '0'. Originally, when Linux was not portable, interrupt '0' was (and still is) the timer interrupt. Since this interrupt is always in use, it can never be probed, so on i386, it's safe.
However, on other architectures, this may not be the case. For instance, on one of the ARM architectures, interrupt 0 is the parallel port interrupt. The new parport attempts to probe it's interrupt and fails because of this assumption that interrupt '0' is not a valid interrupt.
Ok, problem highlighted. Now the fixes:
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.
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:
int probe_irq_off(unsigned long irqs, unsigned int *probed_irq) { ... *probed_irq = irq_found;
return failure; }
Obviously, this can only go into Kernel 2.3.
Comments anyone (but please remember to CC: me)? _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk@arm.uk.linux.org --- --- | | | | http://www.arm.uk.linux.org/~rmk/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ |
- 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
| |