linux-kernel - Re: [PATCH v2 0/6] arm64: dts: qcom: Fix broken regulator spec on RPMH boards

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yw8EE/ESDUnIRf8P@hovoldconsulting.com>
Date:   Wed, 31 Aug 2022 08:47:47 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andrew Halaney <ahalaney@...hat.com>,
        Mark Brown <broonie@...nel.org>,
        Andy Gross <agross@...nel.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Bhupesh Sharma <bhupesh.sharma@...aro.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Vinod Koul <vkoul@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] arm64: dts: qcom: Fix broken regulator spec on
 RPMH boards

On Mon, Aug 29, 2022 at 09:49:46AM -0700, Douglas Anderson wrote:
> Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
> get_optimum_mode(), not set_load()") several boards were able to
> change their regulator mode even though they had nothing listed in
> "regulator-allowed-modes". After that commit (and fixes [1]) we'll be
> stuck at the initial mode. Discussion of this (again, see [1]) has
> resulted in the decision that the old dts files were wrong and should
> be fixed to fully restore old functionality.
> 
> This series attempts to fix everyone. I've kept each board in a
> separate patch to make stable / backports work easier.

Should you also update the bindings so that this can be caught during
devicetree validation? That is, to always require
"regulator-allowed-modes" when "regulator-allow-set-load" is specified.

Perhaps at least for RPMh as it seemed you found some cases were this
wasn't currently needed (even if that sounded like an Linux-specific
implementation detail).

Johan