From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: 'Simon Horman' <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [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 [thread overview]
Message-ID: <20260413105110.695930-2-horms@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-4-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
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);
> }
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>,
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 [thread overview]
Message-ID: <20260413105110.695930-2-horms@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-4-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
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);
> }
next prev parent reply other threads:[~2026-04-13 10:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 13:11 [Intel-wired-lan] [PATCH iwl-net v2 0/6] ixgbe: six bug fixes Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 1/6] ixgbe: fix SWFW semaphore timeout for X550 family Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:52 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:52 ` Simon Horman
2026-04-14 0:56 ` [Intel-wired-lan] " Jacob Keller
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 2/6] ixgbe: add bounds check for debugfs register access Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:30 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:30 ` Simon Horman
2026-04-14 1:00 ` [Intel-wired-lan] " Jacob Keller
2026-04-14 17:16 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 3/6] ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:51 ` Simon Horman [this message]
2026-04-13 10:51 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 4/6] ixgbe: fix cls_u32 nexthdr path returning success when no entry installed Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 10:54 ` [Intel-wired-lan] " Simon Horman
2026-04-13 10:54 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 5/6] ixgbe: fix ITR value overflow in adaptive interrupt throttling Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 13:39 ` [Intel-wired-lan] " Simon Horman
2026-04-13 13:39 ` Simon Horman
2026-04-08 13:11 ` [Intel-wired-lan] [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr() Aleksandr Loktionov
2026-04-08 13:11 ` Aleksandr Loktionov
2026-04-13 13:43 ` [Intel-wired-lan] " Simon Horman
2026-04-13 13:43 ` Simon Horman
2026-04-13 14:02 ` [Intel-wired-lan] " Simon Horman
2026-04-13 14:02 ` Simon Horman
2026-04-13 14:03 ` [Intel-wired-lan] " Simon Horman
2026-04-13 14:03 ` Simon Horman
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=20260413105110.695930-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 \
/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.