From: Mark Bloch <mbloch@nvidia.com>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
Simon Horman <horms@kernel.org>
Cc: <saeedm@nvidia.com>, <gal@nvidia.com>, <leonro@nvidia.com>,
<tariqt@nvidia.com>, Leon Romanovsky <leon@kernel.org>,
<netdev@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Shahar Shitrit <shshitrit@nvidia.com>,
"Mark Bloch" <mbloch@nvidia.com>
Subject: [PATCH net 9/9] net/mlx5e: Fix number of lanes to UNKNOWN when using data_rate_oper
Date: Tue, 10 Jun 2025 18:15:14 +0300 [thread overview]
Message-ID: <20250610151514.1094735-10-mbloch@nvidia.com> (raw)
In-Reply-To: <20250610151514.1094735-1-mbloch@nvidia.com>
From: Shahar Shitrit <shshitrit@nvidia.com>
When the link is up, either eth_proto_oper or ext_eth_proto_oper
typically reports the active link protocol, from which both speed
and number of lanes can be retrieved. However, in certain cases,
such as when a NIC is connected via a non-standard cable, the
firmware may not report the protocol.
In such scenarios, the speed can still be obtained from the
data_rate_oper field in PTYS register. Since data_rate_oper
provides only speed information and lacks lane details, it is
incorrect to derive the number of lanes from it.
This patch corrects the behavior by setting the number of lanes to
UNKNOWN instead of incorrectly using MAX_LANES when relying on
data_rate_oper.
Fixes: 7e959797f021 ("net/mlx5e: Enable lanes configuration when auto-negotiation is off")
Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index ea078c9f5d15..3cb8d3bf9044 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -43,7 +43,6 @@
#include "en/fs_ethtool.h"
#define LANES_UNKNOWN 0
-#define MAX_LANES 8
void mlx5e_ethtool_get_drvinfo(struct mlx5e_priv *priv,
struct ethtool_drvinfo *drvinfo)
@@ -1098,10 +1097,8 @@ static void get_link_properties(struct net_device *netdev,
speed = info->speed;
lanes = info->lanes;
duplex = DUPLEX_FULL;
- } else if (data_rate_oper) {
+ } else if (data_rate_oper)
speed = 100 * data_rate_oper;
- lanes = MAX_LANES;
- }
out:
link_ksettings->base.duplex = duplex;
--
2.34.1
next prev parent reply other threads:[~2025-06-10 15:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 15:15 [PATCH net 0/9] mlx5 misc fixes 2025-06-10 Mark Bloch
2025-06-10 15:15 ` [PATCH net 1/9] net/mlx5: Ensure fw pages are always allocated on same NUMA Mark Bloch
2025-06-13 16:22 ` Zhu Yanjun
2025-06-15 5:55 ` Moshe Shemesh
2025-06-15 14:44 ` Zhu Yanjun
2025-06-19 16:31 ` Moshe Shemesh
2025-06-10 15:15 ` [PATCH net 2/9] net/mlx5: Fix ECVF vports unload on shutdown flow Mark Bloch
2025-06-10 15:15 ` [PATCH net 3/9] net/mlx5: Fix return value when searching for existing flow group Mark Bloch
2025-06-10 15:15 ` [PATCH net 4/9] net/mlx5: HWS, Init mutex on the correct path Mark Bloch
2025-06-10 15:15 ` [PATCH net 5/9] net/mlx5: HWS, fix missing ip_version handling in definer Mark Bloch
2025-06-10 15:15 ` [PATCH net 6/9] net/mlx5: HWS, make sure the uplink is the last destination Mark Bloch
2025-06-10 15:15 ` [PATCH net 7/9] net/mlx5e: Properly access RCU protected qdisc_sleeping variable Mark Bloch
2025-06-11 21:40 ` Jakub Kicinski
2025-06-12 7:31 ` Mark Bloch
2025-06-12 14:22 ` Jakub Kicinski
2025-06-12 14:47 ` Mark Bloch
2025-06-10 15:15 ` [PATCH net 8/9] net/mlx5e: Fix leak of Geneve TLV option object Mark Bloch
2025-06-10 15:15 ` Mark Bloch [this message]
2025-06-11 21:43 ` [PATCH net 0/9] mlx5 misc fixes 2025-06-10 Jakub Kicinski
2025-06-11 21:50 ` patchwork-bot+netdevbpf
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=20250610151514.1094735-10-mbloch@nvidia.com \
--to=mbloch@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=shshitrit@nvidia.com \
--cc=tariqt@nvidia.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
all inboxes | Powered by JetHome®