RE: [PATCH iwl-net 10/12] ice: remove unnecessary discarding of timestamps after clock adjust

> -----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]>