Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 22 Aug 2022 14:42:09 -0500
From:   Andrew Halaney <ahalaney@redhat.com>
To:     Doug Anderson <dianders@chromium.org>
Cc:     Mark Brown <broonie@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>, bmasney@redhat.com
Subject: Re: [PATCH] regulator: core: Clean up on enable failure
Message-ID: <20220822194209.b7mpb3wgvqwjybg5@halaneylaptop>
References: <20220819194336.382740-1-ahalaney@redhat.com>
 <YwATSglfJEgG6V73@sirena.org.uk>
 <CAD=FV=UWn8a9C3j0Ky9JWqo_2AvOE=ORVP94zHftGQLsxFdXyw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD=FV=UWn8a9C3j0Ky9JWqo_2AvOE=ORVP94zHftGQLsxFdXyw@mail.gmail.com>
Precedence: bulk

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@kernel.org> 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