[PATCH 1/2] regulator: fix handling of off_on_delay

[Sascha Hauer]

On Thu, Jan 29, 2026 at 01:06:53PM +0100, Marco Felsch wrote:
> On 26-01-29, Sascha Hauer wrote:
> > In Linux the off_on_delay field in a regulator is described as:
> > 
> > > The guard time (in uS), before re-enabling a regulator
> > 
> > The primary user is the fixed regulator which puts the value of
> > the "off-on-delay-us" property into it.
> > 
> > In barebox we put the off_on_delay into the enable_time_us field
> > which is the delay we introduce when turning on a regulator. This
> > is wrong and fixed in this commit.
> > 
> > The off_on_delay is defined as the time we should take before
> > re-enabling a regulator. Linux does it the complicated way of
> > remembering the time when it was last disabled and delays the
> > re-enabling if necessary. We use the simple approach here of
> > just waiting the off_on_delay time in the regulator disable path.
> > 
> > Fixes: 26a4c78917 ("regulator: add support for struct regulator_desc::off_on_delay")
> > Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> > ---
> >  drivers/regulator/core.c | 5 ++++-
> >  include/regulator.h      | 1 +
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index cd07955894..8ca937e8bd 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -96,6 +96,9 @@ static int regulator_disable_rdev(struct regulator_dev *rdev)
> >  
> >  	rdev->enable_count--;
> >  
> > +	if (rdev->off_on_delay)
> > +		udelay(rdev->off_on_delay);
> > +
> >  	return regulator_disable(rdev->supply);
> >  }
> >  
> > @@ -309,7 +312,7 @@ int of_regulator_register(struct regulator_dev *rdev, struct device_node *node)
> >  	node->dev = rdev->dev;
> >  
> >  	if (rdev->desc->off_on_delay)
> > -		rdev->enable_time_us = rdev->desc->off_on_delay;
> 
> Nit: is is worth to remove the enable_time_us completely and
> re-introduce it within the next commit?

I think so, yes. I could have merged it into a single commit, but I
think this way makes it clearer what happens despite the intermediate
breakage

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |