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

[Mark Brown]

On Thu, Jul 30, 2026 at 01:11:36AM +0530, Kamal Wadhwa wrote:
> On Fri, Jul 24, 2026 at 01:48:30PM +0100, Mark Brown wrote:

> > 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.

You could cache the values currently written to the control interface?

> 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.

That's logic that should be implemented in the core rather than driver
specific, this is an issue that affects everything - we just mostly get
away with it since we don't start touching things until drivers do so.
It's a real problem, just tough to solve.

> 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?

Consider what happens if something really needs a voltage raising to
enumerate - if you ignore it then the hardware might be in for a bad
time.

> > > 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() ?

Will the bootloader be running at the same time as the kernel, I really
mean "by something else" rather than "autonomously" - usually that's the
device itself (eg, reporting that a regulator was shut down due to over
current) but it could be something else I guess.

Attachment: signature.asc
Description: PGP signature