STRUCT REGULATOR_IRQ_DESC(9)

✨ STRUCT REGULATOR_IRQ_DESC(9) ✨

okay bestie, welcome to the Kernel API Manual entry for struct regulator_irq_desc(9) and honestly? it's giving "the group chat that tells everyone when something goes wrong" 💅 this thing is the notification sender for IRQ based events, and it's lowkey the main character of regulator error handling 🔥

---

🌸 NAME 🌸

struct regulator_irq_desc — notification sender for IRQ based events. that's it, that's the vibe 🎀

---

🦋 SYNOPSIS 🦋

struct regulator_irq_desc {
    const char *name;
    int fatal_cnt;
    int reread_ms;
    int irq_off_ms;
    bool skip_off;
    bool high_prio;
    void *data;
    int (*die)(struct regulator_irq_data *rid);
    int (*map_event)(int irq, struct regulator_irq_data *rid, unsigned
long *dev_mask);
    int (*renable)(struct regulator_irq_data *rid);
 };

copy that exactly, bestie — no cap, every character matters 😤

---

🎀 Members 🎀

okay so here's the cast of characters, and they ALL have lore 🫶

• name — the visible name for the IRQ. literally its government name ✨
• fatal_cnt — so if this IRQ is used to signal a HW damaging condition, it may be best to shut-down regulator(s) or reboot the SOC if error handling is repeatedly failing. if fatal_cnt is given, the IRQ handling is aborted if it fails for fatal_cnt times and the die callback (if populated) is called. and if die is not populated, poweroff for the system is attempted in order to prevent any further damage. that's the dramatic part, and it's real 💀
• reread_ms — the time which is waited before attempting to re-read status at the worker if IC reading fails. immediate re-read is done if time is not specified. so: no number = no waiting, it just goes 🏃‍♀️
• irq_off_ms — the time which IRQ is kept disabled before re-evaluating the status for devices which keep IRQ disabled for duration of the error. if this is not given, the IRQ is left enabled and renable is not called. important!! 🙈
• skip_off — if set to true, the IRQ handler will attempt to check if any of the associated regulators are enabled prior to taking other actions. if no regulators are enabled and this is set to true, a spurious IRQ is assumed and IRQ_NONE is returned. spurious IRQ said "not me, not my problem" 😭
• high_prio — boolean to indicate that high priority WQ should be used. high priority work queue, because this girl does not do lines ⭐
• data — driver private data pointer which will be passed as such to the renable, map_event and die callbacks in regulator_irq_data. it's the little bag she carries everywhere 🎒
• die — protection callback. if IC status reading or recovery actions fail fatal_cnt times, this callback is called or the system is powered off. this callback should implement a final protection attempt like disabling the regulator. if protection succeeded, die may return 0. if anything else is returned, the core assumes final protection failed and attempts to perform a poweroff as a last resort. so like... zero means slay, anything else means 🕯️🕯️🕯️
• map_event — driver callback to map IRQ status into regulator devices with events / errors. NOTE: callback MUST initialize both the errors and notifs for all rdevs which it signals having active events, as core does not clean the map data. REGULATOR_FAILED_RETRY can be returned to indicate that the status reading from IC failed. if this is repeated for fatal_cnt times, the core will call the die callback or power-off the system as a last resort to protect the HW. read that NOTE again bestie, it's not decorative 👑
• renable — optional callback to check status (if HW supports that) before re-enabling IRQ. if implemented, this should clear the error flags so that errors fetched by regulator_get_error_flags are updated. if callback is not implemented, then errors are assumed to be cleared and IRQ is re-enabled. REGULATOR_FAILED_RETRY can be returned to indicate that the status reading from IC failed. if this is repeated for 'fatal_cnt' times, the core will call the die callback or, if die is not populated, then attempt to power-off the system as a last resort to protect the HW. returning zero indicates that the problem in HW has been solved and IRQ will be re-enabled. returning REGULATOR_ERROR_ON indicates the error condition is still active and keeps IRQ disabled. please note that returning REGULATOR_ERROR_ON does not retrigger evaluating what events are active or resending notifications. if this is needed, you probably want to return zero and allow IRQ to retrigger, causing events to be re-evaluated and re-sent. that's the whole plot twist right there 🌈

---

💜 Description 💜

this structure is used for registering regulator IRQ notification helper. short and sweet — it's the ~registration form~ for the whole notification situation 💌

---

🌟 SEE ALSO 🌟

• Kernel file ./include/linux/regulator/driver.h
• struct regulator_ops(9)
• struct regulator_desc(9)
• struct regulator_config(9)
• struct regulator_err_state(9)
• struct regulator_irq_data(9)

go read those too, iykyk 📚

---

okay that's the whole page 🫶 this came out of ./include/linux/regulator, dated October 2026, and it's still struct regulator_irq_desc(9) — she said "same name, same energy" 💅✨ bye bestie, go write some safe regulators 🦋💖