[PATCH v12 35/36] phy: rockchip: usbdp: Re-init PHY on mux change

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uncoordinated PHY reset during Type-C mode change pulls the rug out from under the active DisplayPort controller, leading to lost DP configuration, race conditions with DRM, and potential hardware SErrors.
--

--- Patch [35]: [PATCH v12 35/36] phy: rockchip: usbdp: Re-init PHY on mux change ---
commit 94db902f39e3cb43921400824c3bb5833e6b7bf2
Author: Sebastian Reichel <sebastian.reichel at collabora.com>

phy: rockchip: usbdp: Re-init PHY on mux change

Ensure that the right part of the PHY are powered up when the
mode changes. This ensures the PHY is re-initialized in the
following two scenarios, which are currently broken:
cable orientation changes without DP being involved and
switching from DP-only into a mode with USB support.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index c5ad300620a65..ecf0ed0139f69 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1383,7 +1383,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  
>  	rk_udphy_set_typec_state(udphy, state->mode);
>  
> -	return 0;
> +	return rk_udphy_update_power_state(udphy);

[Severity: High]
Will this cause an uncoordinated PHY reset that breaks the active DisplayPort
controller?

When rk_udphy_update_power_state() detects a mode change, it calls
rk_udphy_init(), which forcefully resets the PHY and disables the DP lanes:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_init() {
    ...
	/* Step 3: configure lane mux */
	regmap_update_bits(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET,
			   CMN_DP_LANE_MUX_ALL | CMN_DP_LANE_EN_ALL,
			   FIELD_PREP(CMN_DP_LANE_MUX_N(3), udphy->lane_mux_sel[3]) |
               ...
			   FIELD_PREP(CMN_DP_LANE_EN_ALL, 0));
    ...
}

If TCPM synchronously calls rk_udphy_typec_mux_set() during an altmode
renegotiation (such as switching from DP-only to DP+USB), the DP controller
might still be active because DRM handles the associated HPD disconnect
asynchronously on a different workqueue.

Could resetting the PHY while the DP controller is still active and its clock
is stopped trigger an SError or leave the display link permanently broken?

>  }
>  
>  static void rk_udphy_typec_mux_unregister(void *data)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=35