linux-kernel - Re: [PATCH] regulator: qcom-rpmh: Implement get_optimum_mode(), not set

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]

Date:   Tue, 23 Aug 2022 14:06:30 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Andrew Halaney <ahalaney@...hat.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: qcom-rpmh: Implement get_optimum_mode(), not
 set_load()

On Mon, Aug 22, 2022 at 01:13:55PM -0700, Doug Anderson wrote:

> I guess at this point I'll wait for Mark to give his suggestion for
> what to do. Options I'm aware of:

> a) ${SUBJECT} patch was written as a cleanup as per Mark's request and
> we could just revert it.

> b) We could make it so that failures to get the input/output voltages
> doesn't count as an error when going through the get_optimum_mode()
> path.

We could push the checks for a valid voltage down into the drivers, a
lot of things aren't particularly sensitive to the output voltage here
and are much more sensitive to the current draw.  Depending on people's
attitudes to DT stability for Qualcomm platforms we could also fix the
affected DTs as well, though that doesn't stop us handling this in the
core too.

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