> -----Original Message----- > From: Keller, Jacob E <[email protected]> > Sent: Friday, August 21, 2026 5:13 PM > To: Intel Wired LAN <[email protected]> > Cc: [email protected]; Machnikowski, Maciej > <[email protected]>; Nguyen, Anthony L > <[email protected]>; Korba, Przemyslaw <[email protected]>; > Nitka, Grzegorz <[email protected]>; Oros, Petr <[email protected]>; > Nowlin, Alexander <[email protected]>; Bross, Kevin > <[email protected]>; Cavatur, Ranjit <[email protected]>; Keller, > Jacob E <[email protected]>; Machnikowski, Maciej > <[email protected]> > Subject: [PATCH iwl-net 10/12] ice: remove unnecessary discarding of > timestamps after clock adjust > > The ice driver currently discards any outstanding timestamps that are > happening very near to a .adjtime or .settime callback. This was originally > add by commit d40fd6009332 ("ice: handle flushing stale Tx timestamps in > ice_ptp_tx_tstamp"). > > The original motivation for discarding timestamps was that extending an old > timestamp using the new cached value of PHC was a problem, as it could > produce incorrect results. The change did not describe what > such "incorrect > results" were. > > There are no such incorrect results. Extending the 32 bit timestamp with the > new time value just means that the timestamp is reported in terms of the > newly updated and adjusted system clock. This won't produce incorrect results > or problematic timestamps to applications. Either the timestamp will be > extended with the value of the PHC just prior to the time adjustment (if the > timestamp completes prior to the adjust callback), or it will be extended > using the new PHC value after the adjustment. In either case, the resulting > extended timestamp value makes sense. > > The timestamp extension logic is very similar to the logic found in > timecounter_cyc2time, the primary difference being that the ice hardware > maintains the full 64 bits of nanoseconds in the MAC rather than being > maintained purely by software as in the timecounter case. > > Indeed, I couldn't find an example of a driver using timecounter_cyc2time > which does discard timestamps that occur nearby a time adjustment. The ice > driver behavior of discarding such timestamps just results > in failure to > deliver a Tx timestamp to userspace, resulting in applications such as ptp4l > to timeout and enter a fault state. Reporting the extended timestamp based on > the updated PHC value isn't producing "garbage" results, and doesn't lead to > incorrect behavior. > > This effectively reverts commit d40fd6009332 ("ice: handle flushing stale Tx > timestamps in ice_ptp_tx_tstamp"). However, the stale logic remains, as we > now use it to inform the driver to drop timestamps which > might fail due to > link down. > > Fixes: d40fd6009332 ("ice: handle flushing stale Tx timestamps in > ice_ptp_tx_tstamp") > Signed-off-by: Jacob Keller <[email protected]> > Reviewed-by: Maciek Machnikowski <[email protected]> > --- > drivers/net/ethernet/intel/ice/ice_ptp.c | 17 ++++------------- > 1 file changed, 4 insertions(+), 13 deletions(-)
Tested-by: Alexander Nowlin <[email protected]>
