From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: conor+dt@kernel.org, dri-devel@lists.freedesktop.org,
robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v5 09/15] drm/rockchip: dw_dp: Implement out-of-band HPD handling
Date: Thu, 23 Jul 2026 22:34:59 +0000 [thread overview]
Message-ID: <20260723223500.63A4B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724-synopsys-dw-dp-improvements-v5-9-9445c2e87441@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Out-of-band HPD callbacks write to hardware registers without ensuring the DP controller's power domain is active, risking system crashes.
- [Medium] The VO GRF lookup unconditionally searches the PHY node, entirely failing to support new platforms that provide the VO GRF phandle directly in the DP node.
--
--- Patch [9]: [PATCH v5 09/15] drm/rockchip: dw_dp: Implement out-of-band HPD handling ---
commit d5d5b2e640507cef02b65193fd2c17e492af4958
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
drm/rockchip: dw_dp: Implement out-of-band HPD handling
This commit implements out-of-band hotplug handling for the Rockchip
DesignWare DisplayPort driver. It moves the HPD register access from the
USBDP PHY driver to this driver to better detect cable plug events from the
USB-C state machine.
> diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> index 005938dc66c9f..0ecbad24dd4e8 100644
> --- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
[ ... ]
> @@ -23,12 +26,54 @@
>
> #include "rockchip_drm_drv.h"
>
> +#define ROCKCHIP_MAX_CTRLS 2
> +
> +#define ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL BIT(10)
> +#define ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG BIT(11)
> +
> +struct rockchip_dw_dp_plat_data {
> + u8 num_ctrls;
> + u32 ctrl_ids[ROCKCHIP_MAX_CTRLS];
> + u32 max_link_rate;
> + u8 pixel_mode;
> + u32 hpd_reg[ROCKCHIP_MAX_CTRLS];
> +};
> +
> struct rockchip_dw_dp {
> struct dw_dp *base;
> struct device *dev;
> + const struct rockchip_dw_dp_plat_data *pdata;
> + struct regmap *vo_grf;
> struct rockchip_encoder *encoder;
> + int id;
> + bool hpd_sel;
> + bool hpd_cfg;
> };
>
> +static void dw_dp_rockchip_hpd_sw_sel(void *data, bool force_hpd_from_sw)
> +{
> + struct rockchip_dw_dp *dp = data;
> + u32 hpd_reg = dp->pdata->hpd_reg[dp->id];
> +
> + dp->hpd_sel = force_hpd_from_sw;
> +
> + regmap_write(dp->vo_grf, hpd_reg,
> + FIELD_PREP_WM16(ROCKCHIP_VO_GRF_DP_SINK_HPD_SEL, dp->hpd_sel));
[Severity: High]
Does this out-of-band hotplug callback require power management before writing
to the VO GRF register?
The commit message notes that this register requires the power-domain from the
DP controller, but dw_dp_rockchip_hpd_sw_sel() executes without first calling
pm_runtime_get_sync() or similar power management functions.
If the display pipeline is suspended when the USB-C state machine triggers
an event, could this unclocked register write lead to a bus hang or
synchronous external abort?
> +}
> +
> +static void dw_dp_rockchip_hpd_sw_cfg(void *data, bool hpd)
> +{
> + struct rockchip_dw_dp *dp = data;
> + u32 hpd_reg = dp->pdata->hpd_reg[dp->id];
> +
> + dev_dbg(dp->dev, "Force HPD connected=%s\n", str_yes_no(hpd));
> +
> + dp->hpd_cfg = hpd;
> +
> + regmap_write(dp->vo_grf, hpd_reg,
> + FIELD_PREP_WM16(ROCKCHIP_VO_GRF_DP_SINK_HPD_CFG, dp->hpd_cfg));
[Severity: High]
Similar to the concern in dw_dp_rockchip_hpd_sw_sel(), does this register
write also require the DP controller's power domain to be active?
> +}
> +
> static int dw_dp_encoder_atomic_check(struct drm_encoder *encoder,
[ ... ]
> @@ -71,6 +116,34 @@ static const struct drm_encoder_helper_funcs dw_dp_encoder_helper_funcs = {
> .atomic_check = dw_dp_encoder_atomic_check,
> };
>
> +static struct regmap *dp_dp_rockchip_get_vo_grf(struct rockchip_dw_dp *dp)
> +{
> + struct device_node *np = dev_of_node(dp->dev);
> + struct of_phandle_args args;
> + struct regmap *regmap;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(np, "phys", "#phy-cells", 0, &args);
> + if (ret)
> + return ERR_PTR(-ENODEV);
> +
> + /*
> + * Limit this workaround to RK3576 and RK3588, new platforms should
> + * add a VO GRF phandle in the DisplayPort DT node.
> + */
> + if (!of_device_is_compatible(args.np, "rockchip,rk3576-usbdp-phy") &&
> + !of_device_is_compatible(args.np, "rockchip,rk3588-usbdp-phy")) {
> + regmap = ERR_PTR(-ENODEV);
> + goto out_put_node;
> + }
> +
> + regmap = syscon_regmap_lookup_by_phandle(args.np, "rockchip,vo-grf");
[Severity: Medium]
Will this function fail to support the new platforms mentioned in the comment?
If a new platform does not have the "phys" property, of_parse_phandle_with_args()
will fail early and return ERR_PTR(-ENODEV). It appears there is no fallback
to check for the VO GRF phandle directly in the DP node, which would prevent
new platforms from probing successfully.
> +
> +out_put_node:
> + of_node_put(args.np);
> + return regmap;
> +}
> +
> static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *data)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260724-synopsys-dw-dp-improvements-v5-0-9445c2e87441@collabora.com?part=9
next prev parent reply other threads:[~2026-07-23 22:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 22:17 [PATCH v5 00/15] Synopsys DisplayPort Controller improvements for Rockchip platforms Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 01/15] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback Sebastian Reichel
2026-07-23 22:34 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 02/15] drm/bridge: synopsys: dw-dp: Cancel pending HPD work on unbind Sebastian Reichel
2026-07-23 22:32 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 03/15] drm/bridge: synopsys: dw-dp: Add missing mutex cleanups on module removal Sebastian Reichel
2026-07-23 22:48 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 04/15] drm/bridge: synopsys: dw-dp: Move dw_dp_bridge_atomic_get_output_bus_fmts() Sebastian Reichel
2026-07-23 22:28 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 05/15] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED Sebastian Reichel
2026-07-23 22:31 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 06/15] drm/bridge: synopsys: dw-dp: Add follow-up bridge support Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 07/15] drm/bridge: Add out-of-band HPD notify handler Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 08/15] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 09/15] drm/rockchip: dw_dp: Implement out-of-band HPD handling Sebastian Reichel
2026-07-23 22:34 ` sashiko-bot [this message]
2026-07-23 22:17 ` [PATCH v5 10/15] drm/bridge: synopsys: dw-dp: Add Runtime PM support Sebastian Reichel
2026-07-23 22:37 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 11/15] drm/rockchip: dw_dp: Add runtime " Sebastian Reichel
2026-07-23 22:40 ` sashiko-bot
2026-07-23 22:17 ` [PATCH v5 12/15] drm/bridge: synopsys: dw-dp: Protect sdp_reg_bank from concurrent access Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 13/15] drm/bridge: synopsys: dw-dp: Use regmap_set_bits in dw_dp_send_sdp Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 14/15] dt-bindings: display: rockchip: dw-dp: Fix sound DAI cells Sebastian Reichel
2026-07-23 22:17 ` [PATCH v5 15/15] drm/bridge: synopsys: dw-dp: Add audio support Sebastian Reichel
2026-07-23 22:38 ` 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=20260723223500.63A4B1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox