Re: [PATCH] regulator: qcom-rpmh: Revert "regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS"

From: Linux regression tracking #adding (Thorsten Leemhuis)
Date: Sun May 14 2023 - 07:57:22 EST


[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 13.05.23 20:08, Amit Pundir wrote:
> On Fri, 24 Mar 2023 at 19:05, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
>>
>> This reverts commit 58973046c1bf ("regulator: qcom-rpmh: Use
>> PROBE_FORCE_SYNCHRONOUS"). Further digging into the problems that
>> prompted the us to switch to synchronous probe showed that the root
>> cause was a missing "rootwait" in the kernel command line
>> arguments. Let's reinstate asynchronous probe.
>
> Hi, the asynchronous probe is broken on Dragonboard 845c (SDM845)
> running AOSP (Android Open Source Project) with v6.4-rc1
> https://bugs.linaro.org/show_bug.cgi?id=5975.
> Can we please go back to synchronous probe.
>
> AOSP do not make use of rootwait, IIRC, but it is added by the
> bootloader anyway. And the device fails to boot AOSP regardless of
> "rootwait" bootarg being present or not.
>
> FWIW I do not see this regression on RB5 (QRB5165/SM8250) running the
> same set of AOSP images.

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced ad44ac082fd
#regzbot title regulator: qcom-rpmh: Dragonboard 845c broken due to
asynchronous probe
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

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
That page also explains what to do if mails like this annoy you.

>> Fixes: 58973046c1bf ("regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS")
>> Cc: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
>> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
>> ---
>>
>> drivers/regulator/qcom-rpmh-regulator.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
>> index 903032b2875f..4826d60e5d95 100644
>> --- a/drivers/regulator/qcom-rpmh-regulator.c
>> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>> @@ -1462,7 +1462,7 @@ MODULE_DEVICE_TABLE(of, rpmh_regulator_match_table);
>> static struct platform_driver rpmh_regulator_driver = {
>> .driver = {
>> .name = "qcom-rpmh-regulator",
>> - .probe_type = PROBE_FORCE_SYNCHRONOUS,
>> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>> .of_match_table = of_match_ptr(rpmh_regulator_match_table),
>> },
>> .probe = rpmh_regulator_probe,
>> --
>> 2.40.0.348.gf938b09366-goog
>>