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: <d0dfdfba-7a70-7d12-2c30-ad32b3f95bb8@linaro.org>
Date:   Wed, 7 Jun 2023 09:49:06 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Doug Anderson <dianders@...omium.org>,
        Amit Pundir <amit.pundir@...aro.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        regressions <regressions@...ts.linux.dev>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dt <devicetree@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: sdm845-db845c: Move LVS regulator nodes
 up

On 07/06/2023 01:34, Doug Anderson wrote:
> Hi,
> 
> On Fri, Jun 2, 2023 at 9:12 AM Amit Pundir <amit.pundir@...aro.org> wrote:
>>
>> Move lvs1 and lvs2 regulator nodes up in the rpmh-regulators
>> list to workaround a boot regression uncovered by the upstream
>> commit ad44ac082fdf ("regulator: qcom-rpmh: Revert "regulator:
>> qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS"").
>>
>> Without this fix DB845c fail to boot at times because one of the
>> lvs1 or lvs2 regulators fail to turn ON in time.
>>
>> Link: https://lore.kernel.org/all/CAMi1Hd1avQDcDQf137m2auz2znov4XL8YGrLZsw5edb-NtRJRw@mail.gmail.com/
>> Signed-off-by: Amit Pundir <amit.pundir@...aro.org>
>> ---
>>  arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 24 +++++++++++-----------
>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>> index e14fe9bbb386..df2fde9063dc 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
>> @@ -301,6 +301,18 @@ regulators-0 {
>>                 vdd-l26-supply = <&vreg_s3a_1p35>;
>>                 vin-lvs-1-2-supply = <&vreg_s4a_1p8>;
>>
>> +               vreg_lvs1a_1p8: lvs1 {
>> +                       regulator-min-microvolt = <1800000>;
>> +                       regulator-max-microvolt = <1800000>;
>> +                       regulator-always-on;
>> +               };
>> +
>> +               vreg_lvs2a_1p8: lvs2 {
>> +                       regulator-min-microvolt = <1800000>;
>> +                       regulator-max-microvolt = <1800000>;
>> +                       regulator-always-on;
>> +               };
>> +
>>                 vreg_s3a_1p35: smps3 {
>>                         regulator-min-microvolt = <1352000>;
>>                         regulator-max-microvolt = <1352000>;
>> @@ -381,18 +393,6 @@ vreg_l26a_1p2: ldo26 {
>>                         regulator-max-microvolt = <1200000>;
>>                         regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>                 };
>> -
>> -               vreg_lvs1a_1p8: lvs1 {
>> -                       regulator-min-microvolt = <1800000>;
>> -                       regulator-max-microvolt = <1800000>;
>> -                       regulator-always-on;
>> -               };
>> -
>> -               vreg_lvs2a_1p8: lvs2 {
>> -                       regulator-min-microvolt = <1800000>;
>> -                       regulator-max-microvolt = <1800000>;
>> -                       regulator-always-on;
>> -               };
> 
> This is a hack, but it at least feels less bad than reverting the
> async probe patch. I'll leave it to Bjorn to decide if he's OK with
> it. Personally, it feels like this would deserve a comment in the dts
> to document that these regulators need to be listed first.
> 
> Ideally, we could still work towards a root cause. I added a few more
> ideas to help with root causing in reply to the original thread about
> this.
> 
> https://lore.kernel.org/r/CAD=FV=UKyjRNZG-ED2meUAR9aXdco+AbUTHiKixTzjCkaJbjTg@mail.gmail.com/

We do not shape DTS based on given OS behavior. AOSP needs this, BSD
needs that and Linux needs something else. Next time someone will move
these regulators down because on his system probing is from end of list,
not beginning and he has the same problem.

No, really, are we going to reshuffle nodes because AOSP needs it?

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ