[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y5xVHU5FBr5qzAOs@hirez.programming.kicks-ass.net>
Date: Fri, 16 Dec 2022 12:23:09 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Robert Foss <robert.foss@...aro.org>,
Todor Tomov <todor.too@...il.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Arnd Bergmann <arnd@...db.de>, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Jonathan Marek <jonathan@...ek.ca>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: camss: csiphy-3ph: avoid undefined behavior
On Thu, Dec 15, 2022 at 05:28:46PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> Marking a case of the switch statement as unreachable means the
> compiler treats it as undefined behavior, which is then caught by
> an objtool warning:
>
> drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.o: warning: objtool: csiphy_lanes_enable() falls through to next function csiphy_lanes_disable()
>
> Instead of simply continuing execution at a random place of the
> driver, print a warning and return from to the caller, which
> makes it possible to understand what happens and avoids the
> warning.
>
> Fixes: 53655d2a0ff2 ("media: camss: csiphy-3ph: add support for SM8250 CSI DPHY")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index 451a4c9b3d30..04baa80494c6 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -429,7 +429,8 @@ static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
> array_size = ARRAY_SIZE(lane_regs_sm8250[0]);
> break;
> default:
> - unreachable();
> + WARN(1, "unknown cspi version\n");
> + return;
> }
So no real objection here; but unreachable() does have an objtool
annotation inside, so clearly the compiler managed to defeat that --
perhaps we should look at that too.
Powered by blists - more mailing lists