Prerequisites

What Is request_irq() in the Linux Kernel?

request_irq() is the kernel API a device driver calls to tell the interrupt subsystem: “when this hardware line fires, please call my function.” It is normally invoked from the driver’s probe method, when the device is being initialized, not from the module’s init() function directly — this matters because on modern kernels most drivers are written against the platform driver or device tree probe model rather than being hardcoded.

The request_irq() Function Signature

The function takes five arguments that have stayed stable across kernel releases:

int request_irq(unsigned int irq,
                 irq_handler_t handler,
                 unsigned long flags,
                 const char *name,
                 void *dev);

Common IRQF_* Flags

A Simple, Original Example: GPIO Button Driver

Below is a small, original example (not taken from any book or external source) showing a minimal GPIO interrupt registration pattern you would find in a modern platform driver targeting an embedded Linux board.

#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/gpio/consumer.h>

struct mybtn_dev {
    struct gpio_desc *gpiod;
    int irq;
};

static irqreturn_t mybtn_isr(int irq, void *dev_id)
{
    struct mybtn_dev *priv = dev_id;

    /* Keep this short: just note the event, do heavy work later */
    dev_info(NULL, "mybtn: button pressed on irq %d\n", irq);

    return IRQ_HANDLED;
}

static int mybtn_probe(struct platform_device *pdev)
{
    struct mybtn_dev *priv;
    int ret;

    priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    priv->gpiod = devm_gpiod_get(&pdev->dev, "button", GPIOD_IN);
    if (IS_ERR(priv->gpiod))
        return PTR_ERR(priv->gpiod);

    priv->irq = gpiod_to_irq(priv->gpiod);
    if (priv->irq irq;

    ret = devm_request_irq(&pdev->dev, priv->irq, mybtn_isr,
                            IRQF_TRIGGER_FALLING, "mybtn-irq", priv);
    if (ret)
        return ret;

    platform_set_drvdata(pdev, priv);
    return 0;
}

Why devm_request_irq() Is Preferred Today

Most modern drivers avoid plain request_irq() in favor of the “devm” (device-managed) variant, devm_request_irq(). It ties the lifetime of the IRQ registration to the underlying struct device, so the kernel automatically calls free_irq() for you when the device is removed or the probe fails partway through. This removes an entire class of bugs where developers forget to release the interrupt in an error path.

Threaded Interrupts: request_threaded_irq()

Many drivers today, especially for I2C/SPI sensors, use request_threaded_irq() instead of a plain hard-IRQ handler. This lets you run the bulk of your interrupt-handling logic in a dedicated kernel thread, where sleeping and blocking calls are allowed — something a normal hard-IRQ handler cannot do.

static irqreturn_t sensor_hard_isr(int irq, void *dev_id)
{
    /* runs in real interrupt context, must be very fast */
    return IRQ_WAKE_THREAD;
}

static irqreturn_t sensor_thread_fn(int irq, void *dev_id)
{
    /* runs in process context: safe to sleep, use I2C, allocate memory */
    struct mysensor_dev *priv = dev_id;

    i2c_smbus_read_byte_data(priv->client, MYSENSOR_REG_STATUS);
    return IRQ_HANDLED;
}

devm_request_threaded_irq(&client->dev, client->irq,
                           sensor_hard_isr, sensor_thread_fn,
                           IRQF_ONESHOT, "mysensor", priv);

Releasing the Interrupt with free_irq()

If you registered the interrupt with plain request_irq(), you are responsible for calling free_irq(irq, dev_id) in your driver’s remove path, matching the exact dev_id pointer you originally passed in. Forgetting this — or freeing it with the wrong pointer on a shared line — is one of the most common driver bugs. This is exactly the class of bug that devm_request_irq() is designed to eliminate.

static void mybtn_remove(struct platform_device *pdev)
{
    struct mybtn_dev *priv = platform_get_drvdata(pdev);

    /* Not required here because devm_request_irq() was used,
       shown only for drivers using plain request_irq() */
    free_irq(priv->irq, priv);
}

Common Mistakes

Best Practices

Security Considerations

Interrupt handlers run with high privilege and can be a target for fault-injection style attacks on embedded systems with physically accessible GPIO lines. Validate any data read from hardware registers before trusting it, and avoid exposing raw register values to user space without sanitization.

Summary / Key Takeaways

Frequently Asked Questions