Re: [PATCH v5 3/4] regulator: qcom-rpmh: readback voltage/bypass/mode/status set during bootup

From: Kamal Wadhwa

Date: Wed Jul 29 2026 - 15:49:12 EST


On Fri, Jul 24, 2026 at 01:48:30PM +0100, Mark Brown wrote:
> On Fri, Jul 24, 2026 at 04:13:02PM +0530, Kamal Wadhwa wrote:
> > On Wed, Jul 22, 2026 at 05:46:37PM +0100, Mark Brown wrote:
>
> > > A get_status() operation should be reading the actual hardware status
> > > right now, not driver state - this should be reading whatever the value
> > > is right now. If the hardware doesn't support this then just don't
> > > provide the operation.
>
> > Actually we are reading from HW what we voted in terms of ENABLE/BYPASS/MODE
> > and we are combing these in the `rpmh_regulator_determine_initial_status()`
> > to come up with the `vreg->status`at the time of probe.
>
> No, that's not the point. A get_status() operation needs to return the
> actual hardware status *now*, not a cached value from some random time
> in the past and not something that was written by the driver.

I can drop it. But I seek your guidance on how should i implement logic
to HOLD the enable/voltage/mode for the regulators which are turned ON by
bootloader.

we need this for shared regulators, to avoid a race between clients
probes to badly impact a client which needed the rail to hold its
mode/voltage/enable state before its probe is called.

I was planning to use get_status() (in a subsequent patch series) to check if
the rail was left ON by bootloader at the regulator registration stage, and
use that criteria to decide if we need to hold the voltage/mode/enable state
or not.

Besides this, since the sync_state() cannot be used.. i was thinking if holding
the voltage/mode/enable till regulator_late_cleanup(). is that ok?

Would really appriciate your help, if you can guide me in some direction..
Thanks in advance!

>
> > So, shall I read the HW MODE/BYPSS/ENABLE value in every get_status() call?
>
> If they reflect values that might be dynamically updated by the
> hardware, yes. If they are just control registers that the hardware
> will not update autonomously they are not suitable for a get_status()
> operation.

It not will autonomously update, but it may be updated by the APPS bootloader.
I guess, that still would make it unsuitable to be used in get_status() ?

Regards,
Kamal