All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hongling Zeng" <zenghongling@kylinos.cn>
Cc: linux-phy@lists.infradead.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v7 3/4] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock  resources
Date: Wed, 09 Sep 2026 11:42:27 +0000	[thread overview]
Message-ID: <20260909114227.A46341F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260909113433.1287454-4-zenghongling@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] A redundant dev_err() call immediately before dev_err_probe() defeats the probe deferral suppression mechanism and causes double logging.
--

commit 09edabe83e95cc967698ec0a56b8901416907e0e
Author: Hongling Zeng <zenghongling@kylinos.cn>

phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources

This commit fixes EPROBE_DEFER handling in ti_pipe3_get_clk() by propagating
the actual error code for the system clock instead of returning -EINVAL. It
also uses devm_clk_get_optional() for the SATA refclk to correctly handle
missing optional clocks while properly propagating probe deferrals.

> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> index 021657cbce481..a67f5da43c83b 100644
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c

[ ... ]

> @@ -608,14 +608,21 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
>  	struct clk *clk;
>  	struct device *dev = phy->dev;
>  
> -	phy->refclk = devm_clk_get(dev, "refclk");
> +	/*
> +	 * refclk is optional for SATA PHY to support older DTBs, but
> +	 * required for other modes. Use devm_clk_get_optional() for SATA
> +	 * which returns NULL for -ENOENT, allowing us to propagate all
> +	 * other errors including -EPROBE_DEFER.
> +	 */
> +	if (phy->mode == PIPE3_MODE_SATA)
> +		phy->refclk = devm_clk_get_optional(dev, "refclk");
> +	else
> +		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);
> +		return dev_err_probe(dev, PTR_ERR(phy->refclk),
> +				"unable to get refclk\n");

[Severity: Low]
Does keeping this dev_err() call defeat the purpose of using dev_err_probe()
below it?

Since dev_err_probe() suppresses logging during -EPROBE_DEFER, leaving the
unconditional dev_err() here will still output "unable to get refclk" to
the kernel log during normal probe deferrals. It will also cause the same
error message to be logged twice on actual failures.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909113433.1287454-1-zenghongling@kylinos.cn?part=3

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

  reply	other threads:[~2026-09-09 11:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09 11:34 [PATCH v7 0/4] phy: ti-pipe3: Fix clock resource handling issues Hongling Zeng
2026-09-09 11:34 ` [PATCH v7 1/4] phy: ti-pipe3: Fix ignored clock enable return value in init Hongling Zeng
2026-09-09 11:46   ` sashiko-bot
2026-09-09 11:34 ` [PATCH v7 2/4] phy: ti: pipe3: Fix clock resource leak on probe errors Hongling Zeng
2026-09-09 11:34 ` [PATCH v7 3/4] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources Hongling Zeng
2026-09-09 11:42   ` sashiko-bot [this message]
2026-09-09 11:34 ` [PATCH v7 4/4] phy: ti-pipe3: Fix clock leak in init error path Hongling Zeng
2026-09-09 11:43   ` sashiko-bot

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=20260909114227.A46341F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --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=zenghongling@kylinos.cn \
    /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.