All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Esben Haabendal" <esben@geanix.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 4/5] drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set()
Date: Mon, 10 Aug 2026 07:22:56 +0000	[thread overview]
Message-ID: <20260810072257.2ABD61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260810-nwl-dsi-fixes-v3-4-256da9d672e1@geanix.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unbalanced resource teardown and PM runtime underflow in mode_set error path.
--

--- Patch [4]: [PATCH v3 4/5] drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set() ---
commit 0db3c1cc2f73a9bc66aea2633f754029dd76b743
Author: Esben Haabendal <esben@geanix.com>

drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set()

This commit adds a return value check for nwl_dsi_mode_set() in
nwl_dsi_bridge_mode_set(), jumping to an error path on failure.

> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 3fd41212933c8..e90588299c5ea 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -884,7 +884,9 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>  	}
>  
>  	/* Step 2 from DSI reset-out instructions */
> -	nwl_dsi_mode_set(dsi);
> +	ret = nwl_dsi_mode_set(dsi);
> +	if (ret < 0)
> +		goto runtime_put;

[Severity: High]
This is a pre-existing issue, but does taking the runtime_put error path here
lead to unbalanced resource teardown and PM runtime underflows?

Because the drm_bridge_funcs.mode_set callback returns void, failures cannot be
propagated to the DRM core to abort the commit. If nwl_dsi_mode_set() fails and
jumps to runtime_put, it calls pm_runtime_put_sync() and returns early. 

However, the DRM core still considers the bridge pipeline state to be 'enabled',
and will unconditionally call nwl_dsi_bridge_atomic_disable() during the next
pipeline teardown.

When atomic_disable() runs, it unconditionally calls pm_runtime_put(), leading
to a reference count underflow:

drivers/gpu/drm/bridge/nwl-dsi.c:nwl_dsi_bridge_atomic_disable() {
	...
	pm_runtime_put(dsi->dev);
}

Furthermore, atomic_disable() unconditionally calls nwl_dsi_disable(), which
blindly attempts to tear down the PHY:

drivers/gpu/drm/bridge/nwl-dsi.c:nwl_dsi_bridge_atomic_disable() {
	...
	nwl_dsi_disable(dsi);
	...
}

Since nwl_dsi_mode_set() already cleans up its own PHY resources on internal
failure, this double-disable pushes the PHY framework's power_count and
init_count to -1. The next attempt to initialize the display will increment
these counters to 0, skipping the actual hardware ops->power_on() and
ops->init() calls, permanently leaving the display broken until the module is
reloaded.

While this broken error path already existed for clock initialization failures
in this function, wiring up nwl_dsi_mode_set's return value to it exposes the
PHY breakage on a new failure path.

>  
>  	/* Step 3 from DSI reset-out instructions */
>  	ret = reset_control_deassert(dsi->rst_esc);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-nwl-dsi-fixes-v3-0-256da9d672e1@geanix.com?part=4

  reply	other threads:[~2026-08-10  7:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10  7:14 [PATCH v3 0/5] drm/bridge: nwl-dsi: Various fixes Esben Haabendal
2026-08-10  7:14 ` [PATCH v3 1/5] drm/bridge: nwl-dsi: Cleanup endpoint mux control selection Esben Haabendal
2026-08-10 15:02   ` Luca Ceresoli
2026-08-10  7:14 ` [PATCH v3 2/5] drm/bridge: nwl-dsi: Limit LCDIF specific sync override Esben Haabendal
2026-08-10  7:14 ` [PATCH v3 3/5] drm/bridge: nwl-dsi: Correct auto-insert EOTP behavior Esben Haabendal
2026-08-10  7:14 ` [PATCH v3 4/5] drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set() Esben Haabendal
2026-08-10  7:22   ` sashiko-bot [this message]
2026-08-10  7:14 ` [PATCH v3 5/5] drm/bridge: nwl-dsi: Correct MIPI DSI horizontal sync timing Esben Haabendal
2026-08-10  7:26   ` sashiko-bot

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=20260810072257.2ABD61F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=esben@geanix.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.