All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xu Yang" <xu.yang_2@oss.nxp.com>
Cc: Frank.Li@kernel.org, vkoul@kernel.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org, imx@lists.linux.dev,
	neil.armstrong@linaro.org
Subject: Re: [PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap
Date: Tue, 30 Jun 2026 11:13:03 +0000	[thread overview]
Message-ID: <20260630111304.68B971F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-4-25d616403844@nxp.com>

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@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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Xu Yang" <xu.yang_2@oss.nxp.com>
Cc: Frank.Li@kernel.org, vkoul@kernel.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org, imx@lists.linux.dev,
	neil.armstrong@linaro.org
Subject: Re: [PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap
Date: Tue, 30 Jun 2026 11:13:03 +0000	[thread overview]
Message-ID: <20260630111304.68B971F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-4-25d616403844@nxp.com>

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@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

  reply	other threads:[~2026-06-30 11:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 10:11 [PATCH v5 0/5] phy: fsl-imx8mq-usb: few improvements Xu Yang
2026-06-30 10:11 ` Xu Yang
2026-06-30 10:11 ` [PATCH v5 1/5] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path Xu Yang
2026-06-30 10:11   ` Xu Yang
2026-06-30 10:31   ` sashiko-bot
2026-06-30 10:31     ` sashiko-bot
2026-06-30 10:11 ` [PATCH v5 2/5] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable Xu Yang
2026-06-30 10:11   ` Xu Yang
2026-06-30 10:11 ` [PATCH v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support Xu Yang
2026-06-30 10:11   ` Xu Yang
2026-06-30 10:52   ` sashiko-bot
2026-06-30 10:52     ` sashiko-bot
2026-06-30 19:06   ` Frank Li
2026-06-30 19:06     ` Frank Li
2026-06-30 10:11 ` [PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap Xu Yang
2026-06-30 10:11   ` Xu Yang
2026-06-30 11:13   ` sashiko-bot [this message]
2026-06-30 11:13     ` sashiko-bot
2026-06-30 10:11 ` [PATCH v5 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP Xu Yang
2026-06-30 10:11   ` Xu Yang
2026-06-30 19:13   ` Frank Li
2026-06-30 19:13     ` Frank Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260630111304.68B971F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    --cc=xu.yang_2@oss.nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.