linux-kernel - Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow 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: <20260203162005.ui7sl4t5m32jwas6@hu-kamalw-hyd.qualcomm.com>
Date: Tue, 3 Feb 2026 21:50:05 +0530
From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
        Jishnu Prakash <jishnu.prakash@....qualcomm.com>,
        Saikiran <bjsaikiran@...il.com>, lgirdwood@...il.com,
        andersson@...nel.org, konradybcio@...nel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        krzk+dt@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow
 regulator-off-on-delay-us

On Fri, Jan 30, 2026 at 12:05:38PM +0100, Konrad Dybcio wrote:
> On 1/29/26 7:15 PM, Mark Brown wrote:
> > On Thu, Jan 29, 2026 at 11:49:42AM -0600, Rob Herring wrote:
> >> On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:
> > 
> >>> This property is required for platforms where specific rails (like camera
> >>> LDOs) rely on passive discharge and need a mandatory off-time constraint
> >>> enforced by the regulator core.
> > 
> >> Does enforcing some off time on all your regulators cause some negative 
> >> impact on the ones that don't need it? If turning them back on is 
> >> performance critical maybe don't turn them off in the first place.
> > 
> > You might see something like unexpectedly long delays resuming a runtime
> > suspended device.  Generally I'd say that if the delays needed for
> > something like this are long enough for anyone to notice they're long
> > enough to be disruptive.
> > 
> > Having said that I believe an active discharge feature in the hardware
> > has been identified and is being investigated, that's generally a vastly
> > better solution all round so hopefully this change isn't needed at all.
> 
> +Jishnu, Kamal
> 
> Could you please confirm whether our hw can do that?

Yes, we do have setting to enable a strong pull-down to discharge the caps
in OFF state, but we dont have the option to enable/disable this from the
APPS. However most regulators will have the pull downs are enabled by
default (I'll check and confirm about this specific LDOs internally)

But I'm wondering if this is really a 'slow discharge' issue, because if the
caps discharge slowly.. shouldn't the rails be turning back ON faster
compared to when they are completely discharged (fast discharge case without
bulk caps)?

@Saikiran, Just checking if you did some analysis from HW side for this
issue.. taking plots? or may be removed the bulk caps on the HW and checked
that that issue went away? (or was still their?)

> 
> Konrad