From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 5F3EC455608 for ; Thu, 8 Oct 2026 21:57:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791496643; cv=none; b=BFJbqEmmxBwZP6ic1Tet4z7ovKjaMmO3kql5dx6yN2zy74cXuPiSFkB+++v6eurp6nV82n9JPEyAUfro3B5k15nvrrDEmrx0uyJuQW+rwK38pB3UC73+VxhsCLpldpHainWhk/RloXKxGUk1yJz3uCD4VwC1JVnWL5N2A38bz/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791496643; c=relaxed/simple; bh=YXCZuoq4A4q6tUlqgsH2fLksuvdG+WCsIoV+QYBoz1s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bjAA+9UsfUb6EI6dXDYhvK6HKw57gPy+y5FaBTH17rEQnTiIZ7jh3UiAP6r3g63VN/yK9LlSbKiRZjGW7KhJkkBPo7cvfDWj9N+R4X1IR7geXptQuKLrkkIgYEvD6Ll0DECkiLrboEaHzmfgH+tpDu60YLnIo85+96oMLNI45Wk= 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=Y0TjQA8K; arc=none smtp.client-ip=192.198.163.16 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="Y0TjQA8K" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1791496643; x=1823032643; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=YXCZuoq4A4q6tUlqgsH2fLksuvdG+WCsIoV+QYBoz1s=; b=Y0TjQA8KdMInmHwomCCzjn2PjS5n4Nhol18BGnMvTnCMu2SuHqRHLxUV XlMCuf69xhB5NHmHs5Aet/voun4It0ASPgaPEEO3ytUtu5iVZNla4MVg0 K/oxS72+yIWim3S+v2WHPQ76fqi8Ft0AmjMssy/tzg1+Xy01MVeLqpt9G u/ilbdf9GG/ChtfkahY8t14hdTOlSqaoFPbR0WKPCQXv04B+pgAvmH+/o YSPmOCgxETipqv29bVewRs30DtcdLTcrN2LhUfRiE7X9kxmkSlwdU5z7f BcdFsa3504dlRHIs3105dxKLEu3MFQSpF0OJG8QNDdxbNdFXUOtC6DDvb Q==; X-CSE-ConnectionGUID: VC11AoW2Q/iIfrs/MF28Qw== X-CSE-MsgGUID: J7dO6ClQST+mek2AZ9+Bvg== X-IronPort-AV: E=McAfee;i="6800,10657,11929"; a="294651" X-IronPort-AV: E=Sophos;i="6.27,147,1787036400"; d="scan'208";a="294651" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2026 14:57:18 -0700 X-CSE-ConnectionGUID: XYBIAKduQcuC9vGjT7oYYA== X-CSE-MsgGUID: B1nubVIeSjumP7ju9Kv6sQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,147,1787036400"; d="scan'208";a="150414" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa003.jf.intel.com with ESMTP; 08 Oct 2026 14:57:17 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Karol Kolacinski , jacob.e.keller@intel.com, maciej.machnikowski@intel.com, przemyslaw.korba@intel.com, grzegorz.nitka@intel.com, sergey.temerkhanov@intel.com, arkadiusz.kubalewski@intel.com, poros@redhat.com, richardcochran@gmail.com, horms@kernel.org, Aleksandr Loktionov , Alexander Nowlin Subject: [PATCH net v2 06/15] ice: E822: keep Tx timestamps disabled during offset calibration Date: Thu, 8 Oct 2026 14:56:03 -0700 Message-ID: <20261008215614.1987250-7-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20261008215614.1987250-1-anthony.l.nguyen@intel.com> References: <20261008215614.1987250-1-anthony.l.nguyen@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 From: Karol Kolacinski Do not clear the tx.calibrating flag immediately after starting the PHY timer in ice_ptp_port_phy_restart(). Instead, keep Tx timestamps disabled until the offset verification work (ice_ptp_wait_for_offsets) has confirmed that the Tx PHY offset is properly configured. Previously, tx.calibrating was set to true, then immediately back to false right after ice_start_phy_timer_e82x() returned. This allowed Tx timestamp requests to be served during the window where offset verification was still pending. Timestamps produced during this window should have their valid bit cleared, but it is better to prevent requests until the driver has confirmed calibration is complete. Move the tx.calibrating = false to ice_ptp_wait_for_offsets(), after Tx offset configuration has completed successfully. This ensures that new Tx timestamp requests are only accepted after the PHY has properly calibrated the Tx offset. If ice_start_phy_timer_e82x() fails, do not restore calibrating to false. The device is in a state where timestamps cannot succeed properly anyways. A dev_err message is already logged on failure to start the timer at the end of the function. Log a debug message while offset calibration is still pending, including the specific Tx/Rx error codes to aid debugging stalled calibration. This path is expected on every routine link-up: ov_work is first queued with no delay and the vernier offset cannot be computed until at least one packet has been transmitted, so the first several invocations normally land here. Use dev_dbg() rather than a rate-limited warning to avoid emitting KERN_WARNING on every link-up during normal operation. Log a debug message when calibration completes successfully. Note that sashiko review has previously complained that leaving the calibrating flag enabled "permanently" disables Tx timestamps if vernier calibration never completes. This is true, but its important to realize that timestamps would still fail regardless of whether the flag is set. Until vernier calibration completes the device will not report valid timestamps regardless. Thus, keeping the calibrating flag set simply prevents new timestamp requests from software while it is known that the hardware will not complete them. Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support") Signed-off-by: Karol Kolacinski Reviewed-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Signed-off-by: Przemyslaw Korba Signed-off-by: Jacob Keller Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_ptp.c | 29 +++++++++++++++++++----- drivers/net/ethernet/intel/ice/ice_ptp.h | 2 +- 2 files changed, 24 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c index 220d174397ba..7f82439c47ee 100644 --- a/drivers/net/ethernet/intel/ice/ice_ptp.c +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c @@ -1161,6 +1161,7 @@ static int ice_ptp_check_tx_fifo(struct ice_ptp_port *port) static void ice_ptp_wait_for_offsets(struct kthread_work *work) { struct ice_ptp_port *port; + unsigned long flags; struct ice_pf *pf; struct ice_hw *hw; int tx_err; @@ -1181,9 +1182,26 @@ static void ice_ptp_wait_for_offsets(struct kthread_work *work) tx_err = ice_ptp_check_tx_fifo(port); if (!tx_err) tx_err = ice_phy_cfg_tx_offset_e82x(hw, port->port_num); + if (!tx_err) { + /* Tx offset has been configured, re-enable Tx timestamps */ + spin_lock_irqsave(&port->tx.lock, flags); + if (port->tx.calibrating) { + port->tx.calibrating = false; + dev_dbg(ice_pf_to_dev(pf), "PTP Tx offset valid for port %u, Tx timestamps enabled\n", + port->port_num); + } + spin_unlock_irqrestore(&port->tx.lock, flags); + } + rx_err = ice_phy_cfg_rx_offset_e82x(hw, port->port_num); if (tx_err || rx_err) { - /* Tx and/or Rx offset not yet configured, try again later */ + /* Tx and/or Rx offset not yet configured, try again later. + * This is expected during normal link-up: the vernier offset + * calibration cannot complete until at least one packet has + * been transmitted, so the first retries routinely land here. + */ + dev_dbg(ice_pf_to_dev(pf), "PTP offset not yet valid for port %u (tx_err=%d rx_err=%d)\n", + port->port_num, tx_err, rx_err); kthread_queue_delayed_work(pf->ptp.kworker, &port->ov_work, msecs_to_jiffies(100)); @@ -1276,11 +1294,10 @@ ice_ptp_port_phy_restart(struct ice_ptp_port *ptp_port) if (err) break; - /* Enable Tx timestamps right away */ - spin_lock_irqsave(&ptp_port->tx.lock, flags); - ptp_port->tx.calibrating = false; - spin_unlock_irqrestore(&ptp_port->tx.lock, flags); - + /* Do not clear calibrating flag here. Tx timestamp requests + * remain disabled until ice_ptp_wait_for_offsets() has + * verified that the Tx offset calibration has completed. + */ kthread_queue_delayed_work(pf->ptp.kworker, &ptp_port->ov_work, 0); break; diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.h b/drivers/net/ethernet/intel/ice/ice_ptp.h index 27ea502b7576..029ee4612d76 100644 --- a/drivers/net/ethernet/intel/ice/ice_ptp.h +++ b/drivers/net/ethernet/intel/ice/ice_ptp.h @@ -107,7 +107,7 @@ enum ice_tx_tstamp_work { * @len: length of the tstamps and in_use fields. * @init: if true, the tracker is initialized; * @calibrating: if true, the PHY is calibrating the Tx offset. During this - * window, timestamps are temporarily disabled. + * window, timestamp requests are disabled. * @has_ready_bitmap: if true, the hardware has a valid Tx timestamp ready * bitmap register. If false, fall back to verifying new * timestamp values against previously cached copy. -- 2.47.1