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]
Date:   Tue, 23 Aug 2022 13:18:43 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.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()

Hi,

On Tue, Aug 23, 2022 at 6:06 AM Mark Brown <broonie@...nel.org> wrote:
>
> 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.

OK, patch posted with this approach. ("regulator: core: Require
regulator drivers to check uV for get_optimum_mode()") [1]

[1] https://lore.kernel.org/r/20220823131629.RFT.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeid

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ