Re: [PATCH] e1000e: set fixed clock frequency indication for Alder Point
From: Ruinskiy, Dima
Date: Sun Sep 06 2026 - 06:43:39 EST
On 06/09/2026 11:50, Simon Horman wrote:
On Thu, Sep 03, 2026 at 06:06:33PM +0000, Rawda, Tony wrote:Hi Tony,
On some Alder Point (e1000_pch_adp) platforms the XTAL value reported in
the software STRAP is incorrect, so the SYSCFI bit in TSYNCRXCTL selects
a 24 MHz base frequency while the SYSTIM counter actually advances at
38.4 MHz. As a result the PTP hardware clock runs ~1.6x too fast
(38.4/24), which prevents ptp4l and other PTP-based time sync from
disciplining the clock.
Commit 688a0d61b2d7 ("e1000e: set fixed clock frequency indication for
Nahum 11 and Nahum 13") fixed the same problem for e1000_pch_mtp,
e1000_pch_lnp and e1000_pch_ptp. Alder Point silicon likewise always
runs at 38.4 MHz, so give it the same fixed-frequency override in both
e1000e_get_base_timinca() and e1000e_ptp_init().
Observed on an HP Z2 Mini G9 with I219-LM (17) [8086:1a1c]: before the
change the PHC advanced 16.0 s per 10.0 s of wall-clock time and
/sys/class/ptp/ptpN/max_adjustment read 999999999 (MAX_PPB_24MHZ);
afterwards it advances ~10.0 s and max_adjustment reads 230769100
(MAX_PPB_38400KHZ).
Fixes: 59e466888038 ("e1000e: Add support for Alder Lake")
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Tony Rawda <Tony.Rawda@xxxxxxxxxx>
Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
Thank you for this patch.
Unfortunately, what we found out is that on Alder Lake platforms (and also some Tiger Lake), the clock does not _always_ run at 38.4MHz. Depending on platform, it can be 24 or 38.4, but some systems in the field have the wrong strap value reflected in the SYSCFI bit, so there really is no way to know in advance what the correct clock rate is.
We have been working on a patch that runs a quick check during initialization and adjusts the clock rate automatically if it detects a drift. The patch is here:
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260414065809.3021177-1-dima.ruinskiy@xxxxxxxxx/
(
also here:
https://sashiko.dev/#/message/20260515182419.1597859-11-anthony.l.nguyen%40intel.com
)
Unfortunately, Sashiko pointed out correctly that the patch is not robust enough, because the fix most likely will not survive subsequent adjustments from userspace. Here is the review:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260515182419.1597859-1-anthony.l.nguyen%40intel.com?part=10
Could you check whether the current state of the auto-adjust patch works on your setup? I expect you will see correct clock, at least immediately upon driver load.
If it works for you, we will rework the patch to address the aforementioned shortcomings.
I'm afraid that your current patch will simply fix it on some TGL/ADL systems, while breaking it on others.
--Dima