From: Herve Codina <herve.codina@bootlin.com>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Linus Walleij <linusw@kernel.org>,
Frieder Schrempf <frieder.schrempf@kontron.de>,
Marek Vasut <marex@denx.de>, Esben Haabendal <esben@geanix.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()
Date: Thu, 16 Jul 2026 19:09:01 +0200 [thread overview]
Message-ID: <20260716190901.29f44aea@bootlin.com> (raw)
In-Reply-To: <178421534408.28815.5022512273977369395.b4-review@b4>
Hi Luca, Esben,
On Thu, 16 Jul 2026 17:22:24 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> On Wed, 15 Jul 2026 15:10:32 +0200, Esben Haabendal <esben@geanix.com> wrote:
>
> Hi Esben,
>
> +Cc Hervé
>
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > index b4b220eee790..7e73035d7798 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > @@ -419,11 +419,12 @@ static void sn65dsi83_reset_work(struct work_struct *ws)
> > ret = sn65dsi83_reset_pipe(ctx);
> > if (ret) {
> > dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret));
> > - return;
> > + goto err_exit;
> > }
>
> This looked like a nasty bug! But it is not, out of pure luck. As sashiko
> noticed:
>
> | sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
> |
> | [Severity: High]
> | This isn't a bug introduced by this patch, but is this error handling block
> | actually dead code?
> |
> | Looking at sn65dsi83_reset_pipe(), it appears to unconditionally return 0,
> | even if drm_bridge_helper_reset_crtc() returns an error like -EINVAL or
> | -ENOMEM:
>
> So perhaps we should just remove the dead code, and also make
> sn65dsi83_reset_pipe() return void.
>
I would keep an error code from sn65dsi83_reset_pipe() but change its code
from
---- 8< ----
retry:
err = drm_bridge_helper_reset_crtc(&sn65dsi83->bridge, &ctx);
if (err == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
}
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
return 0;
---- 8< ----
to
---- 8< ----
retry:
err = drm_bridge_helper_reset_crtc(&sn65dsi83->bridge, &ctx);
if (err == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
}
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
return err;
---- 8< ----
Indeed, if drm_bridge_helper_reset_crtc() fails, we can consider that
sn65dsi83_reset_pipe() fails.
With that done, Esben's modification is still relevant (i.e. goto err_exit
on failure).
Best regards,
Hervé
next prev parent reply other threads:[~2026-07-16 17:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 13:10 [PATCH v2 0/3] drm/bridge: ti-sn65dsi83: Various fixes Esben Haabendal
2026-07-15 13:10 ` [PATCH v2 1/3] drm/bridge: ti-sn65dsi83: Fix problem with premature PLL locking Esben Haabendal
2026-07-15 13:32 ` sashiko-bot
2026-07-15 13:10 ` [PATCH v2 2/3] drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() Esben Haabendal
2026-07-15 13:21 ` sashiko-bot
2026-07-16 15:22 ` Luca Ceresoli
2026-07-16 17:09 ` Herve Codina [this message]
2026-07-15 13:10 ` [PATCH v2 3/3] drm/bridge: ti-sn65dsi83: Support LVDS Channel B on SN65DSI84 Esben Haabendal
2026-07-15 13:18 ` sashiko-bot
2026-07-16 15:22 ` Luca Ceresoli
2026-07-16 16:03 ` Esben Haabendal
2026-07-16 17:03 ` Luca Ceresoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716190901.29f44aea@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=esben@geanix.com \
--cc=frieder.schrempf@kontron.de \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linusw@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marex@denx.de \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.