[PATCH] regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS

[PATCH] regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS

[Marek Szyprowski]

Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
otherwise the UFSHC device is not properly initialized on QRB5165-RB5
board.

Fixes: ed6962cc3e05 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 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 4826d60e5d95..903032b2875f 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_PREFER_ASYNCHRONOUS,
+		.probe_type = PROBE_FORCE_SYNCHRONOUS,
 		.of_match_table	= of_match_ptr(rpmh_regulator_match_table),
 	},
 	.probe = rpmh_regulator_probe,
-- 
2.34.1

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

[Doug Anderson]

Hi,

On Thu, Mar 23, 2023 at 3:05 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
> otherwise the UFSHC device is not properly initialized on QRB5165-RB5
> board.
>
> Fixes: ed6962cc3e05 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/regulator/qcom-rpmh-regulator.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I don't object to this patch landing temporarily, but can you provide
any more details, please? On Qualcomm Chromebooks I'm not seeing any
issues with RPMH regulators probing asynchronously, so I can only
assume that there's a bug in the UFSHC driver that's being tickled.

-Doug

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

[Mark Brown]

On Thu, 23 Mar 2023 23:05:18 +0100, Marek Szyprowski wrote:
> Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
> otherwise the UFSHC device is not properly initialized on QRB5165-RB5
> board.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS
      commit: 58973046c1bf782cac01644a9dcd8e5bba9c2f16

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

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

[Marek Szyprowski]

Hi,

On 23.03.2023 23:08, Doug Anderson wrote:
> On Thu, Mar 23, 2023 at 3:05 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
>> otherwise the UFSHC device is not properly initialized on QRB5165-RB5
>> board.
>>
>> Fixes: ed6962cc3e05 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19")
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>>   drivers/regulator/qcom-rpmh-regulator.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> I don't object to this patch landing temporarily, but can you provide
> any more details, please? On Qualcomm Chromebooks I'm not seeing any
> issues with RPMH regulators probing asynchronously, so I can only
> assume that there's a bug in the UFSHC driver that's being tickled.

You are right. I've analyzed this case further and it turned out that it 
was my fault. In short - 'rootwait' kernel cmdline parameter was missing 
and root was specified as '/dev/sda7'.

UFSHC driver properly retried probing after it cannot get its 
regulators, but it happened at the same time when kernel tried to mount 
rootfs. I was confused that this is really a regulator issue, because 
the mentioned /dev/sda* devices were properly reported as available in 
the system in the root mounting failure message, but adding the 
'rootwait' cmdline parameter fixed this problem. It would be safe to 
revert this change. I'm really sorry for the false report and the noise.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[Andrew Halaney]

On Fri, Mar 24, 2023 at 12:18:53PM +0100, Marek Szyprowski wrote:
> Hi,
> 
> On 23.03.2023 23:08, Doug Anderson wrote:
> > On Thu, Mar 23, 2023 at 3:05 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
> >> otherwise the UFSHC device is not properly initialized on QRB5165-RB5
> >> board.
> >>
> >> Fixes: ed6962cc3e05 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19")
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> ---
> >>   drivers/regulator/qcom-rpmh-regulator.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > I don't object to this patch landing temporarily, but can you provide
> > any more details, please? On Qualcomm Chromebooks I'm not seeing any
> > issues with RPMH regulators probing asynchronously, so I can only
> > assume that there's a bug in the UFSHC driver that's being tickled.
> 
> You are right. I've analyzed this case further and it turned out that it 
> was my fault. In short - 'rootwait' kernel cmdline parameter was missing 
> and root was specified as '/dev/sda7'.
> 
> UFSHC driver properly retried probing after it cannot get its 
> regulators, but it happened at the same time when kernel tried to mount 
> rootfs. I was confused that this is really a regulator issue, because 
> the mentioned /dev/sda* devices were properly reported as available in 
> the system in the root mounting failure message, but adding the 
> 'rootwait' cmdline parameter fixed this problem. It would be safe to 
> revert this change. I'm really sorry for the false report and the noise.
> 

It looks like this got applied, but reading your above message makes it
seem like this patch is not necessary. Did I understand that correctly?

If so we should see if Mark can drop / revert it?

Thanks,
Andrew

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

[Doug Anderson]

Hi,

On Fri, Mar 24, 2023 at 7:12 AM Andrew Halaney <ahalaney@redhat.com> wrote:
>
> On Fri, Mar 24, 2023 at 12:18:53PM +0100, Marek Szyprowski wrote:
> > Hi,
> >
> > On 23.03.2023 23:08, Doug Anderson wrote:
> > > On Thu, Mar 23, 2023 at 3:05 PM Marek Szyprowski
> > > <m.szyprowski@samsung.com> wrote:
> > >> Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
> > >> otherwise the UFSHC device is not properly initialized on QRB5165-RB5
> > >> board.
> > >>
> > >> Fixes: ed6962cc3e05 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19")
> > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > >> ---
> > >>   drivers/regulator/qcom-rpmh-regulator.c | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > > I don't object to this patch landing temporarily, but can you provide
> > > any more details, please? On Qualcomm Chromebooks I'm not seeing any
> > > issues with RPMH regulators probing asynchronously, so I can only
> > > assume that there's a bug in the UFSHC driver that's being tickled.
> >
> > You are right. I've analyzed this case further and it turned out that it
> > was my fault. In short - 'rootwait' kernel cmdline parameter was missing
> > and root was specified as '/dev/sda7'.
> >
> > UFSHC driver properly retried probing after it cannot get its
> > regulators, but it happened at the same time when kernel tried to mount
> > rootfs. I was confused that this is really a regulator issue, because
> > the mentioned /dev/sda* devices were properly reported as available in
> > the system in the root mounting failure message, but adding the
> > 'rootwait' cmdline parameter fixed this problem. It would be safe to
> > revert this change. I'm really sorry for the false report and the noise.
> >
>
> It looks like this got applied, but reading your above message makes it
> seem like this patch is not necessary. Did I understand that correctly?
>
> If so we should see if Mark can drop / revert it?

Ah, sorry. I didn't reply with breadcrumbs. The revert is at:

https://lore.kernel.org/r/20230324063357.1.Ifdf3625a3c5c9467bd87bfcdf726c884ad220a35@changeid

-Doug