linux-kernel - Re: [PATCH] regulator: qcom_spmi: do no register unused regulators

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: <YYOYZ1cEFFJhX2ae@gerhold.net>
Date:   Thu, 4 Nov 2021 09:23:03 +0100
From:   Stephan Gerhold <stephan@...hold.net>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: qcom_spmi: do no register unused regulators

On Thu, Nov 04, 2021 at 03:43:51AM +0300, Dmitry Baryshkov wrote:
> Typically SPMI interface to PMIC regulators on Qualcomm platforms is
> used to supplement RPM interface in cases where direct control is
> required (e.g. for the APCC or GFX regulators). Registering all possible
> regulators is thus not required and may be potentially harmfull if
> somebody tries to setup those directly. Thus register only regulators
> that are really used in the device tree and ignore all unused
> regulators.
> 

Shouldn't the missing regulator constraints already take care of that?
If you don't setup any voltage etc in the device tree it should
effectively make the regulator read-only.

This is useful sometimes, I have used this for debugging before because
it lets you check the actual voltage applied by RPM (at least on MSM8916).
The voltage that Linux believes to have set through the RPM driver is
not necessarily the same that is really set at the end.

Thanks,
Stephan