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:   Fri, 4 Nov 2022 10:37:52 +0530
From:   Viresh Kumar <viresh.kumar@linaro.org>
To:     James Calligeros <jcalligeros99@gmail.com>
Cc:     linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, nm@ti.com,
        rafael@kernel.org, sboyd@kernel.org, vincent.guittot@linaro.org,
        vireshk@kernel.org
Subject: Re: [PATCH V2 5/5] OPP: decouple dt properties in
 opp_parse_supplies()
Message-ID: <20221104050752.67eh54ui2ohbbyni@vireshk-i7>
References: <cover.1667473008.git.viresh.kumar@linaro.org>
 <3519763.iIbC2pHGDl@makoto>
 <20221103131051.2ivkhibbsdarbewt@vireshk-i7>
 <2379445.NG923GbCHz@makoto>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2379445.NG923GbCHz@makoto>
Precedence: bulk

On 04-11-22, 01:23, James Calligeros wrote:
> >if (list_empty(&opp_table->opp_list) &&
> >    opp_table->regulator_count > 0) {

I did test this and it should have worked for you as well.

> >	dev_err(dev, "%s: opp-microvolt missing although OPP managing regulators\n",
> >		__func__);
> >	return ERR_PTR(-EINVAL);
> >}
> 
> When this path is removed, things work as expected. Could it be that opp_list has
> not been updated by the time we're parsing the next OPP? Seems unlikely, but
> at the same time if we're ending up taking this branch then there's not much else
> that could have gone wrong.

It should happen sequentially.

Ahh, I looked code for sometime before I wrote this line. I know what's going
on. Its a bug in the patchset that I fixed yesterday and pushed.

Initialize "ret = 0" in opp_parse_supplies().

Or pick patches from:

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git opp/linux-next

Sorry for the trouble.

-- 
viresh