Re: [PATCH 0/4] regulator: qcom-rpmh: Support RPMH address reads and use it for rpmh-regulators

[Kamal Wadhwa]

On Tue, Apr 07, 2026 at 04:58:26AM +0300, Dmitry Baryshkov wrote:
> On Tue, Apr 07, 2026 at 03:44:57AM +0530, Kamal Wadhwa wrote:
> > This patch series adds a new `rpmh_read()` API to allow reading RPMH
> > addresses. Using this API enhances the RPMH regulator driver by adding
> > new `get_status()` callback to reflect the regulator status and also
> > readback the voltage/bypass/mode settings as they have been applied by
> > APPS during the bootloader stage, so regulator framework can get them
> > via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during
> > regulator registration.
> > 
> > This is needed because currently regulator framework does a unnecessary
> > write with `min-microvolt` DT setting for all the RPMH regulators during
> > regulator registration, because the first time after boot the value is
> > seen as -ENOTRECOVERABLE, as there is no option to read these regulator
> > settings.
> > 
> > With this change this unnecessary write can be avoided and regulator
> > framework gets a sense of the initial state set during the bootloader
> > stage for all regulator settings.
> > 
> > NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had
> > inquired about possible need for the use of the sync_state() to handle the
> > "multiple" client case - for maintaining the regulator settings till all
> > the clients are probed.
> > 
> > This case was not covered in my previous series and had originally planned
> > to do that series seperately. But after the discussion decided to merge
> > the 2 series as it seemed this would be a better approach. But after
> > working on sync_state change. I realized a basic issue with using
> > sync_state() for regulators - that its per-driver and not per-regulator
> > resource. But we needed a sync_state callback for each regulator seperately.
> > 
> > I had been experimenting with few ideas but seems its going to need more
> > time for me to close on the eqvivalent solution that has per-regulator
> > sync_state or something to that effect. So I thought to close on this 
> > series and attend to that seperately.
> > 
> > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@xxxxxxxxxxxxxxxx>
> > ---
> > Changes in v3:
> 
> If this is v3, why is not marked as such?

I'm so sorry! i have fixed version and sent again (ignore this series)
link - https://lore.kernel.org/all/20260407-read-rpmh-v3-v3-0-34079f92691c@xxxxxxxxxxxxxxxx/