Re: [PATCH 2/2] regulator: pwm-regulator: Revert "Add validity checks in continuous .get_voltage"

[Mike Looijmans]

On 06-11-2026 22:45, Martin Blumenstingl wrote:
> On Fri, Nov 6, 2026 at 2:46 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> > On Fri, Nov 06, 2026 at 01:59:56PM +0100, Mike Looijmans wrote:
> > > This reverts commit c92688cac239 ("regulator: pwm-regulator: Add validity
> > > checks in continuous .get_voltage").
> > And again...  please don't try to sneak changes past people :/
> Thank you for looping me in, Mark!
>
> > > The core, and in particular the machine_constraints_voltage() method,
> > > expects the regulator to report what the current setting is, even if that
> > > is outside the allowed range. The core will then bring the voltage into
> > > that range. It cannot do that if the regulator refuses to return its
> > > setting, and causes probe() to fail for a pwm-regulator when it has
> > > restrictions to the PWM range with messages like:
> > >    dsp7-pwm: failed to get the current voltage: -ENOTRECOVERABLE
> > >    pwm-regulator dsp7-supply-pwm: error -ENOTRECOVERABLE: Failed to register
> > >      regulator pwm-regulator
> > >    pwm-regulator dsp7-supply-pwm: probe with driver pwm-regulator failed
> > >      with error -131
> > >
> > > Besides that, regulator_get_voltage() is not supposed to return any
> > > state information, as is mentioned in the API documentation.
> according to include/linux/regulator/driver.h:
>   * @get_voltage: Return the currently configured voltage for the regulator;
>   *                   return -ENOTRECOVERABLE if regulator can't be read at
>   *                   bootup and hasn't been set yet.
>
> Can you please specify which API documentation you are referring to?

https://docs.kernel.org/driver-api/regulator.html#c.regulator_get_voltage

And the text above clearly states "can't be read at bootup and hasn't 
been set yet", which is not the same as "whenever it's set out of range".


> I believe back when this change was authored it didn't make a
> difference on my board (but made sense based on review feedback).
> So I'm not against reverting as long as we have a proper explanation
> why the original patch is incorrect.
>
>
> Best regards,
> Martin


--
Mike Looijmans