[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bcf1004d-802a-4b48-9aab-0a4e39274037@sirena.org.uk>
Date: Tue, 14 Oct 2025 13:35:11 +0100
From: Mark Brown <broonie@...nel.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
linux-mediatek@...ts.infradead.org, lee@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, matthias.bgg@...il.com,
lgirdwood@...il.com, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
kernel@...labora.com, wenst@...omium.org,
igor.belwon@...tallysanemainliners.org
Subject: Re: [PATCH v8 4/9] regulator: Add support for MediaTek MT6363 SPMI
PMIC Regulators
On Tue, Oct 14, 2025 at 01:35:37PM +0200, AngeloGioacchino Del Regno wrote:
> Il 09/10/25 16:41, Nicolas Frattaroli ha scritto:
> > Just initialise ret to 0 at the start of the function scope when
> > you declare it. You've already missed an uninitialised use once,
> > and playing these branch games is just asking for more trouble
> > in the future. There's no micro-optimisation you're doing here,
> > clang produces the same assembly for both zero initialised and
> > the else branch version you're doing here.
> It's not about micro-optimization. Double initialization is a bad coding practice.
Yes, if you just set the value at the start of the function then the
compiler won't be able to tell if you messed up the logic somewhere
later. Sure, the warning is gone but that also includes cases where the
compiler is telling you about an actual problem.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists