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: <93ea039d-c194-47e5-8a4e-975c144a1a25@sirena.org.uk>
Date: Wed, 28 Jan 2026 11:55:45 +0000
From: Mark Brown <broonie@...nel.org>
To: Saikiran B <bjsaikiran@...il.com>
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 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).

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