Re: [RFC PATCH 1/4] regulator: core: Ensure the cached state matches the hardware state in regulator_set_voltage_unlocked()

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On Thu, Jun 06, 2024 at 03:12:42PM +0100, Lad, Prabhakar wrote:
> On Thu, Jun 6, 2024 at 1:05 PM Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Jun 05, 2024 at 08:49:33AM +0100, Prabhakar wrote:

> > > Driver code flow:
> > > 1> set regulator to 1.8V (BIT0 = 1)
> > > 2> Regulator cached state now will be 1.8V
> > > 3> Now for some reason driver issues a reset to the IP block
> > >    which resets the registers to default value. In this process
> > >    the regulator is set to 3.3V (BIT0 = 0)
> > > 4> Now the driver requests the regulator core to set 1.8V

> > If something is resetting the regulator like this that's a problem in
> > general, we need to either have the driver notify the core when that
> > happens so it can reconfigure the regulator or have it reapply
> > configuration directly.  Obviously it's not great to have that happen at
> > all...

> Currently I am seeing this problem with SDHI driver. For the voltage
> switch operation the MMC core requests the driver to do the change and
> similarly the MMC core requests the reset operation.

> > Having the core driver notify the core when that happens so it can reconfigure the regulator or have it reapply configuration directly.

> Again doing this would be a problem as MMC core also maintains the IOS
> states, reconfiguring the regulator would cause conflicts between the
> states.

If the device can't cope with the requested configuration being applied
why is this going through the regulator API at all?  This just seems
quite confused, putting a bodge in the core like this clearly isn't the
right solution.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]