All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 1/6] ixgbe: fix SWFW semaphore timeout for X550 family
Date: Mon, 13 Apr 2026 11:52:28 +0100	[thread overview]
Message-ID: <20260413105228.GM469338@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-2-aleksandr.loktionov@intel.com>

On Wed, Apr 08, 2026 at 03:11:49PM +0200, Aleksandr Loktionov wrote:
> According to FW documentation, the most time-consuming FW operation is
> Shadow RAM (SR) dump which takes up to 3.2 seconds.  For X550 family
> devices the module-update FW command can take over 4.5 s.  The default
> semaphore loop runs 200 iterations with a 5 ms sleep each, giving a
> maximum wait of 1 s -- not "200 ms" as previously stated in error.
> This is insufficient for X550 family FW update operations and causes
> spurious EBUSY failures.
> 
> Extend the SW/FW semaphore timeout from 1 s to 5 s (1000 iterations x
> 5 ms) for all three X550 variants: ixgbe_mac_X550, ixgbe_mac_X550EM_x,
> and ixgbe_mac_x550em_a.  All three share the same FW and exhibit the
> same worst-case latency.  Use three explicit mac.type comparisons rather
> than a range check so future MAC additions are not inadvertently
> captured.
> 
> The timeout variable is set immediately before the loop so the intent
> is clear, with an inline comment stating the resulting maximum delay.
> 
> Suggested-by: Soumen Karmakar <soumen.karmakar@intel.com>
> Cc: stable@vger.kernel.org
> Suggested-by: Marta Plantykow <marta.a.plantykow@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> v1 -> v2:
>  - Squash with 0015 (X550EM extension); fix commit message ("200ms" was
>    wrong, actual default is 1 s); replace >= / <= range check with three
>    explicit mac.type == comparisons per Tony Nguyen.

Reviewed-by: Simon Horman <horms@kernel.org>


WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH iwl-net v2 1/6] ixgbe: fix SWFW semaphore timeout for X550 family
Date: Mon, 13 Apr 2026 11:52:28 +0100	[thread overview]
Message-ID: <20260413105228.GM469338@kernel.org> (raw)
In-Reply-To: <20260408131154.2661818-2-aleksandr.loktionov@intel.com>

On Wed, Apr 08, 2026 at 03:11:49PM +0200, Aleksandr Loktionov wrote:
> According to FW documentation, the most time-consuming FW operation is
> Shadow RAM (SR) dump which takes up to 3.2 seconds.  For X550 family
> devices the module-update FW command can take over 4.5 s.  The default
> semaphore loop runs 200 iterations with a 5 ms sleep each, giving a
> maximum wait of 1 s -- not "200 ms" as previously stated in error.
> This is insufficient for X550 family FW update operations and causes
> spurious EBUSY failures.
> 
> Extend the SW/FW semaphore timeout from 1 s to 5 s (1000 iterations x
> 5 ms) for all three X550 variants: ixgbe_mac_X550, ixgbe_mac_X550EM_x,
> and ixgbe_mac_x550em_a.  All three share the same FW and exhibit the
> same worst-case latency.  Use three explicit mac.type comparisons rather
> than a range check so future MAC additions are not inadvertently
> captured.
> 
> The timeout variable is set immediately before the loop so the intent
> is clear, with an inline comment stating the resulting maximum delay.
> 
> Suggested-by: Soumen Karmakar <soumen.karmakar@intel.com>
> Cc: stable@vger.kernel.org
> Suggested-by: Marta Plantykow <marta.a.plantykow@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> v1 -> v2:
>  - Squash with 0015 (X550EM extension); fix commit message ("200ms" was
>    wrong, actual default is 1 s); replace >= / <= range check with three
>    explicit mac.type == comparisons per Tony Nguyen.

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2026-04-13 10:52 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   ` Simon Horman [this message]
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   ` [Intel-wired-lan] " Simon Horman
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=20260413105228.GM469338@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.