[PATCH v2 2/3] phy: rockchip: samsung-hdptx: Handle PHY config after module reload

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] The driver deliberately forces a requested rate of 0 to bypass CCF's rate-change skipping, breaking the CCF notifier state machine and posing a fatal divide-by-zero risk for standard downstream dividers.
--

commit 785f91a9be66b165695a8546ef8682f38790202e
Author: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>

phy: rockchip: samsung-hdptx: Handle PHY config after module reload

This commit modifies the pll_config_dirty mechanism to first compute the
target rate from the HDMI link configuration before deciding whether to
invalidate the requested rate. It now zeros out req->rate only if it
matches the Common Clock Framework's cached rate.

> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
[ ... ]
> @@ -2346,14 +2346,16 @@ static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
>  	 * to ensure rk_hdptx_phy_clk_set_rate() will be always invoked.
>  	 * Otherwise, restrict the rate according to the PHY link setup.
>  	 */
> -	if (hdptx->pll_config_dirty)
> -		req->rate = 0;
> -	else if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
> +
> +	if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
>  		req->rate = hdptx->hdmi_cfg.rate;
>  	else
>  		req->rate = DIV_ROUND_CLOSEST_ULL(hdptx->hdmi_cfg.rate * 8,
>  						  hdptx->hdmi_cfg.bpc);
>  
> +	if (hdptx->pll_config_dirty && req->rate == clk_hw_get_rate(hw))
> +		req->rate = 0;

[Severity: High]
This is a pre-existing issue, but does setting the requested rate to 0
pose a risk of a divide-by-zero exception in downstream clocks?

When CCF propagates this new_rate = 0 to child clocks, if a child clock
uses standard clk_divider_ops, its clk_divider_set_rate() callback
executes divider_get_val(), which evaluates:

DIV_ROUND_UP_ULL(parent_rate, rate)

Since rate is 0, this causes a fatal divide-by-zero exception.

Additionally, because the driver programs the PHY to the actual rate (e.g.,
148.5MHz) and clk_recalc() returns this accurate rate, CCF observes
old_rate == core->rate in clk_change_rate() and skips firing the
POST_RATE_CHANGE notifier.

Does this leave any consumers that prepared state during PRE_RATE_CHANGE
permanently stuck? This path appears reachable by unprivileged userspace
via standard DRM/KMS resolution changes that reconfigure the PHY while
retaining the same clock frequency.

> +
>  	return 0;
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-hdptx-ffe-v2-0-3a5922c76fc5@collabora.com?part=2