Re: [PATCH 1/5] regulator: dt-bindings: Add regulator-boot-force-off property

[Paul Louvel]

Hi Mark,

On Thu Oct 22, 2026 at 2:22 PM CEST, Mark Brown wrote:
> On Wed, Oct 21, 2026 at 07:11:51PM +0200, Paul Louvel wrote:
>> On Wed Oct 21, 2026 at 7:01 PM CEST, Conor Dooley wrote:
>> > On Wed, Oct 21, 2026 at 12:27:42PM +0200, Paul Louvel wrote:
>
>> >> +  regulator-boot-force-off:
>> >> +    description: a regulator may be enabled by default when the system powers up.
>> >> +      A consumer may query the regulator's state during boot and disable it if
>> >> +      it is already enabled, potentially resulting in an unbalanced disable
>> >> +      operation. This property ensures that the regulator is disabled at boot,
>> >> +      regardless of its previous state.
>
>> > To be honest, I'm not sure how the commentary about querying the state
>> > or being unbalanced is relevant to the description - that sounds like
>> > something specific to the linux regulator framework?
>
> I'm fairly sure this is about masking some driver bug, a driver should
> never be disabling something it didn't enable.
>
>> Yes it is. Maybe I miss something, does this binding is used outside linux ?
>
> Pretty sure u-boot uses it.
>
>> > In fact, I'm not sure why this is needed at all? Can't you just change
>> > the software so that it is okay to disable a regulator that has an
>> > explicit enable count of zero?
>
>> Do you mean by calling regulator_force_disable() instead ? I thinked about that
>> but I don't think this is ideal.
>
> No, you should only be using that API for recovering from catastrophic
> hardware errors where you're cutting power to do something like
> preventing physical damange to the system and serious disruption to
> other users is an acceptable cost.

Then I think a straightforward solution without any core change would be to call
regulator_enable() and immediately follow it with regulator_disable() in the
consumer driver's probe function to ensure that the regulator is in a known
disabled state.

I have considered this solution, but it doesn't feel quite right either, but
neither does this patch.

Thanks,
-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com