From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, paul.greenwalt@intel.com,
netdev@vger.kernel.org, anthony.l.nguyen@intel.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: update ice_link_mode_str_high() with 200G
Date: Fri, 20 Mar 2026 19:19:04 +0000 [thread overview]
Message-ID: <20260320191903.161126-2-horms@kernel.org> (raw)
In-Reply-To: <20260320050552.422715-1-aleksandr.loktionov@intel.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
---
ice: update ice_link_mode_str_high() with 200G
This patch adds string entries to ice_link_mode_str_high[] for 200G and
400GBASE-FR8 PHY types to fix ice_dump_phy_type() debug output for E825C
hardware.
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> index ce11fea122d0..7cdd6a043d86 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -84,6 +84,17 @@ static const char * const ice_link_mode_str_high[] = {
> [2] = "100G_CAUI2",
> [3] = "100G_AUI2_AOC_ACC",
> [4] = "100G_AUI2",
> + [5] = "200G_CR4_PAM4",
> + [6] = "200G_SR4",
> + [7] = "200G_FR4",
> + [8] = "200G_LR4",
> + [9] = "200G_DR4",
> + [10] = "200G_KR4_PAM4",
> + [11] = "200G_AUI4_AOC_ACC",
> + [12] = "200G_AUI4",
> + [13] = "200G_AUI8_AOC_ACC",
> + [14] = "200G_AUI8",
> + [15] = "400GBASE_FR8",
> };
>
> /**
Are entries [13], [14], and [15] missing their corresponding hardware
definitions?
The patch adds strings for indices 13-15, but ICE_PHY_TYPE_HIGH_MAX_INDEX
remains defined as 12 in ice_adminq_cmd.h (line 1047), and no
ICE_PHY_TYPE_HIGH_* bit definitions exist for these three types.
Other driver code uses MAX_INDEX as a bound:
drivers/net/ethernet/intel/ice/ice_common.c:ice_get_phy_type_high() {
for (index = 0; index <= ICE_PHY_TYPE_HIGH_MAX_INDEX; index++)
...
}
This creates an inconsistency where ice_dump_phy_type() can print these
strings via debug output, but code checking PHY types based on MAX_INDEX
will not recognize indices 13-15.
If E825C hardware truly supports these PHY types, should this patch also
include the hardware definitions (ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC =
BIT_ULL(13), etc.) and update MAX_INDEX to 15?
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, paul.greenwalt@intel.com,
netdev@vger.kernel.org, anthony.l.nguyen@intel.com
Subject: Re: [PATCH iwl-next] ice: update ice_link_mode_str_high() with 200G
Date: Fri, 20 Mar 2026 19:19:04 +0000 [thread overview]
Message-ID: <20260320191903.161126-2-horms@kernel.org> (raw)
In-Reply-To: <20260320050552.422715-1-aleksandr.loktionov@intel.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
---
ice: update ice_link_mode_str_high() with 200G
This patch adds string entries to ice_link_mode_str_high[] for 200G and
400GBASE-FR8 PHY types to fix ice_dump_phy_type() debug output for E825C
hardware.
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> index ce11fea122d0..7cdd6a043d86 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -84,6 +84,17 @@ static const char * const ice_link_mode_str_high[] = {
> [2] = "100G_CAUI2",
> [3] = "100G_AUI2_AOC_ACC",
> [4] = "100G_AUI2",
> + [5] = "200G_CR4_PAM4",
> + [6] = "200G_SR4",
> + [7] = "200G_FR4",
> + [8] = "200G_LR4",
> + [9] = "200G_DR4",
> + [10] = "200G_KR4_PAM4",
> + [11] = "200G_AUI4_AOC_ACC",
> + [12] = "200G_AUI4",
> + [13] = "200G_AUI8_AOC_ACC",
> + [14] = "200G_AUI8",
> + [15] = "400GBASE_FR8",
> };
>
> /**
Are entries [13], [14], and [15] missing their corresponding hardware
definitions?
The patch adds strings for indices 13-15, but ICE_PHY_TYPE_HIGH_MAX_INDEX
remains defined as 12 in ice_adminq_cmd.h (line 1047), and no
ICE_PHY_TYPE_HIGH_* bit definitions exist for these three types.
Other driver code uses MAX_INDEX as a bound:
drivers/net/ethernet/intel/ice/ice_common.c:ice_get_phy_type_high() {
for (index = 0; index <= ICE_PHY_TYPE_HIGH_MAX_INDEX; index++)
...
}
This creates an inconsistency where ice_dump_phy_type() can print these
strings via debug output, but code checking PHY types based on MAX_INDEX
will not recognize indices 13-15.
If E825C hardware truly supports these PHY types, should this patch also
include the hardware definitions (ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC =
BIT_ULL(13), etc.) and update MAX_INDEX to 15?
next prev parent reply other threads:[~2026-03-20 19:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 5:05 [Intel-wired-lan] [PATCH iwl-next] ice: update ice_link_mode_str_high() with 200G Aleksandr Loktionov
2026-03-20 5:05 ` Aleksandr Loktionov
2026-03-20 19:19 ` Simon Horman [this message]
2026-03-20 19:19 ` 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=20260320191903.161126-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.org \
--cc=paul.greenwalt@intel.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.