Re: [PATCH v6 02/23] phy: rockchip: usbdp: Update mode_change after error handling

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] System crash due to concurrent MMIO access after PHY reinitialization failure.
- [High] State desync and resource leak in PHY mode tracking during Type-C role transitions.
--

commit e7082d92230eb75aff8a9e06c20d96b4d548e34c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: phy: rockchip: usbdp: Update mode_change after error handling

If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.

Link: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index fba35510d88ce..a5ffdf7a6e76b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  	}
>  
>  	if (udphy->status == UDPHY_MODE_NONE) {

[Severity: High]
This isn't a bug introduced by this patch, but I have a question about how
PHY mode transitions are tracked when the Type-C mux switches from a state
with USB (like DP+USB) to a state without it (like DP-only).

In this scenario, the mode variable gets updated, but the USB flag is not
cleared from the status field. Later, when the USB subsystem calls
rk_udphy_usb3_phy_exit(), it sees that the current mode lacks the USB flag
and returns early. This bypasses rk_udphy_power_off().

Does this mean the USB flag is permanently leaked in the status field? If
the remaining DP consumer subsequently powers off, it seems the status would
still contain the USB flag, preventing the driver from properly shutting
down the hardware and leaving APB clocks active.

>  		ret = rk_udphy_setup(udphy);
>  		if (ret)
>  			return ret;
>  
>  		if (udphy->mode & UDPHY_MODE_USB)
>  			rk_udphy_u3_port_disable(udphy, false);
> -	} else if (udphy->mode_change) {
>  		udphy->mode_change = false;
> +	} else if (udphy->mode_change) {
>  		udphy->status = UDPHY_MODE_NONE;
>  		if (udphy->mode == UDPHY_MODE_DP)
>  			rk_udphy_u3_port_disable(udphy, true);
> @@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  		ret = rk_udphy_setup(udphy);
>  		if (ret)
>  			return ret;

[Severity: Critical]
This is a pre-existing issue, but what happens if the setup or init fails
here during a Type-C orientation change?

If rk_udphy_init() fails due to something like an LCPLL lock timeout, it
asserts all resets, including the APB resets, before returning the error.
This function then propagates that error, but it doesn't restore the prior
state of sibling PHYs (like DP) which might already be active.

Since the DP framework would still consider the PHY active, could it
subsequently invoke rk_udphy_dp_phy_configure()? If that happens and it
attempts MMIO access to the PMA regmap while the APB bus reset is still
asserted, would this trigger a bus hang and a kernel panic?

> +		udphy->mode_change = false;
>  	}
>  
>  	udphy->status |= mode;

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