[PATCH v13 17/35] phy: rockchip: usbdp: Drop DP HPD handling

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Jul 14 13:03:22 PDT 2026


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

Pre-existing issues:
- [High] The Type-C mux handler ignores standard USB and Safe mode reset events, preventing dynamic recovery of USB 3.0 functionality when exiting DP Alt Mode.
--

--- Patch [17]: [PATCH v13 17/35] phy: rockchip: usbdp: Drop DP HPD handling ---
commit 7a23b9358d639150ae95d06261a789689b085a0c
Author: Sebastian Reichel <sebastian.reichel at collabora.com>

phy: rockchip: usbdp: Drop DP HPD handling

This commit removes the HPD handling logic from the USBDP PHY, delegating
the responsibility to the displayport controller itself. It also adjusts
the Type-C mux set routine to ignore mux events not involving DP AltMode.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1309,6 +1267,14 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  	struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
>  	u8 mode;
>  
> +	/*
> +	 * Ignore mux events not involving DP AltMode, because
> +	 * the mode field is being reused, e.g. state->mode == 4
> +	 * could be either TYPEC_MODE_USB4 or TYPEC_DP_STATE_C.
> +	 */
> +	if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
> +		return 0;
> +

[Severity: High]
This is a pre-existing issue, but does this early return cause the PHY to
ignore standard TYPEC_STATE_SAFE and TYPEC_STATE_USB reset events?

When a dynamic exit from DP Alt Mode occurs (for example, via VDM), TCPM
typically sets the mux to TYPEC_STATE_SAFE and then TYPEC_STATE_USB. During
these transitions, state->alt will be NULL.

Because this early return completely ignores those states, udphy->mode
appears to get stuck in UDPHY_MODE_DP, leaving the PHY lanes permanently
mapped to DisplayPort.

Could this cause subsequent USB power-on attempts to fail the
!(udphy->mode & mode) check in rk_udphy_power_on() and silently abort,
breaking USB 3.0 SuperSpeed functionality until a physical replug occurs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-rockchip-usbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com?part=17



More information about the linux-phy mailing list