[PATCH v11 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 2 potential issue(s) to consider:

New issues:
- [High] Deadlock / Recursive Lock

Pre-existing issues:
- [High] Silent DP PHY State Loss
--

--- Patch [35]: [PATCH v11 35/36] phy: rockchip: usbdp: Re-init PHY on mux change ---
commit 63e6102eaff345b4ebf6faefafd6aae88e7bb98e
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 when cable orientation changes without
DP being involved, and when 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]
Could this lead to a recursive locking deadlock if the DWC3 controller is
runtime-suspended?

Since rk_udphy_typec_mux_set() holds udphy->mutex using a guard, the
following chain seems to re-acquire the same mutex:

rk_udphy_typec_mux_set()
   guard(mutex)(&udphy->mutex);
   rk_udphy_update_power_state()
      phy_notify_reset(udphy->phy_u3, PHY_NOTIFY_PRE_RESET);

If the DWC3 driver handles this notification in device role:

dwc3_usb3_phy_notify()
   pm_runtime_resume_and_get()
      ...
      dwc3_resume_common()
         dwc3_core_init_for_resume()
            dwc3_phy_init()
               phy_init()

The PHY init then attempts to acquire the lock again:

rk_udphy_usb3_phy_init()
   guard(mutex)(&udphy->mutex);

Will this cause a system freeze when hotplugging or switching modes?


[Severity: High]
This isn't a bug introduced by this patch, but does invoking
rk_udphy_update_power_state() during a mux change cause the DP link to be
permanently lost?

When the power state updates, the PHY is re-initialized:

rk_udphy_update_power_state()
   rk_udphy_init()
      regmap_write(..., FIELD_PREP(CMN_DP_LANE_EN_ALL, 0));

This reset sequence clears the CMN_DP_LANE_EN_ALL bits and disables DP
transmission. Since rk_udphy_dp_lane_enable() does not appear to be called
afterward to restore the active DP configuration, does the DRM subsystem
lose the link without a full power cycle?

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

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