linux-kernel - Re: [PATCH 3/3] regulator: dt-bindings: qcom,rpmh: Indicate regulator-allow-set-load dependencies

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: <51d77893-502d-9581-5d50-e99ff0a730e6@linaro.org>
Date:   Thu, 8 Sep 2022 12:23:07 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Andrew Halaney <ahalaney@...hat.com>
Cc:     agross@...nel.org, andersson@...nel.org,
        konrad.dybcio@...ainline.org, lgirdwood@...il.com,
        broonie@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        dianders@...omium.org, johan@...nel.org
Subject: Re: [PATCH 3/3] regulator: dt-bindings: qcom,rpmh: Indicate
 regulator-allow-set-load dependencies

On 06/09/2022 16:41, Andrew Halaney wrote:
> On Mon, Sep 05, 2022 at 06:50:02PM +0200, Krzysztof Kozlowski wrote:
>> On 02/09/2022 20:51, Andrew Halaney wrote:
>>> For RPMH regulators it doesn't make sense to indicate
>>> regulator-allow-set-load without saying what modes you can switch to,
>>> so be sure to indicate a dependency on regulator-allowed-modes.
>>
>> Hmmmm.... What about other regulators?
>>
> 
> My understanding (which very well might be wrong) is that if your
> regulator is allowed to change modes, and sets regulator-allow-set-load,
> then you have to describe what modes you can switch to.
>> But if you don't allow setting modes (for example qcom_rpm-regulator.c)
> and just allow yourself to set_load() directly, then you don't need it.
> 
> So there is a more general requirement that applies regulator wide, but
> I'm not sure how you would apply that at a higher level. I don't see a
> good way to figure out in dt-binding land what regulator ops each
> binding supports.

The bindings don't express it, but the regulator core explicitly asks
for set_mode with set_load callbacks in drms_uA_update(), which depends
on REGULATOR_CHANGE_DRMS (toggled with regulator-allow-set-load).

drms_uA_update() later calls regulator_mode_constrain() which checks if
mode changing is allowed (REGULATOR_CHANGE_MODE).

Therefore based on current implementation and meaning of
set-load/allowed-modes properties, I would say that this applies to all
regulators. I don't think that RPMh is special here.

Best regards,
Krzysztof