qcom_labibb...overy_worker(9)

🌸 NAME 🌸

qcom_labibb_ocp_recovery_worker — bestie, this one handles the OCP event 💅

---

✨ SYNOPSIS ✨

void qcom_labibb_ocp_recovery_worker (struct work_struct *work );

---

🎀 ARGUMENTS 🎀

• work — the OCP work structure, that's literally the whole vibe 🫶

---

💖 DESCRIPTION 💖

Okay so picture this: this is the worker function that handles the Over Current Protection hardware event — yes, the whole OCP situation, main character energy only 🔥

What it does is check if the hardware is still signaling an over-current condition, and it'll eventually stop the regulator if that condition is still being signaled after LABIBB_MAX_OCP_COUNT times. Like, it gives it that many chances and then it's done being nice 💀

And if the driver that's consuming the regulator did not take action for the OCP condition, or the hardware just didn't stabilize? Bestie, a cut of the LAB and IBB regulators will be forced — the regulators get disabled, no cap 🔌✨

As a last resort: if the writes to shut down the LAB/IBB regulators fail for more than LABIBB_MAX_FATAL_COUNT, then a kernel panic will be triggered 😭 and ngl that's fully intentional — it's the last resort to protect the hardware from burning. This is expected to never happen, but it's kept around to try to further ensure that we protect the hardware at all costs. Protecting the hardware is the whole point, periodt 👑

Fr fr though — that kernel panic path is by design, not a bug. It's the "we would literally rather crash than let the silicon cook" option 🫶

---

🦋 SEE ALSO 🦋

• Kernel file ./drivers/regulator/qcom-labibb-regulator.c
• qcom_labibb_check_ocp_status(9)
• qcom_labibb_ocp_isr(9)
• qcom_labibb_check_sc_status(9)
• qcom_labibb_sc_recovery_worker(9)
• qcom_labibb_sc_isr(9)

---

Okay that's the whole thing, bestie 🌈 this page lives over in ./drivers/regulator, it's from October 2026, kernel-y as ever — mwah, go read the source, ily 💜🎀