linux-kernel - Re: [PATCH 3/5] arm64: dts: qcom: sm6125-seine: Provide regulators to SDHCI 1

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]

Message-ID: <20221223130813.qk7thawdueugb5z4@SoMainline.org>
Date:   Fri, 23 Dec 2022 14:08:13 +0100
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     phone-devel@...r.kernel.org,
        Bjorn Andersson <andersson@...nel.org>,
        ~postmarketos/upstreaming@...ts.sr.ht,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Martin Botka <martin.botka@...ainline.org>,
        Jami Kettunen <jami.kettunen@...ainline.org>,
        Andy Gross <agross@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] arm64: dts: qcom: sm6125-seine: Provide regulators
 to SDHCI 1

On 2022-12-23 13:00:18, Konrad Dybcio wrote:
> 
> 
> On 22.12.2022 21:36, Marijn Suijten wrote:
> > While SDHCI 1 appears to work out of the box, we cannot rely on the
> > bootloader-enabled regulators nor expect them to remain enabled (e.g.
> > when finally dropping pd_ignore_unused).
>
> Unrelated, unused-yet-enabled (as far as Linux is concerned, anyway,
> it doesn't know the state of smd rpm regulators unless you add
> regulator-boot-on) regulators get swept by "regulator cleanup".

That's exactly the point made here: at least this way Linux knows that
these regulators should remain enabled.  Even if it doesn't know about
many others and would fall flat on its face regardless when disabling
others as part of regulator cleanup.

Unless you meant something different?

- Marijn