linux-kernel - Re: [PATCH v2] regulator: qcom_smd: Keep one rpm handle for all vregs

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]

Date: Fri, 5 Jan 2024 20:23:26 +0000
From: Mark Brown <broonie@...nel.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Marijn Suijten <marijn.suijten@...ainline.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] regulator: qcom_smd: Keep one rpm handle for all vregs

On Fri, Jan 05, 2024 at 09:15:49PM +0100, Konrad Dybcio wrote:
> On 5.01.2024 17:31, Mark Brown wrote:

> > It'd be slightly more robust to have a check here that we do get the
> > same RPM back if the variable is already set, just on the off chance
> > that something changes in some future system and we do end up with a
> > second RPM somehow.

> Knowing how improbable this is (currently RPM is responsible for almost all
> power and some clock rails, including DDR), I'd say it's excessive, but if
> you wish, I can add it.

It really feels like something where if this was a good idea we'd have
an API to do this directly rather than passing around through driver
data.  The fact that it's used for all power management doesn't
immediately preclude having two instances managing the power for two
different bits of the system (eg, a low power island).

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