From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E35C418871F for ; Fri, 20 Mar 2026 19:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774034433; cv=none; b=YjTk5Hdxc0VyThxVT9amdXImFfZhn+D+88Oljupj5b2+D9dABpmjYyh4mqJsk77DXp7X14DbR0VUhitR5Oc4VsPQTgag2zw0HHQJts91D+lQVQAr7czZEESXGP+npvN6NqnYnPVWECJ6NHJPQ/OWeQn6QuNNstG7DRvCCWWJtGQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774034433; c=relaxed/simple; bh=OhEVl68IJXW23s3giI06+FZaV7LwoTDtzK/9RZFAhsE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qaD49AecSep9w564dzHFtRuYSA2jnkNs1jlFQtrG5wUtel6HlLzVwJumdB5TXiG8yAdAx7LztQcMzLrnSCyzuaHtSDnouvu8kx+TMldb/DiVvCwCmW29VZU5CmVy8atV3aqdbxQtQaoEUwgXg1PgIlSlwWGMZ7Jw598B9/LW1Hs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ti0NtSVD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ti0NtSVD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 313B4C4CEF7; Fri, 20 Mar 2026 19:20:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774034432; bh=OhEVl68IJXW23s3giI06+FZaV7LwoTDtzK/9RZFAhsE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ti0NtSVDUyLBzfZ+62YK5zqAfPsUiJgWDPmFm6Bh3YGi4F55eWMokv+C4kcoIGY87 M3GCy5VgEVaGwYwScNb0F0N4Sx6H0GQJ44aCfgwAo/aWbjYGkgq32z4gjm+f6/DG4+ cP7gykXyWr7VPiKXyBor0vCrUBsgGEPsCNsnqsQnn89xIoUhsRAy+AUAB8pb+uzCNd JuXSV81Kevn5NnyWgH434bbVgNllO0OwT8oyZUi6pgpbVF+uuAOK0Fov60PRmvHY/D /M3iRZaryh3FIYmVD4IJvpV+grZoYyK+U5d5LShNB7soT9cjlkQhVXURLOqEramwgZ 1oQGfRpISOkzQ== From: Simon Horman To: aleksandr.loktionov@intel.com Cc: Simon Horman , 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 Message-ID: <20260320191903.161126-2-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260320050552.422715-1-aleksandr.loktionov@intel.com> References: <20260320050552.422715-1-aleksandr.loktionov@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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?