On Tue, 29 Sep 2026 13:20:29 +0000, [email protected] wrote:
> Then, on the next plug, msm_dp_display_host_phy_init() will silently skip
> PHY initialization because dp->phy_initialized was never reset to false:
[...]
> Can this sequence leave the hardware PHY uninitialized on replug, causing
> link training to fail and the display to remain broken until reboot?
I tried it on the device (Lenovo TB323FU, a DP monitor over USB-C) by
delaying the unplug handler by 5 s and forcing a detect in that window.
- A normal unplug already leaves the PHY initialized across the
controller's runtime suspend: msm_dp_hpd_unplug_handle() only calls
msm_dp_display_host_phy_exit() when sink_count == 0, which it was not
here, and msm_dp_pm_runtime_suspend() does not touch the PHY for DP.
With this patch the controller suspended after the unplug, and a
replug 20 s later trained the link with phy_init=1 and brought the
picture back. The controller's runtime suspend does not power the PHY
down, so the flag still describes the PHY correctly.
- Tearing the PHY down in detect() when the sink is gone (the natural
fix for the scenario in the review) made it worse: the next detect()
initialized the PHY again and hit
phy phy-88e8000.phy.3: phy_power_on was called before phy_init
and the SoC reset shortly after.
So I would keep this patch as it is. detect() clearing plugged so that
the unplug handler returns early is older than this change and is not
affected by it.
Thanks,
Joonhoe
