handle_threaded_wake_irq(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… handle_threaded_wake_irq(9) β€” a Kernel API Manual moment

okay so bestie, welcome to the handle_threaded_wake_irq page from the Kernel API Manual. this one's short but it's lowkey important, so pay attention 🫢


✨ NAME ✨

handle_threaded_wake_irq β€” the handler for dedicated wake-up interrupts πŸ’€βž‘οΈπŸ”₯


🌸 SYNOPSIS 🌸

irqreturn_t handle_threaded_wake_irq (int irq , void *_wirq );

πŸŽ€ ARGUMENTS πŸŽ€

  • irq β€” the device-specific dedicated wake-up interrupt. this is the interrupt in question, the one whose whole job is waking stuff up ⭐
  • _wirq β€” the wake IRQ data. literally the data, no cap πŸ™ˆ

πŸ¦‹ DESCRIPTION πŸ¦‹

so like, some devices have a separate wake-up interrupt on top of their normal device IO interrupt. the wake-up interrupt is the one that signals "hey, this device should be woken up from its idle state" πŸ””

this handler uses device specific pm_runtime functions to wake the device, and then it's up to the device to do whatever it needs to do. it's giving main character energy β€” everyone else is just supporting cast πŸ’…

note that because the device may need to restore context and start up regulators, we use a threaded IRQ 🧡 (yes, that's why it's in the name, iykyk).

also note: we are not resending the lost device interrupts. we assume that the wake-up interrupt just needs to wake-up the device, and then the device's pm_runtime_resume can deal with the situation. periodt. πŸ’€

πŸ”₯ SEE ALSO πŸ”₯

like, the whole wake IRQ friend group honestly πŸŒˆπŸ‘‘


and that's the page!! it lives in ./drivers/base/power, dated October 2026, and it's iconic for it πŸŽ€βœ¨ bye bestie, go wake up some devices πŸ’–

πŸ“¦ where this page comes from