From: sashiko-bot@kernel.org
To: kr494167@gmail.com
Cc: neil.armstrong@linaro.org, vkoul@kernel.org,
linux-phy@lists.infradead.org, olteanv@gmail.com
Subject: Re: [PATCH] phy: fsl-lynx-28g: propagate PCVT enable errors
Date: Thu, 23 Jul 2026 03:36:49 +0000 [thread overview]
Message-ID: <20260723033650.5E0C51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260722033619.10647-1-kr494167@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardware and software state desynchronization on PCVT enable failure prevents mode recovery.
--
--- Patch [1]: [PATCH] phy: fsl-lynx-28g: propagate PCVT enable errors ---
commit 6193a7adcb18a183b9462da919d480f3a6949562
Author: surendra <kr494167@gmail.com>
phy: fsl-lynx-28g: propagate PCVT enable errors
This commit updates lynx_28g_set_mode() to check the return value of
lynx_28g_lane_enable_pcvt(). If an error occurs, the code now propagates
the error and exits before updating the software lane mode tracking.
> diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> index 38afcd081a2a7..1fe406adc83cb 100644
> --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> @@ -1003,7 +1003,9 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
>
> lynx_28g_lane_change_proto_conf(lane, lane_mode);
> lynx_28g_lane_remap_pll(lane, lane_mode);
> - WARN_ON(lynx_28g_lane_enable_pcvt(lane, lane_mode));
> + err = lynx_28g_lane_enable_pcvt(lane, lane_mode);
> + if (err)
> + goto out;
[Severity: Medium]
Does this new error path leave the software and hardware states
desynchronized?
Prior to this point, the hardware has already been reprogrammed to the
new mode by lynx_28g_lane_change_proto_conf() and
lynx_28g_lane_remap_pll(). If lynx_28g_lane_enable_pcvt() fails and takes
the goto out path, lane->mode remains set to the old mode.
If a caller later attempts to recover by setting the PHY back to the old
mode, lynx_28g_set_mode() will see:
if (lane_mode == lane->mode)
return 0;
and short-circuit, preventing the hardware from actually being reverted.
Should the error path either revert the hardware changes or set
lane->mode = LANE_MODE_UNKNOWN to ensure subsequent recovery attempts bypass
the short-circuit check?
>
> lane->mode = lane_mode;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260722033619.10647-1-kr494167@gmail.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
prev parent reply other threads:[~2026-07-23 3:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 3:36 [PATCH] phy: fsl-lynx-28g: propagate PCVT enable errors kr494167
2026-07-22 8:00 ` Vladimir Oltean
2026-07-22 13:37 ` Andrew Lunn
2026-07-23 3:36 ` sashiko-bot [this message]
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=20260723033650.5E0C51F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kr494167@gmail.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox