From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 5ABEB38D008 for ; Wed, 8 Apr 2026 13:11:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775653919; cv=none; b=FO56X3QFKcbcCz8qn7XZ0CErNQNx+4DIZcHsi4BATCRLfyfW/hVWio779/THPMYsmGAW1Q8tb055gm1gYIyRSNKlViwfplNjPCxYmdE7E3oSyU/otaSo5ctg91smIwNbR2b5l6zMbBAcHco1oA3dFPD7INltHZm/QJmPfZuK/4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775653919; c=relaxed/simple; bh=jqWWnbeGaAloNgo2/0T0yqS/cY0f70+KgebTL+VZ8HI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UF3fkV5Rme3DPeDqwERc1pNiezs5yFjn8HlWXWs9XQKCifr8hp2aL8ytAY6SpEhPYPHq/n/r1ocVxceHRXP6OS++A4s9CsO7A+coJQPs+UP53sH1gCOij+ltJgPEcbLUFDHXE86S9edgagRbTd6aB2pwvCoHdYAyfGr9FYNskvg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WogBYzQV; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WogBYzQV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775653918; x=1807189918; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jqWWnbeGaAloNgo2/0T0yqS/cY0f70+KgebTL+VZ8HI=; b=WogBYzQVLLLRsLbLfWYRcPYJijap9mk3Z9KRQIyTOKlwihwBtEHOvLrx dIQsPe+dI29htdQnNT0CPfLHNlxnvf9hkCyFGsdNmMQxHkOy//UC4tCVZ zGNjidVv0i6XWtkxjZpZ9L98tAEXvkcXAJ+wm5yaFp+9X1CKSNxAyDYUS w7mgMFJ4aP5dRGr6IQvRRVie3iREdPzN0Osvq3KyGmtXSEiu83kqnPEVT XtrPfgJw1RNF+xnrcdcpoTE3/gr4QTdOsxNLK+uq1mAGOOGxjkf2/eXqk QE9TkZk+bpQEdh3y9YB+MD6gxt98IpdK/xalGE8RDpC8e7fxznF/nvnsn g==; X-CSE-ConnectionGUID: XcD9/EHbR/qfXAq/gfppxA== X-CSE-MsgGUID: ZBcoD/NwQaOUqVfmuucatw== X-IronPort-AV: E=McAfee;i="6800,10657,11752"; a="102087226" X-IronPort-AV: E=Sophos;i="6.23,167,1770624000"; d="scan'208";a="102087226" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2026 06:11:58 -0700 X-CSE-ConnectionGUID: UYU4/WfkRCy55u/s3o2AYw== X-CSE-MsgGUID: pcGEyYDkTQuuRSYQcN+Hdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,167,1770624000"; d="scan'208";a="228714944" Received: from amlin-019-225.igk.intel.com ([10.102.19.225]) by orviesa007.jf.intel.com with ESMTP; 08 Apr 2026 06:11:57 -0700 From: Aleksandr Loktionov To: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com, aleksandr.loktionov@intel.com Cc: netdev@vger.kernel.org Subject: [PATCH iwl-net v2 1/6] ixgbe: fix SWFW semaphore timeout for X550 family Date: Wed, 8 Apr 2026 15:11:49 +0200 Message-ID: <20260408131154.2661818-2-aleksandr.loktionov@intel.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260408131154.2661818-1-aleksandr.loktionov@intel.com> References: <20260408131154.2661818-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 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 Cc: stable@vger.kernel.org Suggested-by: Marta Plantykow Signed-off-by: Aleksandr Loktionov --- 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. drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c index e67e2fe..a3c8f51 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c @@ -577,6 +577,15 @@ int ixgbe_acquire_swfw_sync_X540(struct ixgbe_hw *hw, u32 mask) swmask |= swi2c_mask; fwmask |= swi2c_mask << 2; + /* Extend to 5 s (1000 x 5 ms) for X550 family; default is 1 s + * (200 x 5 ms). FW SR-dump takes up to 3.2 s; module-update up + * to 4.5 s. + */ + if (hw->mac.type == ixgbe_mac_X550 || + hw->mac.type == ixgbe_mac_X550EM_x || + hw->mac.type == ixgbe_mac_x550em_a) + timeout = 1000; + for (i = 0; i < timeout; i++) { /* SW NVM semaphore bit is used for access to all * SW_FW_SYNC bits (not just NVM) -- 2.52.0