All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v9 03/22] drm/bridge: synopsys: dw-dp: Fix error handling in dw_dp_link_enable()
Date: Mon, 03 Aug 2026 18:25:54 +0000	[thread overview]
Message-ID: <20260803182555.605441F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803-synopsys-dw-dp-improvements-v9-3-2e6e46135312@collabora.com>

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

New issues:
- [High] The patch introduces a double-free bug by adding error path cleanups (`phy_power_off()` and `drm_dp_link_power_down()`) in `dw_dp_link_enable()`. Because `atomic_enable` returns `void` and cannot abort a commit, the DRM core unconditionally invokes `atomic_disable` later, executing a second cleanup.

Pre-existing issues:
- [High] A preexisting bug where `phy_power_off()` is called on atomic disable even if `phy_power_on()` failed in `dw_dp_link_enable()`, corrupting the PHY power state and regulator counts.
--

--- Patch [3]: [PATCH v9 03/22] drm/bridge: synopsys: dw-dp: Fix error handling in dw_dp_link_enable() ---
commit 37d17812be83d5554aca9b8d15486591d59db100
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

drm/bridge: synopsys: dw-dp: Fix error handling in dw_dp_link_enable()

This commit adds missing error handling in dw_dp_link_enable(), which
failed to release resources it already requested before hitting an error.

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index 06997208945ed..e332d66b80571 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -1636,10 +1636,19 @@ static int dw_dp_link_enable(struct dw_dp *dp)
>  

[Severity: High]
This is a pre-existing issue, but does the same unbalanced power state
happen if phy_power_on() fails?

Looking at dw_dp_link_enable(), which executes just before this hunk:

    ret = phy_power_on(dp->phy);
    if (ret)
        return ret;

If phy_power_on() fails, we return early. However, because atomic_enable()
returns void and cannot abort a commit, the DRM core will still
unconditionally call dw_dp_link_disable() later:

dw_dp_link_disable() {
    ...
    phy_power_off(dp->phy);
}

Will this unconditional cleanup drop the phy power count to -1, permanently
breaking subsequent power on attempts because the next phy_power_on()
will only increment the count to 0 and skip hardware initialization?

>  	ret = drm_dp_link_power_up(&dp->aux, dp->link.revision);
>  	if (ret < 0)
> -		return ret;
> +		goto err_phy_power_off;
>  
>  	ret = dw_dp_link_train(dp);
> +	if (ret < 0)
> +		goto err_link_power_down;
> +
> +	return 0;
> +
> +err_link_power_down:
> +	drm_dp_link_power_down(&dp->aux, dp->link.revision);
>  
> +err_phy_power_off:
> +	phy_power_off(dp->phy);

[Severity: High]
Will this explicit rollback result in phy_power_off() being called twice?

Since the DRM core will unconditionally invoke atomic_disable() later
when the commit fails, dw_dp_link_disable() will execute and perform
its own cleanup:

dw_dp_link_disable() {
    ...
    if (dw_dp_hpd_detect(dp))
        drm_dp_link_power_down(&dp->aux, dp->link.revision);
    ...
    phy_power_off(dp->phy);
}

Doing the cleanup here in the error path means these functions will be
called a second time.

Can this double cleanup cause the phy power count to drop to -1, resulting
in the same permanent breakage of the display pipeline described above?

>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-synopsys-dw-dp-improvements-v9-0-2e6e46135312@collabora.com?part=3

  reply	other threads:[~2026-08-03 18:25 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 18:05 [PATCH v9 00/22] Synopsys DisplayPort Controller improvements for Rockchip platforms Sebastian Reichel
2026-08-03 18:05 ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 01/22] drm/bridge: synopsys: dw-dp: Register DP AUX on bridge attach Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:35   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 02/22] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:27   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 03/22] drm/bridge: synopsys: dw-dp: Fix error handling in dw_dp_link_enable() Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:25   ` sashiko-bot [this message]
2026-08-03 18:05 ` [PATCH v9 04/22] drm/bridge: synopsys: dw-dp: Cancel pending HPD work Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:35   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 05/22] drm/bridge: synopsys: dw-dp: Document missing reset line deassert Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 06/22] drm/bridge: synopsys: dw-dp: Add missing mutex cleanups on module removal Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:27   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 07/22] drm/bridge: synopsys: dw-dp: Fix AUX transfer timeout race condition Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 08/22] drm/bridge: synopsys: dw-dp: Fix support for short I2C reads Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 09/22] drm/bridge: synopsys: dw-dp: Free output_fmts when none are valid Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:35   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 10/22] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:43   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 11/22] drm/bridge: synopsys: dw-dp: Add follow-up bridge support Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 12/22] drm/bridge: Add out-of-band HPD notify handler Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 13/22] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 14/22] drm/rockchip: dw_dp: Implement out-of-band HPD handling Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:46   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 15/22] drm/bridge: synopsys: dw-dp: Add Runtime PM support Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:55   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 16/22] drm/rockchip: dw_dp: Add runtime " Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:58   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 17/22] drm/bridge: synopsys: dw-dp: Protect sdp_reg_bank from concurrent access Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 18/22] drm/bridge: synopsys: dw-dp: Drop useless reservation of first slot Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 19:02   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 19/22] drm/bridge: synopsys: dw-dp: Clear only enabled SDPs on atomic disable Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 20/22] drm/bridge: synopsys: dw-dp: Use regmap_set_bits in dw_dp_send_sdp Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 18:05 ` [PATCH v9 21/22] dt-bindings: display: rockchip: dw-dp: Fix sound DAI cells Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 19:06   ` sashiko-bot
2026-08-03 18:05 ` [PATCH v9 22/22] drm/bridge: synopsys: dw-dp: Add audio support Sebastian Reichel
2026-08-03 18:05   ` Sebastian Reichel
2026-08-03 19:11   ` sashiko-bot
2026-08-04 13:56 ` [PATCH v9 00/22] Synopsys DisplayPort Controller improvements for Rockchip platforms Igor Paunovic
2026-08-04 13:56   ` Igor Paunovic
2026-08-06  0:53   ` Sebastian Reichel
2026-08-06  0:53     ` Sebastian Reichel

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=20260803182555.605441F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sebastian.reichel@collabora.com \
    /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.