linux-kernel - Re: [PATCH v2] 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: <CAAFDt1vPGS9EFqQHdwSWm9G1NUC-71+-EFuFG_diksJy0=87Zw@mail.gmail.com>
Date: Wed, 28 Jan 2026 19:29:34 +0530
From: Saikiran B <bjsaikiran@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, lgirdwood@...il.com, 
	andersson@...nel.org, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

On Wed, Jan 28, 2026 at 5:25 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Wed, Jan 28, 2026 at 05:04:36PM +0530, Saikiran B wrote:
>
> > The `off_on_delay` field resides in `struct regulator_desc`. For most
> > regulator drivers, this structure is `static const` (immutable) as it describes
> > fixed silicon characteristics. Generic parsing code in `of_regulator.c`
> > cannot blindly write to `desc->off_on_delay` without risking a write to
> > read-only memory.
>
> Your reading there is right, generally the expectation was that this
> should be a property of the regulator rather than the system.  This case
> seems pretty unusual thus far but perhaps we'll see more such cases in
> future and should move the property but for now having it enabled per
> driver seems safer.
>
> > The `qcom-rpmh-regulator` driver is unique in that it allocates
> > `vreg->rdesc` dynamically at runtime, which allows us to safely populate
> > this field from DT.
>
> > To support this generically in `of_regulator.c`, we would likely need to
> > introduce `off_on_delay` into `struct regulator_constraints` instead,
> > and then update the core regulator handling to check both sources.
>
> Yes, indeed - if we were supporting the property completely generically
> we'd just not have the driver fill in in the information and store the
> actual value used separately with the DT property overriding the driver
> value (possibly only if it was larger).

Thanks for the confirmation, Mark.

Since the driver-specific approach is architecturally acceptable, I will keep
this implementation in mind as a fallback.

However, to address the root cause of the camera brownout once and for all,
I am now investigating porting the Active Discharge logic (sending specific
voltage/mode resource commands) from similar Qualcomm sister boards into
`qcom-rpmh-regulator`.

That would be the superior hardware solution, eliminating the need for
arbitrary delays. Since that involves complex RPMh resource handling and
reverse-engineering the specific commands for this PMIC, it will take some
time to implement and validate.

I will hold off on pursuing this delay patch further until I have exhausted
the Active Discharge path.

I thank you and konrad for providing the feedback.

Regards,
Saikiran