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 {
[ ... ]
next prev parent 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