Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jan Petrous (OSS)" <jan.petrous@oss.nxp.com>
Cc: devicetree@vger.kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org, vkoul@kernel.org, olteanv@gmail.com,
	imx@lists.linux.dev, wsa+renesas@sang-engineering.com,
	robh@kernel.org, conor+dt@kernel.org, linux-pci@vger.kernel.org,
	Frank.Li@kernel.org
Subject: Re: [PATCH RFC v3 04/12] net: pcs: add NXP SerDes XPCS shared core
Date: Sun, 20 Sep 2026 06:54:58 +0000	[thread overview]
Message-ID: <20260920065458.E16661F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260919-s32g_serdes-v3-4-9d68868c1e89@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] net: pcs: Link flap and incorrect speed/duplex resolution in SGMII AN
- [High] net: pcs: USXGMII full-duplex configuration dropped by regmap mask
- [Medium] net: pcs: Kernel panic on NULL pointer in nxp_serdes_xpcs_destroy
--

commit fefa07f062a827745ea578ec9b3b8e4d9a1e9739
Author: Clark Wang <xiaoning.wang@nxp.com>

net: pcs: add NXP SerDes XPCS shared core

This commit adds a transport agnostic phylink PCS core for the Synopsys
DesignWare Ethernet XPCS and Ethernet PHY found on NXP S32G and i.MX SoCs.
It provides configuration and link state handling, operating on regmaps
supplied by platform-specific glue drivers.

> diff --git a/drivers/net/pcs/pcs-nxp-serdes-xpcs.c b/drivers/net/pcs/pcs-nxp-serdes-xpcs.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/net/pcs/pcs-nxp-serdes-xpcs.c
[ ... ]
> +static int nxp_serdes_xpcs_get_state_c37_sgmii(struct nxp_serdes_xpcs *xpcs,
> +					       unsigned int neg_mode,
> +					       struct phylink_link_state *state)
> +{
[ ... ]
> +	if (ret & DW_VR_MII_C37_ANSGM_SP_LNKSTS) {
[ ... ]
> +	} else if (ret == DW_VR_MII_AN_STS_C37_ANCMPLT_INTR) {
> +		int speed, duplex;
> +
> +		state->link = true;
> +
> +		speed = nxp_serdes_xpcs_read(xpcs, MDIO_MMD_VEND2, MII_BMCR);
> +		if (speed < 0)
> +			return speed;
> +
> +		speed &= BMCR_SPEED100 | BMCR_SPEED1000;
> +		if (speed == BMCR_SPEED1000)
> +			state->speed = SPEED_1000;
> +		else if (speed == BMCR_SPEED100)
> +			state->speed = SPEED_100;
> +		else if (speed == 0)
> +			state->speed = SPEED_10;
> +
> +		duplex = nxp_serdes_xpcs_read(xpcs, MDIO_MMD_VEND2,
> +					      MII_ADVERTISE);
> +		if (duplex < 0)
> +			return duplex;
> +
> +		if (duplex & ADVERTISE_1000XFULL)
> +			state->duplex = DUPLEX_FULL;
> +		else if (duplex & ADVERTISE_1000XHALF)
> +			state->duplex = DUPLEX_HALF;
> +
> +		nxp_serdes_xpcs_write(xpcs, MDIO_MMD_VEND2,
> +				      DW_VR_MII_AN_INTR_STS, 0);
> +	}
> +
> +	return 0;
> +}

[Severity: High]
Does this code override a valid link-down status and clear the interrupt,
which could cause persistent link flaps?

In nxp_serdes_xpcs_get_state_c37_sgmii(), if the link is actually down 
(DW_VR_MII_C37_ANSGM_SP_LNKSTS is clear) but AN completed 
(DW_VR_MII_AN_STS_C37_ANCMPLT_INTR is set), this block forces state->link
to true and writes 0 to DW_VR_MII_AN_INTR_STS. The next poll might read 0
and report the link as down, creating an endless link flap.

Additionally, can the auto-negotiated duplex be resolved incorrectly here
by reading the local advertisement (MII_ADVERTISE) rather than the link
partner's ability?

[ ... ]
> +static void nxp_serdes_xpcs_link_up_usxgmii(struct nxp_serdes_xpcs *xpcs,
> +					    int speed)
> +{
[ ... ]
> +	ret = nxp_serdes_xpcs_modify(xpcs, MDIO_MMD_VEND2, MII_BMCR,
> +				     DW_USXGMII_SS_MASK,
> +				     speed_sel | DW_USXGMII_FULL);

[Severity: High]
Does this regmap modification drop the DW_USXGMII_FULL configuration?

Looking at nxp_serdes_xpcs_link_up_usxgmii(), the code attempts to set the
duplex by passing DW_USXGMII_FULL to nxp_serdes_xpcs_modify().

However, DW_USXGMII_FULL is not included in DW_USXGMII_SS_MASK. Because
nxp_serdes_xpcs_modify() masks the target value with the provided mask,
the full-duplex configuration will be filtered out and never written to
the hardware.

[ ... ]
> +void nxp_serdes_xpcs_destroy(struct phylink_pcs *pcs)
> +{
> +	struct nxp_serdes_xpcs *xpcs = phylink_pcs_to_nxp_serdes_xpcs(pcs);
> +
> +	if (!xpcs)
> +		return;
> +
> +	kfree(xpcs);
> +}

[Severity: Medium]
Can this regression cause a panic due to evaluating container_of() before
checking for NULL?

In nxp_serdes_xpcs_destroy(), xpcs is extracted from pcs using
phylink_pcs_to_nxp_serdes_xpcs() which is a container_of() wrapper. If a
caller passes a NULL pcs pointer, container_of() will yield a negative
offset. This bypasses the if (!xpcs) check, resulting in kfree() being
called with an invalid pointer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919-s32g_serdes-v3-0-9d68868c1e89@oss.nxp.com?part=4

  parent reply	other threads:[~2026-09-20  6:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19  6:54 [PATCH RFC v3 00/12] Add support for the NXP S32G SerDes subsystem Jan Petrous via B4 Relay
2026-09-19  6:54 ` [PATCH RFC v3 01/12] dt-bindings: phy: Add " Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 02/12] dt-bindings: net: nxp,s32-dwmac: Document pcs-handle Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 03/12] dt-bindings: PCI: nxp,s32g-pcie: Fix SerDes PHY phandle in example Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 04/12] net: pcs: add NXP SerDes XPCS shared core Jan Petrous via B4 Relay
2026-09-19 15:31   ` Maxime Chevallier
2026-09-19 16:31     ` Coia Prant
2026-09-20  6:54   ` sashiko-bot [this message]
2026-09-20 18:39   ` Andrew Lunn
2026-09-19  6:54 ` [PATCH RFC v3 05/12] net: pcs: Add NXP S32G XPCS driver Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-20 17:07   ` Andrew Lunn
2026-09-19  6:54 ` [PATCH RFC v3 06/12] phy: freescale: s32g: Add SerDes subsystem PHY Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 07/12] net: stmmac: dwmac-s32: Add SGMII support Jan Petrous via B4 Relay
2026-09-19 12:04   ` Maxime Chevallier
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 08/12] MAINTAINERS: Add NXP S32G SerDes and SerDes xPCS core entries Jan Petrous via B4 Relay
2026-09-19  6:54 ` [PATCH RFC v3 09/12] arm64: dts: s32g: Add SCMI reset controller Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 10/12] arm64: dts: s32g: Add SerDes controller nodes Jan Petrous via B4 Relay
2026-09-20  6:55   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 11/12] arm64: dts: s32g: Add PCIe " Jan Petrous via B4 Relay
2026-09-20  6:55   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 12/12] arm64: dts: s32g: Add S32G3-RDB3 SerDes routing variants Jan Petrous via B4 Relay
2026-09-20  6:55   ` 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=20260920065458.E16661F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=jan.petrous@oss.nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    --cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox