[PATCH v3 3/6] regulator: core: Add helper for allow access to enable register
Biju Das
biju.das.jz at bp.renesas.com
Tue Jun 11 09:28:37 PDT 2024
Hi Mark Brown,
Thanks for the feedback.
> -----Original Message-----
> From: Mark Brown <broonie at kernel.org>
> Sent: Tuesday, June 11, 2024 4:00 PM
> Subject: Re: [PATCH v3 3/6] regulator: core: Add helper for allow access to enable register
>
> On Tue, Jun 11, 2024 at 12:03:59PM +0100, Biju Das wrote:
> > Add a helper function that allow regulator consumers to allow
> > low-level enable register access, in order to enable/disable regulator
> > in atomic context.
>
> > +To access the hardware register for enabling/disabling the regulator, use::
> > +
> > + int regulator_set_hardware_enable_register(struct regulator *regulator,
> > + bool enable);
>
> So, it'll doubtless not be a surprise that I'm not thrilled with this - it's basically just
> punching a hole straight through all the locking and reference counting in a way that's just
> begging for abuse. At the very least we should have a check for exclusive access in there.
Do you mean exclusive access by means of spinlock to avoid race between enable/disable()?
If that is the case
Option1:
Add a spin_lock in struct regulator_dev and add locking in regulator_xxx_hardware_enable_xxx()
Option 2:
Core calls the callback for enable()/disable() and driver handles the exclusive access by
spin lock
or
Please share, if you have any other options?
>
> Also it's not sure about that name, if we were doing this it should be more describing the effect
What about the name regulator_hardware_enable() to make it generic??
> on the regulator rather than this happening to be done via a register write (this should also work
> for GPIOs...).
Do you mean to make it generic, so that it works for both regmap based enable/disable() as well as
gpio based enable()/disable()??
Cheers,
Biju
More information about the linux-phy
mailing list