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", > }; > > /**
