[PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Runtime PM enablement is leaked on probe error paths.
--

commit 487a0a8551844cc9b5c38e7f8d7cbf2ec3f1435d
Author: Xu Yang <xu.yang_2 at nxp.com>

phy: fsl-imx8mq-usb: add control register regmap

This commit adds a control register regmap for the USB 3.0 femtoPHY.
It exposes these registers through debugfs to assist with diagnostic
efforts.

> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 9d1dd0e7352ed..4949ec78d3044 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -695,6 +707,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  	if (IS_ERR(imx_phy->base))
>  		return PTR_ERR(imx_phy->base);
>  
> +	imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> +						   &imx_cr_regmap_config);
> +	if (IS_ERR(imx_phy->cr_regmap)) {
> +		dev_warn(dev, "Fail to init debug register regmap\n");
> +		imx_phy->cr_regmap = NULL;
> +	}
> +
>  	pm_runtime_set_active(dev);
>  	pm_runtime_enable(dev);

[Severity: Medium]
Is there a leak of the runtime PM enablement state on probe error paths here?

In imx8mq_usb_phy_probe(), pm_runtime_enable() is called, but subsequent
initialization steps (like devm_phy_create() or devm_regulator_get()) can fail
and return directly without calling pm_runtime_disable().

Could this leave the disable_depth counter at 0 on a probe failure like
-EPROBE_DEFER, resulting in an 'Unbalanced pm_runtime_enable!' warning on the
next probe attempt? Would using devm_pm_runtime_enable() ensure this state is
properly cleaned up?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=4