From: Jacob Keller <jacob.e.keller@intel.com>
To: Aaron Ma <aaron.ma@canonical.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Richard Cochran <richardcochran@gmail.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Dan Nowlin <dan.nowlin@intel.com>,
Brett Creeley <brett.creeley@intel.com>,
"moderated list:INTEL ETHERNET DRIVERS"
<intel-wired-lan@lists.osuosl.org>
Subject: Re: [PATCH 1/5] ice: check the full PF reset polling limit
Date: Tue, 27 Oct 2026 14:35:51 -0700 [thread overview]
Message-ID: <f225d50e-fe71-4344-a88c-3c9e678a6211@intel.com> (raw)
In-Reply-To: <20261019105155.3793063-2-aaron.ma@canonical.com>
On 10/19/2026 3:51 AM, Aaron Ma wrote:
> The PF reset polling loop includes the Global Configuration Lock timeout
> in addition to the normal PF reset wait. Its timeout check still compares
> the iteration count against only the normal PF reset wait.
>
> Consequently, exhausting the extended loop reports success while PFSWR
> is still set. A reset completing exactly at the old limit can instead
> report a false failure. Subsequent initialization must not proceed on
> the assumption that an unfinished reset succeeded.
>
> Compare the count against the same bound used by the polling loop.
>
> Fixes: c9a12d6d2091 ("ice: Increase timeout after PFR")
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> drivers/net/ethernet/intel/ice/ice_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> index 04633103e3e61..82b803e74aac0 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -1291,7 +1291,7 @@ static int ice_pf_reset(struct ice_hw *hw)
> mdelay(1);
> }
>
> - if (cnt == ICE_PF_RESET_WAIT_COUNT) {
> + if (cnt == ICE_GLOBAL_CFG_LOCK_TIMEOUT + ICE_PF_RESET_WAIT_COUNT) {
> ice_debug(hw, ICE_DBG_INIT, "PF reset polling failed to complete.\n");
> return -EIO;
> }
This conflicts with
https://lore.kernel.org/intel-wired-lan/20261002130752.2597259-9-poros@redhat.com/
which is part of the series
https://lore.kernel.org/intel-wired-lan/20261002130752.2597259-1-poros@redhat.com/
I think Petr's fix is more complete, checking for the actual reset
status is more reliable than *either* the old or this check.
I'm rejecting just this one patch from the series and won't apply it. If
you need to rebase please exlude that fix in v2 or later and we'll carry
the better fix from Petr as it goes through the net tree.
Thanks,
Jake
next prev parent reply other threads:[~2026-10-27 21:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 10:51 [PATCH 0/5] ice: fix reset and suspend paths Aaron Ma
2026-10-19 10:51 ` [PATCH 1/5] ice: check the full PF reset polling limit Aaron Ma
2026-10-19 11:28 ` Temerkhanov, Sergey
2026-10-19 11:30 ` Przemek Kitszel
2026-10-27 21:35 ` Jacob Keller [this message]
2026-10-19 10:51 ` [PATCH 2/5] ice: retain the adapter throughout hardware initialization and teardown Aaron Ma
2026-10-19 11:29 ` Temerkhanov, Sergey
2026-10-20 9:24 ` Przemek Kitszel
2026-10-22 18:06 ` Jacob Keller
2026-10-19 10:51 ` [PATCH 3/5] ice: scope global configuration lock to the adapter Aaron Ma
2026-10-21 11:12 ` Loktionov, Aleksandr
2026-10-22 8:17 ` Aaron Ma
2026-10-22 11:10 ` Przemek Kitszel
2026-10-22 18:19 ` Jacob Keller
2026-10-19 10:51 ` [PATCH 4/5] ice: clear DVM boost table before scanning package hints Aaron Ma
2026-10-19 10:51 ` [PATCH 5/5] ice: quiesce PTP periodic work before system suspend Aaron Ma
2026-10-21 12:14 ` Loktionov, Aleksandr
2026-10-22 18:22 ` Jacob Keller
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=f225d50e-fe71-4344-a88c-3c9e678a6211@intel.com \
--to=jacob.e.keller@intel.com \
--cc=aaron.ma@canonical.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=brett.creeley@intel.com \
--cc=dan.nowlin@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®