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?
