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

[Kamal Wadhwa]

On Wed, Jul 29, 2026 at 09:04:47PM +0100, Mark Brown wrote:
> 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?

We can cache it, but i was planning to add change in core,
which will require get_status() or something similar i think.

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

yes yes, it needs to be fixed in core.

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

May be we can allow the up-ing of voltage/mode to go through? but cache the
lowering requests for voltage/mode and apply them in regulator_late_cleanup()
so we are sure that there is more then sufficient power during this sensitive
phase. will that work?

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

Ok, so is there something similar to get_status() that i can use to pass on the
info to core (from the driver) that regulator state was ON at bootloader stage?

Regards,
Kamal