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 D22EB35AC0A for ; Mon, 13 Apr 2026 10:51:41 +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=1776077501; cv=none; b=hL/ITJM+1uljSFs/2qZoGt0XU7sEEkC8Y8RBxS8vq+H1WxMQCJRc9pNXCaFvGEiH0/7jhnjq1nEITbtDAaQ3uJ9y4gN40cM8nSEOpBjnPoNckrQ66ki3Ict5xlVGn613X6qmxfZ2A9FT/NVU7p3+mFb6bfvHTBFYoxiYKVCOj1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776077501; c=relaxed/simple; bh=bQAYLLneMNI9jJ1/diAoWNp9Xyr3yX5LkVwGEeYI2S8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Yyva94DbKz+rJ/LuE4gbpgmZSt7y0MFl7X8lu7FKdewD4iS4j72vkT1GcfFD0olt/epJQh5LCSn/xp4UzPJDpQEkTBfdbDA7z3esczHL2u6escQwH/wgzBQfs0hihRbnwPS1/rGEQOG07BOqmBAeN6y3L2GLh50VhQA7eAIBD/M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ckYRyYKK; 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="ckYRyYKK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8598BC116C6; Mon, 13 Apr 2026 10:51:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776077501; bh=bQAYLLneMNI9jJ1/diAoWNp9Xyr3yX5LkVwGEeYI2S8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ckYRyYKK5bD0iIR40GZXA42qZENIZOJr1ylDSGcf3h6BYfOwxcW65R74jNxFAYBNU ZWqgQRz2Hq7TvA1vfxbF4OxSvEaLiKyaih/RJwUHxYWCPxD/RP+WwXrjeKO5CcnkAt WfE9fv6F3SvrVD7BWJ7XkchBBcvg9XlKTAnOmRAcwhiqgE6xIANo794HiqRRzPLX2z lNzeJ1RsHfBz/Vt1cfm482NV4wyzVHONFRewnL04Rro8al9N3YaJckxWZPmAJXNZjT M6vL6qY1DV8pI2i3OmQS7BsQxk6DMAy3g8Ax9gpQpNWGOAtCQjn/jUtUAdsIs9j89C HvXelyWsubkxg== From: Simon Horman To: aleksandr.loktionov@intel.com Cc: 'Simon Horman' , intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com, netdev@vger.kernel.org Subject: Re: [PATCH iwl-net v2 3/6] ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update Date: Mon, 13 Apr 2026 11:51:11 +0100 Message-ID: <20260413105110.695930-2-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260408131154.2661818-4-aleksandr.loktionov@intel.com> References: <20260408131154.2661818-4-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 From: 'Simon Horman' This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update This commit adds a call to hw->mac.ops.setup_fc() before fc_enable() in the watchdog task when the link comes up, aiming to prevent MDD events after an NVM update by reprogramming flow-control autonegotiation. > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > @@ -8031,7 +8031,14 @@ static void ixgbe_watchdog_update_link(struct ixgbe_adapter *adapter) > pfc_en |= !!(adapter->ixgbe_ieee_pfc->pfc_en); > > if (link_up && !((adapter->flags & IXGBE_FLAG_DCB_ENABLED) && pfc_en)) { > - hw->mac.ops.fc_enable(hw); > + /* Re-program flow-control autoneg before applying the result. > + * If setup_fc() fails its output is invalid; skip fc_enable() > + * to avoid committing stale capability bits that trigger MDD. > + */ > + if (hw->mac.ops.setup_fc && hw->mac.ops.setup_fc(hw)) Will calling setup_fc() unconditionally from the link-up watchdog cause an infinite link flapping loop on 82599 backplane interfaces? For backplane interfaces like KX/KX4/KR, setup_fc() resolves to ixgbe_setup_fc_generic(), which then calls hw->mac.ops.prot_autoc_write(). On 82599 hardware, this calls prot_autoc_write_82599(), which unconditionally executes ixgbe_reset_pipeline_82599(). Since ixgbe_reset_pipeline_82599() toggles the IXGBE_AUTOC_AN_RESTART bit, would this drop the link immediately to restart Auto-Negotiation? If the link drops, it would trigger a link-down LSC interrupt. Once Auto-Negotiation completes, the link would come back up, triggering another link-up LSC interrupt. This would cause ixgbe_watchdog_update_link() to run again, repeating the cycle. > + e_warn(drv, "setup_fc failed, skipping fc_enable\n"); > + else > + hw->mac.ops.fc_enable(hw); > ixgbe_set_rx_drop_en(adapter); > }