Re: [PATCH] drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] msm_hdmi_phy_resource_enable() fails to clean up resources on error paths, leading to leaked PM runtime references and unbalanced clocks/regulators.
- [High] msm_hdmi_bridge_atomic_pre_enable() ignores the return value of msm_hdmi_phy_resource_enable().
--

commit 7bd11a53a59269371e001514370dec3c09b44b21
Author: Guangshuo Li <lgs201920130244@gmail.com>

drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure

This commit ensures that if PHY resource enabling or PLL initialization
fails during probe, the driver routes through a common error path to
disable runtime PM before returning.

> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> index eb1088755cb3a..77dce35cd45e0 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
> @@ -168,13 +168,13 @@ static int msm_hdmi_phy_probe(struct platform_device *pdev)
>  
>  	ret = msm_hdmi_phy_resource_enable(phy);
>  	if (ret)
> -		return ret;
> +		goto err_pm_disable;

[Severity: High]
This isn't a bug introduced by this patch, but looking at the call to
msm_hdmi_phy_resource_enable() here, does it leak PM runtime references 
and fail to clean up regulators on error?

Inside msm_hdmi_phy_resource_enable() in drivers/gpu/drm/msm/hdmi/hdmi_phy.c,
if regulator_bulk_enable() fails, it returns early without calling
pm_runtime_put_sync(), which permanently leaks the PM runtime usage counter:

drivers/gpu/drm/msm/hdmi/hdmi_phy.c:msm_hdmi_phy_resource_enable() {
    ...
    ret = regulator_bulk_enable(cfg->num_regs, phy->regs);
    if (ret) {
        DRM_DEV_ERROR(dev, "failed to enable regulators: (%d)\n", ret);
        return ret;
    }
    ...
}

Additionally, in the same function, if a clock fails to enable during the
loop, does it overwrite the error and falsely return success if a
subsequent clock succeeds?

drivers/gpu/drm/msm/hdmi/hdmi_phy.c:msm_hdmi_phy_resource_enable() {
    ...
    for (i = 0; i < cfg->num_clks; i++) {
        ret = clk_prepare_enable(phy->clks[i]);
        if (ret)
            DRM_DEV_ERROR(dev, "failed to enable clock: %s (%d)\n",
                cfg->clk_names[i], ret);
    }

    return ret;
}

Because the loop does not break on error, a subsequent successful clock
enable will set ret back to 0, falsely returning success and leaving the
hardware partially unclocked.

[Severity: High]
This is a pre-existing issue, but since we are handling failures from
msm_hdmi_phy_resource_enable() in this path, is it safe that
msm_hdmi_bridge_atomic_pre_enable() ignores this function's return value?

drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:msm_hdmi_bridge_atomic_pre_enable() {
    ...
    if (!hdmi->power_on) {
        msm_hdmi_phy_resource_enable(phy);
        msm_hdmi_power_on(bridge);
        hdmi->power_on = true;
    }
    ...
}

If msm_hdmi_phy_resource_enable() fails during an atomic commit, the hardware
remains unclocked and unpowered. Calling msm_hdmi_power_on() immediately
after will access dead hardware registers, which can lead to a synchronous
external abort or kernel panic on MSM platforms.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913085814.1509352-1-lgs201920130244@gmail.com?part=1