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

[Kamal Wadhwa]

On Wed, Apr 29, 2026 at 08:15:20AM +0900, Mark Brown wrote:
> On Wed, Apr 29, 2026 at 03:03:31AM +0530, Kamal Wadhwa wrote:
> 
> > To elaborate, till now for all chipsets using RPMH regulator driver, the boot
> > time voltage setting would always be overwritten by `min-microvolts` by the
> > framework. However, i found during the development of this patch that on some
> > chipsets like SM8550, SM8660 etc for one or two rails there exists some
> > misalignments between the bootloader voltage setting and the APPS side min/max
> > voltage limits(subset of RPMH firmware min/max) where the voltage value is
> > set lower or higher from the bootloader side compared to the DT min/max, which
> > caused the regulator registeration failure and all the sibling regulators under
> > the same pmic will also fail to register, even though issue was with only one
> > regulator.
> 
> Why would this cause registration failures?  Bringing the voltage in
> line with the constraints is a perfectly normal and fairly widely used
> operation.

(Very sorry for coming back late on this)
I looked up for some examples of the regulator probe failures i faced during
development of this patch.

It seems that regulator registration failures happen after adding the read
support ONLY if both of the conditions below are true for any regulator.

	1. The [min or max]-microvolts values defined in the device tree didn’t
	   exactly match with any of the  selector voltages supported by the
  	   regulator.
	2. On top of this, if the initial value read is out-of-range of the
	   DT min,max limit.

eg-

For board file(s) /arch/arm64/boot/dts/qcom/sm8550-*.dts, I found
that the voltage set during the boot stage for `vreg_l6n_3p3`
was 3312mV, which didn't match with the max-microvolts of `3304mV`
(which is the max enforced from RPMH firmware) and when i added this new
patch the  regulator registration for L6N failed, and caused the probe to
fail.

Note - This we had fixed by reducing the regulator min-microvolts to 3200mV.

But since these error is getting unmasked only if we added get_voltage_sel()
support, so wanted to check if its ok to print these as errors, and do not
report voltage values out of [min, max] range and avoid the regulator
registration failures?

pleae note that, currently if one regulator registration fails, driver
will not register any other regulator and probe will exit with failure.

Debugging such issues will be simplified if we can know where the mismatch
happened with the error logs, and not have to do repeat testing multiple
times to fix (one-by-one) the firmware side mismatch between the boot and
rpmh firmware voltage values.

Regards,
Kamal