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

[Mike Looijmans <mike.looijmans@topic.nl>]

On 06-11-2026 22:45, Martin Blumenstingl wrote:
> On Fri, Nov 6, 2026 at 2:46 PM Mark Brown <broonie@kernel.org> 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