request_threaded_irq(9)

💖 request_threaded_irq(9) — the Kernel API Manual page your bestie actually wants to read 💖

okay so. this is request_threaded_irq, straight out of the Kernel API Manual, and it's literally the glow-up your interrupt handling has been waiting for. grab a snack 🍓, we're allocating an interrupt line together.

---

✨ NAME ✨

request_threaded_irq — allocate an interrupt line 🎀

---

✨ SYNOPSIS ✨

int request_threaded_irq (unsigned int irq , irq_handler_t handler ,
       irq_handler_t thread_fn , unsigned long irqflags , const char *devname ,
       void *dev_id );

six arguments, one function, zero chill. let's go 👑

---

🌸 ARGUMENTS 🌸

• irq — the interrupt line you're allocating. this is the one you're claiming, bestie 💅
• handler — the function that gets called when the IRQ occurs. it's the primary handler for threaded interrupts. and here's the cute part: if handler is NULL and thread_fn != NULL, the default primary handler gets installed for you. no cap, it just does it 🫶
• thread_fn — the function that gets called from the irq handler thread. if it's NULL, no irq thread is created. periodt 💀
• irqflags — the interrupt type flags. vibes: specified 🌈
• devname — an ascii name for the claiming device. cute little nametag energy 🎀
• dev_id — a cookie passed back to the handler function 🍪 (yes, literally a cookie, iykyk)

---

🦋 DESCRIPTION 🦋

so this call allocates interrupt resources and enables the interrupt line and IRQ handling. from the exact point this call is made, your handler function may be invoked. like, immediately. no warning text, no "3… 2… 1…", it's just live 🔥

and because your handler function must clear any interrupt the board raises, you have to take care of both things: initialise your hardware, and set up the interrupt handler in the right order. get the order wrong and it's giving chaos 💀

---

🧚 threaded irq handlers — the split-handler situation

if you want to set up a threaded irq handler for your device, then you need to supply handler and thread_fn. here's the tea:

• handler is still called in hard interrupt context and it has to check whether the interrupt originates from the device.
• if yes — it needs to disable the interrupt on the device and return IRQ_WAKE_THREAD, which wakes up the handler thread and runs thread_fn.

this split handler design is necessary to support shared interrupts. it's not a phase, it's a lifestyle ✨

---

💜 dev_id rules (important, bestie)

dev_id must be globally unique. normally the address of the device data structure is used as the cookie. and since the handler receives this value, it genuinely makes sense to use it. it's giving "the system was designed for this" 👑

if your interrupt is shared, you must pass a non-NULL dev_id, because that's required when freeing the interrupt. skip it and you're gonna have a bad time 😭

---

🎀 Flags 🎀

• IRQF_SHARED — interrupt is shared 💅
• IRQF_TRIGGER_* — specify active edge(s) or level 🌈
• IRQF_ONESHOT — run thread_fn with interrupt line masked 🙈

---

💫 SEE ALSO 💫

kernel file ./kernel/irq/manage.c, plus this whole iconic friend group:

synchronize_hardirq(9), synchronize_irq(9), irq_can_set_affinity(9), irq_can_set_affinity_usr(9), irq_set_thread_affinity(9), irq_affinity_schedule_notify_work(9), irq_update_affinity_desc(9), irq_set_affinity(9), irq_force_affinity(9), irq_set_affinity_notifier(9), irq_set_vcpu_affinity(9), disable_irq_nosync(9), disable_irq(9), disable_hardirq(9), disable_nmi_nosync(9), enable_irq(9), enable_nmi(9), irq_set_irq_wake(9), irq_wake_thread(9), free_irq(9), request_any_context_irq(9), request_nmi(9), irq_percpu_is_enabled(9), free_percpu_irq(9), request_percpu_irq_affinity(9), request_percpu_nmi(9), prepare_percpu_nmi(9), teardown_percpu_nmi(9), irq_get_irqchip_state(9), irq_set_irqchip_state(9), irq_has_action(9), irq_check_status_bit(9)

---

and that's the whole page, bestie 🫶 this came out of ./kernel/irq, dated October 2026, and the header up top says request_threaded_irq(9) — go forth and allocate responsibly, mwah 💋