On 11/15/2022 1:57 AM, Doug Anderson wrote:
Hi,
On Mon, Nov 14, 2022 at 11:41 AM Rob Clark <robdclark@xxxxxxxxx> wrote:
From: Rob Clark <robdclark@xxxxxxxxxxxx>
If we get an error (other than -ENOENT) we need to propagate that up the
stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
whatever OPP(s) are represented by bit zero.
Can you explain the "whatever OPP(s) are represented by bit zero"
part? This doesn't seem to be true because `supp_hw` is initiated to
UINT_MAX. If I'm remembering how this all works, doesn't that mean
that if we get an error we'll assume all OPPs are OK?
I'm not saying that I'm against your change, but I think maybe you're
misdescribing the old behavior.
Speaking of the initialization of supp_hw, if we want to change the
behavior like your patch does then we should be able to remove that
initialization, right?
I would also suspect that your patch will result in a compiler
warning, at least on some compilers. The goto label `done` is no
longer needed, right?
-Doug
You are right about the commit message. The problem is we can't enable
all bits in supp_hw anymore due to changes like this:
https://patchwork.kernel.org/project/linux-arm-msm/patch/20220829011035.1.Ie3564662150e038571b7e2779cac7229191cf3bf@changeid/
This creates 2 opps with same freq when supp_hw = UINT_MAX.
-Akhil.
