[PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Thu May 14 19:32:51 PDT 2026
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Masking of -EPROBE_DEFER to -EINVAL when fetching sysclk.
- [High] Ignoring -EPROBE_DEFER for the SATA refclk.
--
commit 4f2fbd627ee80455cac194a4ae1b559d48180075
Author: Hongling Zeng <zenghongling at kylinos.cn>
phy: ti: pipe3: Fix clock resource leak on probe errors
When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.
Fix this by adding an error handling path to disable the clock
when these functions fail.
> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> index b5543b5c674c8..58fbc3b278130 100644
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c
[ ... ]
This isn't a regression introduced by this patch, but looking at
ti_pipe3_get_clk() called earlier in the probe sequence:
drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() {
...
if (phy->mode != PIPE3_MODE_PCIE || phy->phy_power_syscon) {
phy->sys_clk = devm_clk_get(dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
dev_err(dev, "unable to get sysclk\n");
return -EINVAL;
}
}
...
}
Does this code mask -EPROBE_DEFER to -EINVAL when fetching sysclk?
If devm_clk_get() for the sysclk returns -EPROBE_DEFER, the function
explicitly converts the error and returns -EINVAL. This completely breaks
the lifecycle of probe deferral for the sysclk resource.
Instead of retrying when the clock provider becomes available later in the
boot process, the driver initialization fails permanently, rendering the PHY
device unusable on systems with non-deterministic probe orders.
Similarly, looking at the SATA refclk handling in the same function:
drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() {
...
phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
dev_err(dev, "unable to get refclk\n");
/* older DTBs have missing refclk in SATA PHY
* so don't bail out in case of SATA PHY.
*/
if (phy->mode != PIPE3_MODE_SATA)
return PTR_ERR(phy->refclk);
}
...
}
Are errors returned by devm_clk_get() for the refclk ignored when the mode
is PIPE3_MODE_SATA?
While ignoring -ENOENT is intentionally done to support older DTBs missing
the clock, indiscriminately ignoring -EPROBE_DEFER breaks the probe deferral
mechanism. The driver will proceed immediately without waiting for the clock
provider to probe, resulting in the SATA PHY being initialized without its
required reference clock and subsequently failing to function properly.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260515021635.13444-1-zenghongling@kylinos.cn?part=1
More information about the linux-phy
mailing list