Received-SPF: pass (google.com: domain of linux-kernel+bounces-178904-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <ZjpMeVk_HiixZUEu@hovoldconsulting.com> <20240514140446.706847-1-quic_skakitap@quicinc.com>
 <CAHp75VcfYuukpLg=F36ykddsT9SpfdGNyyvVeyw-Yvz61Lrq7g@mail.gmail.com> <0a372307-8887-ac97-54c6-d6080e64540f@quicinc.com>
In-Reply-To: <0a372307-8887-ac97-54c6-d6080e64540f@quicinc.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Tue, 14 May 2024 19:04:58 +0300
Message-ID: <CAHp75VddpSz9Z785ey1FfgDMPD-zY8gesrqD1rt8yGdc9Pz-PQ@mail.gmail.com>
Subject: Re: [PATCH 12/13] regulator: add pm8008 pmic regulator driver
To: "Satya Priya Kakitapalli (Temp)" <quic_skakitap@quicinc.com>
Cc: johan@kernel.org, andersson@kernel.org, broonie@kernel.org, 
	conor+dt@kernel.org, devicetree@vger.kernel.org, johan+linaro@kernel.org, 
	konrad.dybcio@linaro.org, krzk+dt@kernel.org, lee@kernel.org, 
	lgirdwood@gmail.com, linus.walleij@linaro.org, linux-arm-msm@vger.kernel.org, 
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, robh@kernel.org, 
	swboyd@chromium.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2024 at 6:05=E2=80=AFPM Satya Priya Kakitapalli (Temp)
<quic_skakitap@quicinc.com> wrote:
> On 5/14/2024 7:48 PM, Andy Shevchenko wrote:
> > On Tue, May 14, 2024 at 5:05=E2=80=AFPM Satya Priya Kakitapalli
> > <quic_skakitap@quicinc.com> wrote:
> >>> On Thu, May 09, 2024 at 03:07:02PM +0300, Andy Shevchenko wrote:
> >>>> Wed, May 08, 2024 at 10:37:50PM +0000, Stephen Boyd kirjoitti:
> >>>>> Quoting Johan Hovold (2024-05-06 08:08:29)

..

> >>>>>> +               BUILD_BUG_ON((ARRAY_SIZE(pldo_ranges) !=3D 1) ||
> >>>>> This should be an && not || right?
> >>>>>> +                               (ARRAY_SIZE(nldo_ranges) !=3D 1));
> >>>> In any case BUILD_BUG_ON() is not encouraged for such cases, it woul=
d be much
> >>>> better to have a static_assert() near to one of those arrays.
> >>> I think the reason it is placed here is that the above line reads:
> >>>
> >>>        rdesc->n_linear_ranges =3D 1;
> >>>
> >>> and that would need to change if anyone expands the arrays.
> >> Correct. static_assert() cannot be used in the middle of code here, it=
 can only be used at the declarations part which doesn't serve the purpose.
> > I didn't get this. The ARRAY_SIZE():s are defined at compile time
> > globally. How does this prevent from using static_assert()?

> The reason we added it here is to make sure the nlod_ranges and
> pldo_ranges doesn't become larger, and we forget updating the
> n_linear_ranges.

> Adding static_assert here is not feasible so adding a
> BUILD_BUG_ON at this point makes sure the n_linear_ranges is proper.

No, static_assert() will do _exactly_ the same with better error
reporting and location, but what you are trying to say is that the
location is chosen to be near to the n_liner_ranges assignment which
happens at runtime, that's why it can't be used as an argument to
BUILD_BUG_ON(). Based on this discussion I think the comment is
missing before BUILD_BUG_ON() to explain the semantics of 1 and all
that was just said.

> >> So, BUILD_BUG_ON is the only way to go here.
> > I don't think so.

As i said.

--=20
With Best Regards,
Andy Shevchenko