From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, andrew+netdev@lunn.ch,
netdev@vger.kernel.org
Cc: Przemyslaw Korba <przemyslaw.korba@intel.com>,
anthony.l.nguyen@intel.com, jiri@resnulli.us,
vadim.fedorenko@linux.dev, przemyslaw.kitszel@intel.com,
arkadiusz.kubalewski@intel.com, Simon Horman <horms@kernel.org>,
Rinitha S <sx.rinitha@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: [PATCH net 07/10] ice: suppress DPLL errors during reset recovery
Date: Tue, 28 Jul 2026 14:09:04 -0700 [thread overview]
Message-ID: <20260728210909.3042004-8-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20260728210909.3042004-1-anthony.l.nguyen@intel.com>
From: Przemyslaw Korba <przemyslaw.korba@intel.com>
During reset recovery, the admin queue returns EBUSY which is expected
behavior. However, the DPLL subsystem was logging these as errors and
incrementing the error counter, potentially leading to unnecessary
warnings and even disabling the DPLL periodic worker if the threshold
was reached.
Suppress error logging and error counter increments when the admin
queue returns EBUSY, as this is expected during reset recovery and
not a real failure condition.
test case:
- ethtool --reset eth3 irq-shared dma-shared filter-shared offload-shared
mac-shared phy-shared ram-shared
- observe if dmesg EBUSY errors are gone
Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu")
Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_dpll.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
index 30c3a4db7d61..85a74cd6ea1f 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.c
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
@@ -793,7 +793,7 @@ ice_dpll_pin_state_update(struct ice_pf *pf, struct ice_dpll_pin *pin,
ret,
libie_aq_str(pf->hw.adminq.sq_last_status),
pin_type_name[pin_type], pin->idx);
- else
+ else if (pf->hw.adminq.sq_last_status != LIBIE_AQ_RC_EBUSY)
dev_err_ratelimited(ice_pf_to_dev(pf),
"err:%d %s failed to update %s pin:%u\n",
ret,
@@ -3024,7 +3024,8 @@ static int ice_dpll_pps_update_phase_offsets(struct ice_pf *pf,
*phase_offset_pins_updated = 0;
ret = ice_aq_get_cgu_input_pin_measure(&pf->hw, DPLL_TYPE_PPS, meas,
ARRAY_SIZE(meas));
- if (ret && pf->hw.adminq.sq_last_status == LIBIE_AQ_RC_EAGAIN) {
+ if (ret && (pf->hw.adminq.sq_last_status == LIBIE_AQ_RC_EAGAIN ||
+ pf->hw.adminq.sq_last_status == LIBIE_AQ_RC_EBUSY)) {
return 0;
} else if (ret) {
dev_err(ice_pf_to_dev(pf),
@@ -3086,10 +3087,12 @@ ice_dpll_update_state(struct ice_pf *pf, struct ice_dpll *d, bool init)
d->dpll_idx, d->prev_input_idx, d->input_idx,
d->dpll_state, d->prev_dpll_state, d->mode);
if (ret) {
- dev_err(ice_pf_to_dev(pf),
- "update dpll=%d state failed, ret=%d %s\n",
- d->dpll_idx, ret,
- libie_aq_str(pf->hw.adminq.sq_last_status));
+ /* EBUSY is expected during reset recovery, don't log error */
+ if (pf->hw.adminq.sq_last_status != LIBIE_AQ_RC_EBUSY)
+ dev_err(ice_pf_to_dev(pf),
+ "update dpll=%d state failed, ret=%d %s\n",
+ d->dpll_idx, ret,
+ libie_aq_str(pf->hw.adminq.sq_last_status));
return ret;
}
if (init) {
@@ -3158,7 +3161,9 @@ static void ice_dpll_periodic_work(struct kthread_work *work)
d->periodic_counter % dp->phase_offset_monitor_period == 0)
ret = ice_dpll_pps_update_phase_offsets(pf, &phase_offset_ntf);
if (ret) {
- d->cgu_state_acq_err_num++;
+ /* EBUSY is expected during reset recovery */
+ if (pf->hw.adminq.sq_last_status != LIBIE_AQ_RC_EBUSY)
+ d->cgu_state_acq_err_num++;
/* stop rescheduling this worker */
if (d->cgu_state_acq_err_num >
ICE_CGU_STATE_ACQ_ERR_THRESHOLD) {
--
2.47.1
next prev parent reply other threads:[~2026-07-28 21:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 21:08 [PATCH net 00/10][pull request] Intel Wired LAN Driver Updates 2026-07-28 (idpf, ice, igc, igbvf, e1000) Tony Nguyen
2026-07-28 21:08 ` [PATCH net 01/10] idpf: bound interrupt-vector register fill to the allocated array Tony Nguyen
2026-07-28 21:08 ` [PATCH net 02/10] idpf: adjust TxQ ring count minimum Tony Nguyen
2026-07-28 21:09 ` [PATCH net 03/10] idpf: Fix mailbox IRQ name leak on request failure Tony Nguyen
2026-07-28 21:09 ` [PATCH net 04/10] ice: wait for reset completion in ice_resume() Tony Nguyen
2026-07-28 21:09 ` [PATCH net 05/10] ice: fix VF interrupts cleanup Tony Nguyen
2026-07-28 21:09 ` [PATCH net 06/10] ice: fix memory leak in ice_lbtest_prepare_rings() Tony Nguyen
2026-07-28 21:09 ` Tony Nguyen [this message]
2026-07-28 21:09 ` [PATCH net 08/10] igc: remove napi_synchronize() in igc_down() Tony Nguyen
2026-07-28 21:09 ` [PATCH net 09/10] igbvf: Fix leak in TX DMA error cleanup Tony Nguyen
2026-07-28 21:09 ` [PATCH net 10/10] e1000: fix memory leak in e1000_probe() Tony Nguyen
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=20260728210909.3042004-8-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=przemyslaw.korba@intel.com \
--cc=sx.rinitha@intel.com \
--cc=vadim.fedorenko@linux.dev \
/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