All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: wei.fang@oss.nxp.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
Date: Wed, 01 Jul 2026 07:51:16 +0000	[thread overview]
Message-ID: <20260701075116.900D81F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260630072036.382761-8-wei.fang@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect unconditional advertisement of 5G/10G MAC capabilities and 10GBASER/XGMII interface modes for older ENETC v1 hardware.
--

commit afb9f1b607c70d3a6a854e15aaa034f99fb49f5c
Author: Claudiu Manoil <claudiu.manoil@nxp.com>

net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC

The ENETC pseudo-MACs are proprietary internal links that do not implement
any standard MII interface, so restrict their supported PHY interface modes
to PHY_INTERFACE_MODE_INTERNAL only. This also expands the supported
interface modes and MAC capabilities for standalone ENETC.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> index 3597cb81a7ccb..adf79a99a8c81 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c

[ ... ]

> @@ -400,25 +400,40 @@ int enetc_phylink_create(struct enetc_ndev_priv *priv, struct device_node *node,
>  {
>  	struct enetc_pf *pf = enetc_si_priv(priv->si);
>  	struct phylink *phylink;
> +	unsigned long mac_caps;
>  	int err;
>  
>  	pf->phylink_config.dev = &priv->ndev->dev;
>  	pf->phylink_config.type = PHYLINK_NETDEV;
> -	pf->phylink_config.mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
> -		MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD;
>  
>  	__set_bit(PHY_INTERFACE_MODE_INTERNAL,
>  		  pf->phylink_config.supported_interfaces);
> -	__set_bit(PHY_INTERFACE_MODE_SGMII,
> -		  pf->phylink_config.supported_interfaces);
> -	__set_bit(PHY_INTERFACE_MODE_1000BASEX,
> -		  pf->phylink_config.supported_interfaces);
> -	__set_bit(PHY_INTERFACE_MODE_2500BASEX,
> -		  pf->phylink_config.supported_interfaces);
> -	__set_bit(PHY_INTERFACE_MODE_USXGMII,
> -		  pf->phylink_config.supported_interfaces);
> -	phy_interface_set_rgmii(pf->phylink_config.supported_interfaces);
>  
> +	mac_caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE;
> +	if (!enetc_is_pseudo_mac(priv->si)) {
> +		mac_caps |= MAC_10 | MAC_100 | MAC_1000FD | MAC_2500FD |
> +			    MAC_5000FD | MAC_10000FD;
> +
> +		__set_bit(PHY_INTERFACE_MODE_SGMII,
> +			  pf->phylink_config.supported_interfaces);
> +		__set_bit(PHY_INTERFACE_MODE_1000BASEX,
> +			  pf->phylink_config.supported_interfaces);
> +		__set_bit(PHY_INTERFACE_MODE_2500BASEX,
> +			  pf->phylink_config.supported_interfaces);
> +		__set_bit(PHY_INTERFACE_MODE_USXGMII,
> +			  pf->phylink_config.supported_interfaces);
> +		__set_bit(PHY_INTERFACE_MODE_10GBASER,
> +			  pf->phylink_config.supported_interfaces);
> +		__set_bit(PHY_INTERFACE_MODE_XGMII,
> +			  pf->phylink_config.supported_interfaces);

[Severity: High]
Will this unconditionally enable 5G and 10G speeds for older ENETC v1
hardware?

If a 10G capable PHY is attached via USXGMII to an ENETC v1 port, it appears
the link will negotiate at 10Gbps instead of being capped at 2.5Gbps.

If that happens, enetc_sched_speed_set() doesn't seem to handle SPEED_5000 or
SPEED_10000:

drivers/net/ethernet/freescale/enetc/enetc_qos.c:enetc_sched_speed_set() {
	...
	switch (speed) {
	case SPEED_1000:
		pspeed = ENETC_PMR_PSPEED_1000M;
		break;
	case SPEED_2500:
		pspeed = ENETC_PMR_PSPEED_2500M;
		break;
	case SPEED_100:
		pspeed = ENETC_PMR_PSPEED_100M;
		break;
	case SPEED_10:
	default:
		pspeed = ENETC_PMR_PSPEED_10M;
	}
	...
}

This would cause it to fall through to 10 Mbps and break QoS scheduling.

Additionally, enetc_mac_config() doesn't appear to have support for
configuring the hardware for PHY_INTERFACE_MODE_10GBASER or
PHY_INTERFACE_MODE_XGMII which are now being advertised.

Should these new capabilities be restricted to newer hardware revisions?

> +		phy_interface_set_rgmii(pf->phylink_config.supported_interfaces);
> +	} else {
> +		mac_caps |= MAC_10FD | MAC_100FD | MAC_1000FD | MAC_2500FD |
> +			    MAC_5000FD | MAC_10000FD | MAC_20000FD |
> +			    MAC_25000FD;
> +	}
> +
> +	pf->phylink_config.mac_capabilities = mac_caps;
>  	phylink = phylink_create(&pf->phylink_config, of_fwnode_handle(node),
>  				 pf->if_mode, ops);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630072036.382761-1-wei.fang@oss.nxp.com?part=7

  reply	other threads:[~2026-07-01  7:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30  7:20 [PATCH net-next 00/14] net: enetc: cleanups and improvements wei.fang
2026-06-30  7:20 ` [PATCH net-next 01/14] net: enetc: extract common helpers for MAC promiscuous mode setting wei.fang
2026-06-30  7:20 ` [PATCH net-next 02/14] net: enetc: extract common helpers for MAC hash filter configuration wei.fang
2026-07-01  7:51   ` sashiko-bot
2026-07-01  8:20     ` Wei Fang (OSS)
2026-06-30  7:20 ` [PATCH net-next 03/14] net: enetc: convert ndo_set_rx_mode() to ndo_set_rx_mode_async() wei.fang
2026-06-30  7:20 ` [PATCH net-next 04/14] net: enetc: improve MAFT entry management with bitmap tracking wei.fang
2026-06-30  7:20 ` [PATCH net-next 05/14] net: enetc: use PCI device name for debugfs directory wei.fang
2026-06-30  7:20 ` [PATCH net-next 06/14] net: enetc: simplify enetc4_set_port_speed() wei.fang
2026-06-30  7:20 ` [PATCH net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC wei.fang
2026-07-01  7:51   ` sashiko-bot [this message]
2026-07-01 10:12     ` Wei Fang (OSS)
2026-06-30  7:20 ` [PATCH net-next 08/14] net: enetc: remove invalid code from enetc4_pl_mac_link_up() wei.fang
2026-06-30  7:20 ` [PATCH net-next 09/14] net: enetc: remove enetc4_set_default_si_vlan_promisc() wei.fang
2026-06-30  7:20 ` [PATCH net-next 10/14] net: enetc: refactor SI VLAN promiscuous mode configuration wei.fang
2026-06-30  7:20 ` [PATCH net-next 11/14] net: enetc: move enetc_set_si_vlan_promisc() to enetc_pf_common.c wei.fang
2026-06-30  7:20 ` [PATCH net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps wei.fang
2026-06-30  7:20 ` [PATCH net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver wei.fang
2026-07-01  7:51   ` sashiko-bot
2026-07-01 10:48     ` Wei Fang (OSS)
2026-06-30  7:20 ` [PATCH net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation wei.fang
2026-07-01  7:51   ` 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=20260701075116.900D81F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wei.fang@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.