[PATCH v11 08/36] phy: rockchip: usbdp: Amend SSC modulation deviation

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] The driver fails to update `udphy->mode` when exiting DisplayPort Alt Mode, leaving the PHY in a broken state for USB3.
- [High] The DisplayPort configure callback allows requesting more lanes than available, which corrupts the configuration of active USB lanes.
--

--- Patch [8]: [PATCH v11 08/36] phy: rockchip: usbdp: Amend SSC modulation deviation ---
commit 721fb4287b2e4de65248e4437ba81583781df56f
Author: Frank Wang <frank.wang at rock-chips.com>

phy: rockchip: usbdp: Amend SSC modulation deviation

This commit moves the SSC modulation deviation into the private config of
the clock for the 24M and 26M configurations.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index e3f5a26c876a5..cb6acadfbccfb 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -350,7 +350,8 @@ static const struct reg_sequence rk_udphy_24m_refclk_cfg[] = {
>  	{0x0a64, 0xa8}, {0x1a3c, 0xd0},
>  	{0x1a44, 0xd0}, {0x1a48, 0x01},
>  	{0x1a4c, 0x0d}, {0x1a54, 0xe0},
> -	{0x1a5c, 0xe0}, {0x1a64, 0xa8}
> +	{0x1a5c, 0xe0}, {0x1a64, 0xa8},
> +	{0x00d4, 0x30}
>  };

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed that the driver might fail to
update udphy->mode when exiting DisplayPort Alt Mode.

In rk_udphy_typec_mux_set():

	if (state->alt && state->alt->svid == USB_TYPEC_DP_SID) {
		struct typec_displayport_data *data = state->data;

When the Type-C mux state changes to TYPEC_STATE_USB or TYPEC_STATE_SAFE,
state->alt is set to NULL. This causes the block above to be skipped,
bypassing the assignment of udphy->mode and udphy->mode_change.

Could this leave udphy->mode stuck in UDPHY_MODE_DP and prevent the USB3
port from being re-enabled?

[Severity: High]
This is a pre-existing issue, but does the DisplayPort configure callback
allow requesting more lanes than available?

In rk_udphy_dp_phy_verify_lanes():

		/* valid lane count. */
		udphy->lanes = dp->lanes;

The requested lane count is accepted and saved without validating it against
the actual number of available DP lanes. 

If the DP controller requests 4 lanes while the PHY is in 2-lane DP + USB
mode, udphy->lanes is inappropriately set to 4.

Later in rk_udphy_dp_phy_configure():

			rk_udphy_dp_set_voltage(udphy, udphy->bw, dp->voltage[i],
					dp->pre[i], lane);

This out-of-bounds lane configuration is applied in a loop.

Could this corrupt the analog state of lanes that are actively being used by
the USB3 controller?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-rockchip-usbdp-cleanup-v11-0-a149ac60f76c@collabora.com?part=8