[PATCH v2 3/3] phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] `phy_validate()` ignores the provided `submode` parameter and relies on the stateful `hdptx->hdmi_cfg.mode`, causing union aliasing validation errors. With the new FFE level check, this can incorrectly validate an invalid TMDS rate by interpreting it as an FRL FFE level update.
--

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

phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
    
This commit wires up optional FRL TxFFE level control in the Samsung HDPTX
PHY driver. It enables the source to incrementally raise the TxFFE level in
response to persistent link failures reported by the sink.

> 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
[ ... ]
> @@ -1735,6 +1785,13 @@ static int rk_hdptx_phy_verify_hdmi_config(struct rk_hdptx_phy *hdptx,
>  		unsigned long long frl_rate = 100000000ULL * hdmi_in->frl.lanes *
>  					      hdmi_in->frl.rate_per_lane;
>  
> +		if (hdmi_in->frl.set_ffe_level) {
> +			if (hdmi_in->frl.ffe_level > FRL_FFE_MAX_LEVEL)
> +				return -EINVAL;
> +
> +			return 0;
> +		}
> +

[Severity: High]
This is a pre-existing issue, but does this new FFE check inadvertently
validate invalid TMDS rates due to union aliasing and stateful mode tracking?

In the driver, rk_hdptx_phy_validate() ignores the provided submode parameter
and instead relies on the stateful hdptx->hdmi_cfg.mode. If the PHY is
currently in FRL mode (for example, from a previous display state), TMDS
mode validations will incorrectly route to this FRL branch.

Because tmds_char_rate and the frl bitfields share a union in
struct phy_configure_opts_hdmi, a TMDS rate can alias into the frl fields.
Specifically, set_ffe_level aliases to bit 24 of the union. For a TMDS rate
where bit 24 is set and the aliased ffe_level byte is <= 3 (e.g., around
50.33 MHz), this check will prematurely return 0 (success).

Will this cause the DRM framework to falsely accept an unsupported mode
during the atomic check phase, which then fails in phy_configure() during
the atomic commit phase?

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