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] [day] [month] [year] [list]

Message-ID: <7da1e3e3-18d7-45f8-9168-481ce8e4493c@sirena.org.uk>
Date: Tue, 3 Feb 2026 16:30:27 +0000
From: Mark Brown <broonie@...nel.org>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
	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 Tue, Feb 03, 2026 at 09:50:05PM +0530, Kamal Wadhwa wrote:

> 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)?

The issue is that some of the supplies fall to a level where they cause
disruption to the devices using them but not far enough to put them back
into a power on reset state, the device browns out somehow (I'm guessing
some retained state is corrupted).  Ideally they'd have POR circuits
that handle this case well but apparently that's not the case.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)