linux-kernel - Re: [PATCH v3] 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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 8 Sep 2022 12:25:25 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Andrew Halaney <ahalaney@...hat.com>, 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
Cc:     linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dianders@...omium.org,
        johan@...nel.org, Johan Hovold <johan+kernel@...nel.org>
Subject: Re: [PATCH v3] regulator: dt-bindings: qcom,rpmh: Indicate
 regulator-allow-set-load dependencies

On 07/09/2022 22:49, 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.
> 
> In general this is true for any regulators that are setting modes
> instead of setting a load directly, for example RPMH regulators. A
> counter example would be RPM based regulators, which set a load
> change directly instead of a mode change. In the RPM case
> regulator-allow-set-load alone is sufficient to describe the regulator
> (the regulator can change its output current, here's the new load),
> but in the RPMH case what valid operating modes exist must also be
> stated to properly describe the regulator (the new load is this, what
> is the optimum mode for this regulator with that load, let's change to
> that mode now).
> 
> With this in place devicetree validation can catch issues like this:
> 
>     /mnt/extrassd/git/linux-next/arch/arm64/boot/dts/qcom/sm8350-hdk.dtb: pm8350-rpmh-regulators: ldo5: 'regulator-allowed-modes' is a dependency of 'regulator-allow-set-load'
>             From schema: /mnt/extrassd/git/linux-next/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
> 
> Where the RPMH regulator hardware is described as being settable, but
> there are no modes described to set it to!
> 
> Suggested-by: Johan Hovold <johan+kernel@...nel.org>
> Reviewed-by: Johan Hovold <johan+kernel@...nel.org>
> Reviewed-by: Douglas Anderson <dianders@...omium.org>
> Signed-off-by: Andrew Halaney <ahalaney@...hat.com>
> ---
> 
> v2: https://lore.kernel.org/linux-arm-msm/20220906201959.69920-1-ahalaney@redhat.com/
> Changes since v2:
>   - Updated commit message to explain how this is a property of the
>     hardware, and why it only applies to certain regulators like RPMH
>     (Johan + Krzysztof recommendation)
>   - Added Johan + Douglas' R-B tags

You posted before we finished discussion so let me paste it here:

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