[PATCH v5 0/4] regulator: qcom-rpmh: Add support for off-on-delay and debounce-delay

From: Jishnu Prakash

Date: Tue Oct 27 2026 - 08:43:56 EST


This series adds support for two related delay properties for the Qualcomm
RPMh regulator driver: `regulator-off-on-delay-us` (enforces a minimum
physical off-time before re-enable) and `qcom,regulator-off-debounce-delay-us`
(defers sending a disable request to RPMh so quick disable/enable bounces
never reach the hardware).

Motivation:
On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
(LDO1, LDO3, LDO7) have large bulk capacitors and rely on passive discharge.
When these regulators are disabled, the voltage decays very slowly. If
re-enabled too quickly, the sensor experiences a brownout and fails to
initialize. This can be prevented by specifying a minimum off-time.

Separately, some consumers rapidly toggle a regulator off and on again,
for example, a driver that disables its supply on -EPROBE_DEFER and
re-enables it on the next probe attempt. Sending the disable vote to RPMh
immediately in this case causes needless power cycling, so
qcom,regulator-off-debounce-delay-us lets this be deferred and canceled
if a quick re-enable follows.

This series was prepared with the help of an AI coding assistant (Claude
Code) under my direction. I reviewed, built and tested the changes.

Signed-off-by: Jishnu Prakash <jishnu.prakash@xxxxxxxxxxxxxxxx>
---
Changes in v5:
- Implemented "regulator-off-on-delay-us" in regulator core as Mark suggested
- Updated vreg->enabled in enable/disable callbacks to report
correct state to regulator framework.
- Made following changes to address Sashiko comments:
- Set debounce_delay to 0 in teardown action to prevent queueing disable
work events afterward (which could lead to use-after-free) and added a
lock to ensure serialization between teardown and disable callback.
- Called disable callback in teardown function in case of pending
queued disable work events, to keep regulator HW state synced with SW state.
- Set vreg->rdev in disable callback to avoid NULL pointer dereference
if consumer tries to disable regulator before this assignment is done in probe.
- Removed Assisted-by tags.
- Link to v4: https://patch.msgid.link/20261001-regulator-off-on-delay-v4-0-258ba9612da8@xxxxxxxxxxxxxxxx

Changes in v4:
- Taking over upstreaming this series from Saikiran.
- Made the binding change for `regulator-off-on-delay-us` in
Documentation/devicetree/bindings/regulator/regulator.yaml instead of
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml,
as this property seems better suited to be a generic one.
- Added new `qcom,regulator-off-debounce-delay-us` property and driver
support for deferring the RPMh disable request to implement Mark's
suggestion.
- Rebased to Linux 7.3-rc5.
- Link to v3: https://patch.msgid.link/20260127190211.14312-1-bjsaikiran@xxxxxxxxx

Changes in v3:
- Added Patch 1/2: Update DT bindings to allow `regulator-off-on-delay-us`
for `qcom,rpmh-regulator` (Requested by Mark Brown).
- Updated Patch 2/2: Refined commit message to explicitly mention the
passive discharge and bulk capacitor mechanism on the Yoga Slim 7x
(Requested by Mark Brown).

Changes in v2:
- Moved the motivation/context from the cover letter into the commit
message of the driver patch.

---
Jishnu Prakash (4):
regulator: dt-bindings: Add 'regulator-off-on-delay-us' property
regulator: core: Parse regulator-off-on-delay-us generically
regulator: dt-bindings: qcom,rpmh-regulator: Add debounce delay property
regulator: qcom-rpmh: Add debounce delay before disabling regulator

.../bindings/regulator/qcom,rpmh-regulator.yaml | 18 +++
.../devicetree/bindings/regulator/regulator.yaml | 5 +
drivers/regulator/core.c | 18 ++-
drivers/regulator/of_regulator.c | 4 +
drivers/regulator/qcom-rpmh-regulator.c | 166 ++++++++++++++++++++-
include/linux/regulator/machine.h | 4 +
6 files changed, 204 insertions(+), 11 deletions(-)
---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
change-id: 20260910-regulator-off-on-delay-2c86cb8f3eb8

Best regards,
--
Jishnu Prakash <jishnu.prakash@xxxxxxxxxxxxxxxx>