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: <CAAFDt1uiWq-adPtXiD+i1swavK_GS+SB__+46NN5jtwOopz9Lw@mail.gmail.com>
Date: Sun, 8 Feb 2026 18:37:24 +0530
From: Saikiran B <bjsaikiran@...il.com>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Mark Brown <broonie@...nel.org>, Konrad Dybcio <konrad.dybcio@....qualcomm.com>, 
	Rob Herring <robh@...nel.org>, Jishnu Prakash <jishnu.prakash@....qualcomm.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, Feb 6, 2026 at 9:50 PM Kamal Wadhwa
<kamal.wadhwa@....qualcomm.com> wrote:
>
> On Tue, Feb 03, 2026 at 04:30:27PM +0000, Mark Brown wrote:
> > 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

Hi Kamal,

Thanks for checking the internal register defaults.

I can confirm it is definitely related to the power-cycling state. While I
haven't probed the pads, I validated this with two software tests:

1. The Always On Test: I modified the driver to keep the regulators
   permanently enabled (never turning off). In this state, the camera works
   100% of the time, even with rapid open/close cycles. This proves the
   crash is triggered specifically by the power-down event.

2. The Timing Threshold: Through iterative testing, I found that reopening
   the camera fails consistently if the off-time is <2.0s, but succeeds if
   the off-time is >2.3s. This 2.3s window matches the calculated RC time
   constant for a passive discharge on these rails.

If the Strong Pull Down were effectively active, the rails should drain in
milliseconds. The fact that it requires 2.3s suggests that on this unit,
the PD is either effectively disabled or too weak for the bulk capacitance
present.

As I mentioned to Mark, I have withdrawn this specific delay patch to
investigate if I can manually enforce Active Discharge (via direct RPMh
commands) to solve this at the source. But now, your note that these settings
might be locked is concerning.

> > > 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.
>
> I have checked:
> - ALL the pm8010 regulators have the PD enabled in OFF state by default.
> - From kernel enable/disable of regulator PD settings is not allowed. Its set
>   from the boot and stays as-is later.
>
> But since its already enabled with strong PD, i guess it would not be needed
> anyway.
>
> Regards,
> Kamal
>

Regards,
Saikiran