[PATCH v6 16/23] phy: rockchip: usbdp: Drop DP HPD handling

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] Potential Use-After-Free of the `udphy` struct when the driver is unbound, triggered by active Type-C consumers.
--

commit 709452eb1097435563d2642eb88ed81ae54361f2
Author: Sebastian Reichel <sebastian.reichel at collabora.com>

phy: rockchip: usbdp: Drop DP HPD handling

This patch drops the HPD handling logic from the USBDP PHY. The registers
involved require the display controller power domain being enabled and thus
the HPD signal should be handled by the displayport controller itself.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index b75c190a4311f..383e68b245060 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1333,6 +1291,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;
> +
>  	mutex_lock(&udphy->mutex);

[Severity: High]
This is a pre-existing issue, but could this code lead to a use-after-free
of the udphy struct when the driver is unbound?

The udphy structure is allocated using devm_kzalloc() in rk_udphy_probe(),
tying its lifetime to the device's binding lifecycle.

On driver unbind, devres calls typec_mux_unregister() and
typec_switch_unregister(), which run device_unregister(), and then frees
udphy.

However, device_unregister() only drops the core reference. If a Type-C
consumer (like the tcpm port driver) holds a reference to these Type-C
devices via fwnode_typec_mux_get(), the mux_dev and sw_dev objects stay
alive.

The consumer can still asynchronously invoke rk_udphy_typec_mux_set() or
rk_udphy_orien_sw_set() after the phy driver has been unbound.

Because udphy has already been freed by devres, does this mean any
subsequent call will dereference the freed udphy pointer when attempting to
lock udphy->mutex here, potentially resulting in memory corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=16