Re: [PATCH] regulator: core: Clean up on enable failure

[Andrew Halaney]

On Fri, Aug 19, 2022 at 04:03:24PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Aug 19, 2022 at 3:48 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> >
> > On Fri, Aug 19, 2022 at 02:43:36PM -0500, Andrew Halaney wrote:
> >
> > > -     if (regulator->uA_load && regulator->enable_count == 1)
> > > -             return drms_uA_update(rdev);
> > > +     if (regulator->uA_load && regulator->enable_count == 1) {
> > > +             ret = drms_uA_update(rdev);
> >
> > I am vaugely surprised and a bit concerned that drms_uA_update() can
> > fail...
> 
> In his original email Andrew implied that his system was misconfigured
> when he was seeing this error. I presume this isn't common which is
> why nobody had noticed this before now, but given that the function
> drms_uA_update() does return an error code it seems like we should
> handle it properly in the caller.

Doug was right, I thought my devicetree was bad. But after spending the
morning trying to write a reply about why exactly it was bad, I realized
that it might not be that. I agree with him that this patch makes sense
(to me at least) regardless.

Here I am reporting on how a recent change in qcom-rpmh-regulator.c made
this appear (no idea yet if the change is at fault, or if I've got some
other misconfiguration though in my devicetree!):

    https://lore.kernel.org/all/20220822193153.zn2oxljmd76awqot@halaneylaptop/

Thanks,
Andrew