devm_request..._context_irq(9)

📦 version 7.3.1, in nixpkgs unstable

💅 devm_request_any_context_irq — the managed-device interrupt grabber, but make it ✨logged✨

okay so bestie, welcome to the Kernel API Manual section of your life 🫶. This page is about devm_request_any_context_irq(9) — yes, the title is literally written as devm_request..._context_irq(9) because kernel devs love a dramatic ellipsis, and honestly? iconic. This one is like request_any_context_irq but managed, meaning the kernel cleans up your mess for you when the driver dips. 👑

🌸 NAME 🌸

devm_request_any_context_irq — allocate an interrupt line for a managed device with error logging. like, it grabs the IRQ, it does devres magic so you don't leak it, and it yells at you in the logs if something goes wrong. all three vibes in one function ✨

🎀 SYNOPSIS 🎀

int devm_request_any_context_irq (struct device *dev , unsigned int irq
, irq_handler_t handler , unsigned long irqflags , const char *devname ,
void *dev_id );

copy it exactly, don't get creative, this is C not a vibe-based language 😭

💖 ARGUMENTS 💖

  • dev — the device you're requesting this interrupt for. main character energy is the device. 🎀
  • irq — the interrupt line you wanna allocate. this is the number you're claiming, no cap.
  • handler — the function that gets called when the interrupt fires. your callback. the moment it all happens. 🔥
  • irqflags — interrupt type flags. the personality settings for how this IRQ behaves.
  • devname — an ascii name for the claiming device. and hey, if you pass NULL, it just uses dev_name(dev). convenient fr fr. ✨
  • dev_id — a cookie that gets passed back to your handler function. a little treat you send out into the world and get returned. 🍓

🦋 DESCRIPTION 🦋

so, except for that extra dev argument, this function takes the same arguments and performs the same function as request_any_context_irq. same energy, one extra parameter. 💅

the glow-up is this: interrupts requested with this function are automatically freed on driver detach. no manual cleanup arc, no leak drama, the devres machinery just handles it. we love a self-cleaning situation. 🧚

but listen — if an interrupt allocated with this function needs to be freed separately (like, while the driver is still alive), you must use devm_free_irq. that's not optional, that's just the rules, bestie. 🙈

and when the request fails, an error message gets printed with contextual info — device name, interrupt number, handler functions and error code. it literally tells you what broke. so don't add extra error messages at the call sites, okay? it's already doing the most. adding your own is giving clutter. 💀

⭐ RETURN ⭐

IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success — those are your good-ending outcomes, slay 🌈 — or a negative error number if it went sideways. check it, always. 😭

👑 SEE ALSO 👑

go read them, that's your homework, iykyk 📚✨

okay that's the whole page, bye bestie 💜

this iconic little doc lives at ./kernel/irq, and it's dated October 2026 — so yes, it's from the future and it's still correct. periodt. 💅🌸🎀

📦 where this page comes from