Handling Hardware Interrupts in Linux Device Drivers (Part 1): Fundamentals & IRQ Allocation

What You Will Learn

Prerequisites

What Is a Hardware Interrupt?

Most peripheral controllers need a way to tell the operating system or device driver that something important just happened. Instead of the CPU constantly asking “are you ready yet?”, the device raises its hand with an electrical signal. That signal is a hardware interrupt. When handling hardware interrupts in Linux device drivers, this is the fundamental idea you must internalize: the interrupt is a hardware notification that redirects the processor to run a small piece of code immediately.

Think of polling like repeatedly opening your front door every few seconds to check whether a delivery arrived. It wastes energy and time. An interrupt is the doorbell: you do nothing until it rings, and only then do you respond. On a battery-powered device, this difference is enormous, because constant polling drains the battery quickly.

Devices that commonly generate interrupts include network adapters, storage controllers, USB controllers, audio and video hardware, human interface devices such as keyboards and touchscreens, timer chips, and DMA controllers. In every case, the interrupt lets the low-level software run only when work genuinely needs to be done.

How the Kernel Handles Hardware Interrupts

To understand handling hardware interrupts in Linux device drivers, you first need a picture of the hardware path. A modern motherboard contains an interrupt controller chip. On x86 platforms this is typically the I/O-APIC (I/O Advanced Programmable Interrupt Controller). On ARM and ARM64 platforms, it is the Generic Interrupt Controller (GIC), and current ARM64 server and mobile SoCs commonly use GICv3 or GICv4. Whatever the name, the controller sits between the peripherals and the CPU’s interrupt pin.

Each peripheral capable of raising an interrupt has an IRQ line connected to this controller. IRQ stands for Interrupt ReQuest, and it names the interrupt line (or lines) assigned to a device.

The Step-by-Step Interrupt Flow

Let us walk through what happens when, say, a network adapter receives a packet. The flow below is simplified on purpose so the concept stays clear:

On a standard (non-threaded) interrupt, the hardware interrupt is the top priority on the system. It preempts whatever was running, whether that was user-space or kernel-space code, so your handler can run right away. Later in this series we will see that the threaded interrupt model changes this behavior in a helpful way.

When Interrupts Become a Problem: Livelock and NAPI

Interrupts are efficient, but they are not free. Modern high-speed network adapters (10 Gbps and above) can raise interrupts so rapidly that the CPU spends all its time entering and leaving interrupt handlers and never makes real progress. This condition is called livelock: the system is busy but effectively frozen, much like a deadlock in outcome.

The solution on Linux is a receive-path framework called NAPI (New API). NAPI lets a network driver switch between interrupt-driven mode and polled mode depending on load. Under light traffic it uses interrupts for low latency; under heavy traffic it disables the interrupt and polls in batches, which is far more efficient. This hybrid approach is standard in modern kernel networking drivers and is worth remembering whenever you study high-throughput hardware.

Allocating the Hardware IRQ

Now we reach the practical core of handling hardware interrupts in Linux device drivers: telling the kernel “when interrupt number N fires, call my function.” The challenge is that the exact wiring from controller to CPU differs wildly between platforms. The kernel solves this with the generic IRQ layer, an abstraction that hides hardware differences and exposes clean, portable APIs. Because of this layer, the same driver code can run on x86, ARM, ARM64, and other architectures without change.

The primary function for requesting an interrupt line in a modern kernel is request_irq(), declared in <linux/interrupt.h>. Here is its shape:

#include <linux/interrupt.h>

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

Each parameter has a clear job. The table below explains them in plain language:

The return value follows the usual kernel convention: 0 on success, and a negative error code on failure. Your driver must always check it.

The Handler Signature

Your handler must match the type irq_handler_t. It receives the interrupt number and the same dev cookie you registered, and it returns an irqreturn_t value:

typedef irqreturn_t (*irq_handler_t)(int irq, void *dev_id);

There are three return values you will use in modern kernels:

Common IRQ Flags

The flags argument controls how the kernel treats the line. A few you will meet often:

Releasing the Interrupt

Whatever you request, you must release. When your driver unloads or the device goes away, call free_irq() so the kernel reclaims the line. Pass the same dev cookie you registered so the kernel can identify your registration on a shared line:

void free_irq(unsigned int irq, void *dev);

Where the IRQ Number Comes From

On modern systems you rarely hardcode an interrupt number. Instead the number is described by firmware and resolved for you:

• On embedded ARM/ARM64 platforms, the Device Tree describes each device’s interrupt, and the driver retrieves it with helpers such as platform_get_irq().
• On PCI and PCIe devices, the bus subsystem assigns the number, often using MSI or MSI-X message-signaled interrupts.
• On x86 with ACPI, firmware tables supply the routing information.

The key point for this free Linux kernel development course lesson is that you request the resolved number; you do not guess it.

Best Practices for IRQ Allocation

• Always check the return value of request_irq() and fail cleanly if it is negative.
• Pair every successful request_irq() with a matching free_irq() in your teardown path.
• Use a meaningful name so /proc/interrupts is readable during debugging.
• Pass your device’s private data as dev; never pass NULL on a shared line.
• Prefer managed helpers such as devm_request_irq() where appropriate, so cleanup happens automatically.

Common Mistakes and Troubleshooting

Key Takeaways

Conclusion

In this first part of our lesson on handling hardware interrupts in Linux device drivers, you built a solid mental model of what interrupts are, how the modern kernel delivers them from silicon to your handler, and how to allocate an interrupt line the right way with request_irq() and release it with free_irq(). These fundamentals are the foundation of every interrupt-driven driver you will ever write. As part of the EmbeddedPathashala free Linux device drivers course and free embedded systems course, this knowledge prepares you to write real handler code. In Part 2, we will implement the interrupt handler routine itself, learn the strict dos and don’ts of interrupt context, explore the threaded interrupt model, and understand top and bottom halves.

Frequently Asked Questions (FAQ)