From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: Simon Horman <horms@kernel.org>,
anthony.l.nguyen@intel.com, intel-wired-lan@lists.osuosl.org,
paul.greenwalt@intel.com, netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: update ice_link_mode_str_high() with 200G
Date: Tue, 24 Mar 2026 18:13:37 +0000 [thread overview]
Message-ID: <20260324181337.264904-2-horms@kernel.org> (raw)
In-Reply-To: <20260323085840.3272274-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 updates ice_link_mode_str_high() to add strings for 200G PHY
types supported by E825C hardware. It also adds three new PHY type bit
definitions for indices 13-15 and increases ICE_PHY_TYPE_HIGH_MAX_INDEX
from 12 to 15.
> diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> index 859e9c66f3e7..f64d2efdc478 100644
> --- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> +++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> @@ -1044,7 +1044,10 @@ struct ice_aqc_get_phy_caps {
> #define ICE_PHY_TYPE_HIGH_200G_KR4_PAM4 BIT_ULL(10)
> #define ICE_PHY_TYPE_HIGH_200G_AUI4_AOC_ACC BIT_ULL(11)
> #define ICE_PHY_TYPE_HIGH_200G_AUI4 BIT_ULL(12)
> -#define ICE_PHY_TYPE_HIGH_MAX_INDEX 12
> +#define ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC BIT_ULL(13)
> +#define ICE_PHY_TYPE_HIGH_200G_AUI8 BIT_ULL(14)
> +#define ICE_PHY_TYPE_HIGH_400GBASE_FR8 BIT_ULL(15)
> +#define ICE_PHY_TYPE_HIGH_MAX_INDEX 15
The new PHY types added here (bits 13-15) will now be iterated by
ice_update_phy_type() when it loops from 0 to ICE_PHY_TYPE_HIGH_MAX_INDEX,
calling ice_get_link_speed_based_on_phy_type() for each index. However,
does ice_get_link_speed_based_on_phy_type() have cases for these three new
PHY types?
Looking at ice_get_link_speed_based_on_phy_type() in ice_common.c, the
switch statement has cases for 200G PHY types like ICE_PHY_TYPE_HIGH_200G_CR4_PAM4
through ICE_PHY_TYPE_HIGH_200G_AUI4 (indices 5-12) that return ICE_AQ_LINK_SPEED_200GB.
But the three newly added PHY types aren't present:
- ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC (bit 13)
- ICE_PHY_TYPE_HIGH_200G_AUI8 (bit 14)
- ICE_PHY_TYPE_HIGH_400GBASE_FR8 (bit 15)
Without these cases, won't they fall through to the default case and return
ICE_AQ_LINK_SPEED_UNKNOWN? The first two appear to be 200G types based on
their naming, so shouldn't they be added to the switch statement to return
ICE_AQ_LINK_SPEED_200GB?
For ICE_PHY_TYPE_HIGH_400GBASE_FR8, is there an ICE_AQ_LINK_SPEED_400GB
constant defined? Looking at ice_adminq_cmd.h, the link speed constants go
from ICE_AQ_LINK_SPEED_200GB (BIT(11)) directly to ICE_AQ_LINK_SPEED_UNKNOWN
(BIT(15)). Without an ICE_AQ_LINK_SPEED_400GB constant, how should the 400G
PHY type be mapped?
This appears to leave the new PHY types non-functional for speed
determination, even though the commit message states they are needed for
E825C hardware support.
>
> struct ice_aqc_get_phy_caps_data {
> __le64 phy_type_low; /* Use values from ICE_PHY_TYPE_LOW_* */
> 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",
> };
>
> /**
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>,
anthony.l.nguyen@intel.com, intel-wired-lan@lists.osuosl.org,
paul.greenwalt@intel.com, netdev@vger.kernel.org
Subject: Re: [PATCH iwl-next v2] ice: update ice_link_mode_str_high() with 200G
Date: Tue, 24 Mar 2026 18:13:37 +0000 [thread overview]
Message-ID: <20260324181337.264904-2-horms@kernel.org> (raw)
In-Reply-To: <20260323085840.3272274-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 updates ice_link_mode_str_high() to add strings for 200G PHY
types supported by E825C hardware. It also adds three new PHY type bit
definitions for indices 13-15 and increases ICE_PHY_TYPE_HIGH_MAX_INDEX
from 12 to 15.
> diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> index 859e9c66f3e7..f64d2efdc478 100644
> --- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> +++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
> @@ -1044,7 +1044,10 @@ struct ice_aqc_get_phy_caps {
> #define ICE_PHY_TYPE_HIGH_200G_KR4_PAM4 BIT_ULL(10)
> #define ICE_PHY_TYPE_HIGH_200G_AUI4_AOC_ACC BIT_ULL(11)
> #define ICE_PHY_TYPE_HIGH_200G_AUI4 BIT_ULL(12)
> -#define ICE_PHY_TYPE_HIGH_MAX_INDEX 12
> +#define ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC BIT_ULL(13)
> +#define ICE_PHY_TYPE_HIGH_200G_AUI8 BIT_ULL(14)
> +#define ICE_PHY_TYPE_HIGH_400GBASE_FR8 BIT_ULL(15)
> +#define ICE_PHY_TYPE_HIGH_MAX_INDEX 15
The new PHY types added here (bits 13-15) will now be iterated by
ice_update_phy_type() when it loops from 0 to ICE_PHY_TYPE_HIGH_MAX_INDEX,
calling ice_get_link_speed_based_on_phy_type() for each index. However,
does ice_get_link_speed_based_on_phy_type() have cases for these three new
PHY types?
Looking at ice_get_link_speed_based_on_phy_type() in ice_common.c, the
switch statement has cases for 200G PHY types like ICE_PHY_TYPE_HIGH_200G_CR4_PAM4
through ICE_PHY_TYPE_HIGH_200G_AUI4 (indices 5-12) that return ICE_AQ_LINK_SPEED_200GB.
But the three newly added PHY types aren't present:
- ICE_PHY_TYPE_HIGH_200G_AUI8_AOC_ACC (bit 13)
- ICE_PHY_TYPE_HIGH_200G_AUI8 (bit 14)
- ICE_PHY_TYPE_HIGH_400GBASE_FR8 (bit 15)
Without these cases, won't they fall through to the default case and return
ICE_AQ_LINK_SPEED_UNKNOWN? The first two appear to be 200G types based on
their naming, so shouldn't they be added to the switch statement to return
ICE_AQ_LINK_SPEED_200GB?
For ICE_PHY_TYPE_HIGH_400GBASE_FR8, is there an ICE_AQ_LINK_SPEED_400GB
constant defined? Looking at ice_adminq_cmd.h, the link speed constants go
from ICE_AQ_LINK_SPEED_200GB (BIT(11)) directly to ICE_AQ_LINK_SPEED_UNKNOWN
(BIT(15)). Without an ICE_AQ_LINK_SPEED_400GB constant, how should the 400G
PHY type be mapped?
This appears to leave the new PHY types non-functional for speed
determination, even though the commit message states they are needed for
E825C hardware support.
>
> struct ice_aqc_get_phy_caps_data {
> __le64 phy_type_low; /* Use values from ICE_PHY_TYPE_LOW_* */
> 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",
> };
>
> /**
next prev parent reply other threads:[~2026-03-24 18:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 8:58 [Intel-wired-lan] [PATCH iwl-next v2] ice: update ice_link_mode_str_high() with 200G Aleksandr Loktionov
2026-03-23 8:58 ` Aleksandr Loktionov
2026-03-23 9:10 ` [Intel-wired-lan] " Paul Menzel
2026-03-24 18:13 ` Simon Horman [this message]
2026-03-24 18:13 ` Simon Horman
2026-03-24 18:16 ` [Intel-wired-lan] " Simon Horman
2026-03-24 18:16 ` Simon Horman
2026-03-25 7:01 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-03-25 7:01 ` Loktionov, Aleksandr
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=20260324181337.264904-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.