public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: vikas.gupta@broadcom.com
Cc: Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	pavan.chebbi@broadcom.com, andrew+netdev@lunn.ch,
	michael.chan@broadcom.com, vsrama-krishna.nemani@broadcom.com,
	bhargava.marreddy@broadcom.com, ajit.khaparde@broadcom.com,
	pabeni@redhat.com, edumazet@google.com, kuba@kernel.org,
	davem@davemloft.net, rajashekar.hudumula@broadcom.com
Subject: Re: [PATCH net-next v8 03/10] bng_en: add ethtool link settings, get_link, and nway_reset
Date: Fri, 20 Mar 2026 11:26:30 +0000	[thread overview]
Message-ID: <20260320112630.2065132-1-horms@kernel.org> (raw)
In-Reply-To: <20260319055124.1350670-4-vikas.gupta@broadcom.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
bng_en: add ethtool link settings, get_link, and nway_reset

Add get/set_link_ksettings, get_link, and nway_reset support. Report
supported, advertised, and link-partner speeds across NRZ, PAM4, and
PAM4-112 signaling modes. Enable lane count reporting.

> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge.h b/drivers/net/ethernet/broadcom/bnge/bnge.h
> index 83ee4749cc70..e9b83c0c64b6 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge.h
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge.h

[ ... ]

> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_link.c b/drivers/net/ethernet/broadcom/bnge/bnge_link.c
> index e5a7b48f6a3f..03beb5593069 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge_link.c
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_link.c

[ ... ]

> +int bnge_set_link_ksettings(struct net_device *dev,
> +			    const struct ethtool_link_ksettings *lk_ksettings)
> +{
> +	const struct ethtool_link_settings *base = &lk_ksettings->base;
> +	struct bnge_ethtool_link_info *elink_info;
> +	struct bnge_net *bn = netdev_priv(dev);
> +	struct bnge_link_info *link_info;
> +	struct bnge_dev *bd = bn->bd;
> +	bool set_pause = false;
> +	int rc = 0;
> +
> +	elink_info = &bn->eth_link_info;
> +	link_info = &bd->link_info;
> +
> +	if (!BNGE_PHY_CFG_ABLE(bd))
> +		return -EOPNOTSUPP;
> +
> +	if (base->autoneg == AUTONEG_ENABLE) {
> +		bnge_set_ethtool_speeds(bn,
> +					lk_ksettings->link_modes.advertising);
> +		elink_info->autoneg |= BNGE_AUTONEG_SPEED;
> +		if (!elink_info->advertising && !elink_info->advertising_pam4) {
> +			elink_info->advertising =
> +				link_info->support_auto_speeds;
> +			elink_info->advertising_pam4 =
> +				link_info->support_pam4_auto_speeds;
> +		}

When autoneg is enabled but no speeds are advertised, does this code
correctly handle SPEEDS2 devices?

On a SPEEDS2 device (bd->phy_flags & BNGE_PHY_FL_SPEEDS2), the fallback
populates elink_info->advertising with support_auto_speeds and
elink_info->advertising_pam4 with support_pam4_auto_speeds.

However, for SPEEDS2 devices, the firmware expects speed masks encoded in
the SPEEDS2 format (using support_auto_speeds2), not the legacy format
(using support_auto_speeds or support_pam4_auto_speeds).

Looking at how this value is used in bnge_hwrm_set_link_common() in patch v2
(c367afb6b104):

    if (bd->phy_flags & BNGE_PHY_FL_SPEEDS2) {
        req->auto_link_speeds2_mask = elink_info->advertising;
        ...
    } else {
        req->auto_link_speed_mask = elink_info->advertising;
        req->auto_pam4_link_speed_mask = elink_info->advertising_pam4;
    }

The firmware will receive legacy NRZ speed bits in auto_link_speeds2_mask,
which it will interpret as SPEEDS2-encoded bits, potentially negotiating the
wrong link speed.

Compare with bnge_support_speed_dropped() in the same patch series
(c367afb6b104), which handles this case differently when support speeds
change:

    if (bd->phy_flags & BNGE_PHY_FL_SPEEDS2) {
        link_info->advertising = link_info->support_auto_speeds2;
        ...
    } else {
        link_info->advertising = link_info->support_auto_speeds;
        link_info->advertising_pam4 = link_info->support_pam4_auto_speeds;
    }

Should bnge_set_link_ksettings() check bd->phy_flags & BNGE_PHY_FL_SPEEDS2 and
use support_auto_speeds2 for the fallback on SPEEDS2 devices?

> +		/* any change to autoneg will cause link change, therefore the
> +		 * driver should put back the original pause setting in autoneg
> +		 */
> +		if (!(bd->phy_flags & BNGE_PHY_FL_NO_PAUSE))
> +			set_pause = true;
> +	} else {

[ ... ]

  reply	other threads:[~2026-03-20 11:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  5:51 [PATCH net-next v8 00/10] bng_en: add link management and statistics support Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 01/10] bng_en: add per-PF workqueue, timer, and slow-path task Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 02/10] bng_en: query PHY capabilities and report link status Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 03/10] bng_en: add ethtool link settings, get_link, and nway_reset Vikas Gupta
2026-03-20 11:26   ` Simon Horman [this message]
2026-03-21  3:11   ` Jakub Kicinski
2026-03-19  5:51 ` [PATCH net-next v8 04/10] bng_en: implement ethtool pauseparam operations Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 05/10] bng_en: add support for link async events Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 06/10] bng_en: add HW stats infra and structured ethtool ops Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 07/10] bng_en: periodically fetch and accumulate hardware statistics Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 08/10] bng_en: implement ndo_get_stats64 Vikas Gupta
2026-03-19  5:51 ` [PATCH net-next v8 09/10] bng_en: implement netdev_stat_ops Vikas Gupta
2026-03-20 11:27   ` Simon Horman
2026-03-20 20:27     ` Bhargava Chenna Marreddy
2026-03-21  9:15       ` Simon Horman
2026-03-19  5:51 ` [PATCH net-next v8 10/10] bng_en: add support for ethtool -S stats display Vikas Gupta
2026-03-20 11:27   ` Simon Horman
2026-03-20 19:51     ` Bhargava Chenna Marreddy
2026-03-21  9:06       ` Simon Horman

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=20260320112630.2065132-1-horms@kernel.org \
    --to=horms@kernel.org \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bhargava.marreddy@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=rajashekar.hudumula@broadcom.com \
    --cc=vikas.gupta@broadcom.com \
    --cc=vsrama-krishna.nemani@broadcom.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