linux-kernel - Re: [PATCH] regulator: qcom-rpmh: Revert "regulator: qcom-rpmh: Use PROBE_FORCE

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: <84110995-a99b-8b5a-cd34-8430866eb9b1@leemhuis.info>
Date:   Wed, 14 Jun 2023 17:37:01 +0200
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Doug Anderson <dianders@...omium.org>,
        Mark Brown <broonie@...nel.org>
Cc:     Amit Pundir <amit.pundir@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH] regulator: qcom-rpmh: Revert "regulator: qcom-rpmh: Use
 PROBE_FORCE_SYNCHRONOUS"

Hi, Thorsten here, the Linux kernel's regression tracker.

On 07.06.23 15:47, Doug Anderson wrote:
> 
> On Wed, Jun 7, 2023 at 6:18 AM Mark Brown <broonie@...nel.org> wrote:
>>
>> On Tue, Jun 06, 2023 at 04:29:29PM -0700, Doug Anderson wrote:
>>
>>> 2. Try adding some delays to some of the regulators with
>>> "regulator-enable-ramp-delay" and/or "regulator-settling-time-us".
>>> Without a scope, it'll be tricky to figure out exactly which
>>> regulators might need delays, but you could at least confirm if the
>>> "overkill" approach of having all the regulators have some delay
>>> helps... I guess you could also try putting a big delay for "ldo26".
>>> If that works, you could try moving it up (again using a bisect style
>>> approach) to see where the delay matters?
>>
>> This is information which should be in the datasheets for the part.
> 
> I was thinking more of something board-specific, not part specific. In
> theory with RPMH this is also all supposed to be abstracted out into
> the firmware code that sets up RPMH which magically takes care of
> things like this, but it certainly could be wrong.

/me waves friendly

That afaics was the last mail in this thread about a regression caused
by ad44ac082fd ("regulator: qcom-rpmh: Revert "regulator: qcom-rpmh: Use
PROBE_FORCE_SYNCHRONOUS"") from Doug; Amit's attempt to patch it (
https://lore.kernel.org/lkml/20230602161246.1855448-1-amit.pundir@linaro.org/
) also wasn't welcomed. Just like his earlier revert attempt
(https://lore.kernel.org/lkml/20230515145323.1693044-1-amit.pundir@linaro.org/
).

Does this mean this regression won't be addressed before 6.4 is
released? Or was there some progress and I just missed it? What should I
tell Linus in my next report?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke