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: <20230515160026.ynqsgu4wvsqxnj2h@ripper>
Date:   Mon, 15 May 2023 09:00:26 -0700
From:   Bjorn Andersson <andersson@...nel.org>
To:     Amit Pundir <amit.pundir@...aro.org>
Cc:     Douglas Anderson <dianders@...omium.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert "regulator: qcom-rpmh: Revert "regulator:
 qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS""

On Mon, May 15, 2023 at 08:23:23PM +0530, Amit Pundir wrote:
> This reverts commit ad44ac082fdff7ee57fe125432f7d9d7cb610a23.
> 
> This patch restores the synchronous probing for
> qcom-rpmh-regulator because asynchronous probing broke
> Dragonboard 845c (SDM845) running AOSP. UFSHC fail to
> initialize properly and DB845c fails to boot regardless
> of "rootwait" bootarg being present or not
> https://bugs.linaro.org/show_bug.cgi?id=5975.
> 

Looking at the first attachment, I would suggest that UFS fails because
it's not able to get hold of its regulators, just as any other device
with supplies would.

The typical cause for rpmh timeouts is that you're no longer able to
talk to the rpmh. Could you please attempt to trace the system and see
what's happening in parallel that would cause such issue.

Also note that such issues often also results in UFS timeouts, which
results in the familiar UFS debug dumps.


In the second log, the system crashes 51 seconds after rpmh probes,
around the time where other sync_state is happening. This too would seem
related to missing resource votes, but I would expect being a separate
issue.

PS. this is a patch in the regulator code, but I don't see Mark in the
recipients list...

Regards,
Bjorn

> Signed-off-by: Amit Pundir <amit.pundir@...aro.org>
> ---
>  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 b0a58c62b1e2..30659922b0aa 100644
> --- a/drivers/regulator/qcom-rpmh-regulator.c
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
> @@ -1517,7 +1517,7 @@ MODULE_DEVICE_TABLE(of, rpmh_regulator_match_table);
>  static struct platform_driver rpmh_regulator_driver = {
>  	.driver = {
>  		.name = "qcom-rpmh-regulator",
> -		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> +		.probe_type = PROBE_FORCE_SYNCHRONOUS,
>  		.of_match_table	= of_match_ptr(rpmh_regulator_match_table),
>  	},
>  	.probe = rpmh_regulator_probe,
> -- 
> 2.25.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ