The mainstream kernel offers a low-level facility for probing the interrupt number. The facility consists of two functions, declared in <linux/interrupt.h> (which also describes the probing machinery):

The programmer should be careful to enable the device after the call to probe_irq_on and to disable it before calling probe_irq_off. Additionally, you must remember to service the pending interrupt in your device, after probe_irq_off.

The short module demonstrates how to use such probing. If you load the module with probe=1, the following code is executed to detect your interrupt line, provided pins 9 and 10 of the parallel connector are bound together:

int count = 0;
do {
    unsigned long mask;

    mask = probe_irq_on();
    outb_p(0x10,short_base+2); /* enable reporting */
    outb_p(0x00,short_base);   /* clear the bit */
    outb_p(0xFF,short_base);   /* set the bit: interrupt! */
    outb_p(0x00,short_base+2); /* disable reporting */
    short_irq = probe_irq_off(mask);

    if (short_irq == 0) { /* none of them? */
        printk(KERN_INFO "short: no irq reported by probe
");
        short_irq = -1;
    }
    /*
     * if more than one line has been activated, the result is
     * negative. We should service the interrupt (no need for lpt port)
     * and loop over again. Loop at most five times, then give up
     */
} while (short_irq < 0 && count++ < 5);
if (short_irq < 0)
printk("short: probe failed %i times, giving up
", count);

Probing might be a lengthy task. While this is not true for short, probing a frame grabber, for example, requires a delay of at least 20ms (which is ages for the processor), and other devices might take even longer. Therefore, it’s best to probe for the interrupt line only once, at module initialization, independently of whether you install the handler at device open (as you should) or within init_module (which you shouldn’t do anyway).

It’s interesting to note that on the Sparc and M68k, probing is unnecessary and therefore isn’t implemented. Probing is a hack, and mature architectures are like PCI, which provides all the needed information. As a matter of fact, M68k and Sparc kernels export to the modules stub probing functions that always return 0--every architecture must define the functions, because they are exported by an architecture-independent source file. All the other supported architectures allow probing using the technique just shown.

The problem with probe_irq_on and probe_irq_off is that they are not exported by early kernel versions. Thus, if you want to write a module that ports back to 1.2, you must implement probing yourself.

Probing can be implemented in the driver itself without too much trouble. The short module performs do-it-yourself detection of the IRQ line if it is loaded with probe=2.

The mechanism is the same as the one described above: enable all unused interrupts, then wait and see what happens. We can, however, exploit our knowledge of the device. Often a device can be configured to use one IRQ number from a set of three or four; probing just those IRQs enables us to detect the right one, without having to test for all possible IRQs.

The short implementation assumes that 3, 5, 7, and 9 are the only possible IRQ values. These numbers are actually the values that some parallel devices allow you to select.

The code below probes by testing all ``possible'' interrupts and looking at what happens. The trials array lists the IRQs to try and has 0 as the end marker; the tried array is used to keep track of which handlers have actually been registered by this driver.

int trials[] = {3, 5, 7, 9, 0};
int tried[]  = {0, 0, 0, 0, 0};
int i, count = 0;

/*
 * install the probing handler for all possible lines. Remember
 * the result (0 for success, or -EBUSY) in order to only free
 * what has been acquired
 */
for (i=0; trials[i]; i++)
    tried[i] = request_irq(trials[i], short_probing,
                           SA_INTERRUPT, "short probe", NULL);

do {
    short_irq = 0; /* none got, yet */
    outb_p(0x10,short_base+2); /* enable */
    outb_p(0x00,short_base);
    outb_p(0xFF,short_base); /* toggle the bit */
    outb_p(0x10,short_base+2); /* disable */

    /* the value has been set by the handler */
    if (short_irq == 0) { /* none of them? */
        printk(KERN_INFO "short: no irq reported by probe
");
    }
    /*
     * If more than one line has been activated, the result is
     * negative. We should service the interrupt (but the lpt port
     * doesn't need it) and loop over again. Do it at most 5 times
     */
} while (short_irq <=0 && count++ < 5);

/* end of loop, uninstall the handler */
for (i=0; trials[i]; i++)
    if (tried[i] == 0)
        free_irq(trials[i], NULL);

if (short_irq < 0)
    printk("short: probe failed %i times, giving up
", count);

You might not know in advance what the ``possible'' IRQ values are. In that case, you’ll need to probe all the free interrupts, instead of limiting yourself to a few trials[]. To probe for all interrupts, you have to probe from IRQ 0 to IRQ NR_IRQS-1, where NR_IRQS is defined in <asm/irq.h> and is platform-dependent.

Now we are missing only the probing handler itself. The handler’s role is to update short_irq according to which interrupts are actually received. A zero value in short_irq means ``nothing yet,'' while a negative value means ``ambiguous.'' I chose these values to be consistent with probe_irq_off and to use the same code to call either kind of probing within short.c.

void short_probing(int irq, void *dev_id, struct pt_regs *regs)
{
    if (short_irq == 0) short_irq = irq;    /* found */
    if (short_irq != irq) short_irq = -irq; /* ambiguous */
}

The arguments to the handler are described later. Knowing that irq is the interrupt being handled should be sufficient to understand the function just shown.

This description has been extrapolated from arch/i386/kernel/irq.c and include/asm-i386/irq.h as they appear in the 2.0.x kernels; although the general concepts remain the same, the hardware details differ on other platforms and have been slightly modified during 2.1 development.

The lowest level of interrupt handling resides in assembly code declared as macros in irq.h and expanded in irq.c. Three functions are declared for each interrupt: the slow, the fast, and the bad handlers.

The ``bad'' handler, the smallest, is the assembler entry point when no C-language handler has been installed for the interrupt. It acknowledges the interrupt to the proper PIC (Programmable Interrupt Controller) device^[24] and disables it, to avoid losing any further processor time due to spurious interrupts. The bad handler is reinstalled by free_irq when a driver is done with an interrupt line. The bad handler doesn’t increment the counter in /proc/stat.

It’s interesting to note that IRQ probing in both the x86 and the Alpha is based on the behavior of the bad handler. probe_irq_on enables all the bad interrupts, without installing a handler; probe_irq_off simply checks which interrupts have been disabled since probe_irq_on. You can verify this behavior by observing that loading short with probe=1 (kernel-aided probing) doesn’t increment the interrupt counters, while loading it with probe=2 (home-made probing) increments them.

The assembler entry point for slow interrupts saves all the registers on the stack and makes data segments (the DS and ES processor registers) point into the kernel address space (CS has already been set by the processor). The code then acknowledges the interrupt to the PIC, disables notification of new interrupts on the same IRQ line, and issues an sti (set interrupt flag). Bear in mind that the processor automatically clears the flag when servicing an interrupt. The slow handler then passes the interrupt number and a pointer to the processor registers to do_IRQ, a C function that dispatches the right C-language handler. The struct pt_regs * argument that is passed to the interrupt handler in the driver is just a pointer to the position in the stack where the registers are stored.

When do_IRQ is finished, cli is issued, the specific interrupt is enabled in the PIC, and ret_from_sys_call is invoked. This last entry point (arch/i386/kernel/entry.S) restores all the registers from the stack, handles any pending bottom half (see Section 9.4 later in the chapter) and, if needed, reschedules the processor.

The fast entry point is different in that sti is not called prior to jumping to the C code, and not every machine register is saved before calling do_fast_IRQ. When the driver’s handler is called, the regs argument is NULL (because the registers aren’t stored on the stack) and interrupts are still disabled.

Finally, the fast handler reenables the interrupt in the 8259, restores the registers that were saved earlier, and returns without passing through ret_from_sys_call. Pending bottom halves are not run.

In all kernels up to 2.1.34, both handlers increment intr_count before passing control to C code (see Section 6.4.1 in Chapter 6).