Re: [Intel-wired-lan] [PATCH iwl-net] ice: Recalibrate PHY after settime64 on E825-C

[Jacob Keller <jacob.e.keller@intel.com>]

On 8/11/2026 11:11 PM, Paul Menzel wrote:
> Dear Tony, dear Maciek,
> 
> 
> Thank you for your patch.
> 
> Am 12.08.26 um 01:10 schrieb Tony Nguyen:
>> From: Maciek Machnikowski <maciej.machnikowski@intel.com>
>>
>> The PHY on E825-C requires recalibration after large jumps of the
>> system time. Add missing PHY recalibration also on E825-C.
> 
> Why does it need it? Does the datasheet say so? Hardware errata?
> 

If we don't perform this step, then the PHY timer is not synchronzized
properly to the MAC timer. This step is required and indeed was done for
E822 devices previously, but was accidentally skipped due to oversight
when we added E825C support.

> How can the issue be reproduced?
> 

Without the fix:
> ptp4l[12591.505]: port 1 (eno8303np0): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
> ptp4l[12591.951]: port 1 (eno8303np0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> ptp4l[12592.027]: rms 752851973 max 1102277559 freq -84408798 +/- 53560133 delay  6009 +/- 92308
> ptp4l[12593.038]: rms 91302045 max 136894784 freq +100000000 +/-   0 delay 93700 +/- 24153
> ptp4l[12594.050]: rms 16036314 max 35711594 freq +47433070 +/- 46746070 delay 44899 +/- 45255
> ptp4l[12595.061]: rms 5558880 max 12292103 freq -13092285 +/- 6627317 delay -13499 +/- 6560
> ptp4l[12596.073]: rms 759533 max 1081638 freq +837063 +/- 802691 delay   711 +/- 979
> ptp4l[12597.085]: rms 60485 max 106800 freq +146706 +/- 263535 delay   145 +/- 263
> ptp4l[12598.096]: rms 16428 max 41896 freq -46707 +/- 34325 delay   -40 +/-  34
> ptp4l[12599.108]: rms 3049 max 5356 freq  +5337 +/- 1730 delay     7 +/-   2
> ptp4l[12600.120]: rms  284 max  381 freq   +104 +/- 759 delay     2 +/-   1
> ptp4l[12601.131]: rms   42 max  119 freq   -124 +/- 143 delay     2 +/-   0
> ptp4l[12602.144]: rms   11 max   25 freq    +39 +/-  12 delay     3 +/-   0
> ptp4l[12603.156]: rms    2 max    4 freq    +14 +/-   5 delay     3 +/-   0
> ptp4l[12604.167]: rms    1 max    3 freq    +15 +/-   5 delay     2 +/-   0
> ptp4l[12605.179]: rms    1 max    4 freq    +16 +/-   5 delay     2 +/-   1
> ptp4l[12606.191]: rms    1 max    3 freq    +15 +/-   5 delay     3 +/-   0


With the fix:
> ptp4l[12834.266]: rms 27178238388098 max 30079328952737 freq +479164 +/- 1040869 delay     5 +/-   1
> ptp4l[12834.522]: port 1 (eno8703np0): minimum delay request interval 2^-8
> ptp4l[12835.315]: rms 86919 max 139746 freq +111289 +/- 539214 delay   -35 +/-  28
> ptp4l[12836.376]: rms 5415 max 8884 freq   +579 +/- 22798 delay     4 +/-   5
> ptp4l[12837.429]: rms  335 max  559 freq   -305 +/- 842 delay     4 +/-   1
> ptp4l[12838.471]: rms   20 max   45 freq    +79 +/-  33 delay     4 +/-   0
> ptp4l[12839.512]: rms    2 max    5 freq    +44 +/-   8 delay     4 +/-   0
> ptp4l[12840.545]: rms    1 max    4 freq    +46 +/-   8 delay     4 +/-   0
> ptp4l[12841.586]: rms    1 max    3 freq    +46 +/-   7 delay     4 +/-   0
> ptp4l[12842.637]: rms    1 max    3 freq    +46 +/-   7 delay     4 +/-   0

Without the fix, we fail to converge quickly as the effective adjustment
requested is not applied properly to the PHY timestamps, so the readings
from the timestamp are incorrect.

With the fix, we have significantly higher accuracy in the applied
update which reduces the time required to achieve synchronization.

Additionally, I suspect, but do not have a good way to verify that
without the fix there will be a persistent offset between the MAC and
PHY timers resulting in a persistent incorrectness between the Tx/Rx
timestamps and the results of clock_gettime() or PTP_SYS_OFFSET_PRECISE
and the timestamps generated by the PHY.

@Tony, @Maciek, we should include this or similar data in the commit
message.

Thanks,
Jake