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 <[email protected]>

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-9445c2e87...@collabora.com?part=9

Reply via email to