linux-kernel - Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAFDt1vLkiy6vHxqbKrrxUqNb=rocOjhU=HZ9+f6BmycUnxpQg@mail.gmail.com>
Date: Tue, 27 Jan 2026 23:13:45 +0530
From: Saikiran B <bjsaikiran@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: lgirdwood@...il.com, andersson@...nel.org, konrad.dybcio@...aro.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

Hi Mark,

(Apologies, our emails crossed, I sent v2 to fix the commit log format
before seeing this reply).

> The core regulator framework does not support this... specifically supported by fixed voltage regulator.

I see that "of_get_regulation_constraints()" in
drivers/regulator/of_regulator.c parses "regulator-off-on-delay-us".
Since qcom-rpmh-regulator uses of_regulator_match(), I will verify if
the core handles this automatically without needing manual parsing in
the driver. If it works via standard constraints, I will drop this
driver patch and only submit the DT Binding update.

> What exactly are we talking about in terms of the actual configuration here...

These are LDOs (LDO1, LDO3 and LDO7) powering camera sensors on the
Lenovo Yoga Slim 7x.
The issue is platform-specific: this board has large bulk capacitors
on the camera rails. When the LDO is disabled, the voltage decays very
slowly (passive discharge), taking some time (Still testing various
timings) to reach a safe reset level. If we re-enable the rail before
this discharge completes, the sensor experiences a brownout and fails
to initialize.

> This would at a minimum need the bindings for the regulators on the affected platforms to be updated.

Understood. I missed the binding update. I will prepare a patch to
update Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
to allow this property.

I will test the standard constraint path and report back.

Thanks & Regards,
Saikiran

On Tue, Jan 27, 2026 at 11:06 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Tue, Jan 27, 2026 at 10:57:57PM +0530, Saikiran wrote:
>
> > Some Qualcomm platforms require a significant delay after powering off a
> > rail before it can be powered on again, especially for regulators that
> > depend on passive discharge.
>
> > The core regulator framework supports this via the 'regulator-off-on-delay-us'
> > property, but the RPMh regulator driver currently ignores it.
>
> The core regulator framework does not support this, this is specifically
> a property supported by the fixed voltage regulator.
>
> > Add support for parsing this generic property from device tree and
> > populating the regulator descriptor. This allows board-specific DTS files
> > to specify required discharge delays for RPMh-controlled regulators.
>
> This would at a minimum need the bindings for the regulators on the
> affected platforms to be updated.  What exactly are we talking about in
> terms of the actual configuration here, what goes wrong if we don't
> leave the regulator powered off and how sure are we that this is
> platform specific rather than regulator specific?  I'm guessing these
> are LDOs?