[PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Lorenzo Bianconi]

stmmac_update_subsecond_increment() ignores the error returned by
stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
addend and system time programming errors, always returning success. A
failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
leaving the hardware timestamp counter in a non-running or partially
configured state while the driver keeps operating as if timestamping
were up. This matters for TAPRIO/EST offloading, which derives the gate
base time from the hardware timestamp counter.

The same hooks are also called from the PHC callbacks: settime64 and
adjfine drop the error and report success to clock_settime() and
clock_adjtime(), so a dead PTP reference clock goes unnoticed by
ptp4l/phc2sys.

Return error codes from stmmac_update_subsecond_increment(),
stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
settime64/adjfine callbacks instead of silently returning success. On
failure, roll back the partially applied configuration so the hardware
and the driver bookkeeping stay consistent, and report the reason
through the devlink extack. Also guard against a zero sub-second
increment, which would otherwise divide by zero when computing the
addend.

Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
timestamping, so a failed init does not leave TX/RX timestamping
enabled on a counter that never started.

Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
---
Changes in v3:
- Do not run stmmac_config_addend() in
  stmmac_update_subsecond_increment() error path.
- Return error from stmmac_adjust_freq() and stmmac_set_time().
- Reset hw ts configuration in stmmac_init_timestamping().
- Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com

Changes in v2:
- Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
  routine.
- Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
 2 files changed, 84 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ec62fa7418f4..9741f97fa37a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -601,31 +601,64 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv *priv, struct dma_desc *p,
 	}
 }
 
-static void stmmac_update_subsecond_increment(struct stmmac_priv *priv)
+static void stmmac_restore_subsecond_increment(struct stmmac_priv *priv,
+					       u32 default_addend)
 {
 	bool xmac = dwmac_is_xmac(priv->plat->core_type);
 	u32 sec_inc = 0;
-	u64 temp = 0;
 
+	stmmac_config_addend(priv, priv->ptpaddr, default_addend);
 	stmmac_config_hw_tstamping(priv, priv->ptpaddr, priv->systime_flags);
+	stmmac_config_sub_second_increment(priv, priv->ptpaddr,
+					   priv->plat->clk_ptp_rate,
+					   xmac, &sec_inc);
+	priv->default_addend = default_addend;
+	priv->sub_second_inc = sec_inc;
+}
+
+static int stmmac_update_subsecond_increment(struct stmmac_priv *priv,
+					     u32 systime_flags)
+{
+	bool xmac = dwmac_is_xmac(priv->plat->core_type);
+	u32 sec_inc = 0, val;
+	u64 temp = 0;
+	int ret;
+
+	stmmac_config_hw_tstamping(priv, priv->ptpaddr, systime_flags);
 
 	/* program Sub Second Increment reg */
 	stmmac_config_sub_second_increment(priv, priv->ptpaddr,
 					   priv->plat->clk_ptp_rate,
 					   xmac, &sec_inc);
-	temp = div_u64(1000000000ULL, sec_inc);
-
-	/* Store sub second increment for later use */
-	priv->sub_second_inc = sec_inc;
+	if (!sec_inc) {
+		ret = -EINVAL;
+		goto error;
+	}
 
 	/* calculate default added value:
 	 * formula is :
 	 * addend = (2^32)/freq_div_ratio;
 	 * where, freq_div_ratio = 1e9ns/sec_inc
 	 */
+	temp = div_u64(1000000000ULL, sec_inc);
 	temp = (u64)(temp << 32);
-	priv->default_addend = div_u64(temp, priv->plat->clk_ptp_rate);
-	stmmac_config_addend(priv, priv->ptpaddr, priv->default_addend);
+	val = div_u64(temp, priv->plat->clk_ptp_rate);
+
+	ret = stmmac_config_addend(priv, priv->ptpaddr, val);
+	if (ret)
+		goto error;
+
+	priv->sub_second_inc = sec_inc;
+	priv->default_addend = val;
+
+	return 0;
+error:
+	/* Restore previous configuration */
+	stmmac_config_hw_tstamping(priv, priv->ptpaddr, priv->systime_flags);
+	stmmac_config_sub_second_increment(priv, priv->ptpaddr,
+					   priv->plat->clk_ptp_rate, xmac,
+					   NULL);
+	return ret;
 }
 
 /**
@@ -854,35 +887,42 @@ static int stmmac_hwtstamp_get(struct net_device *dev,
 /**
  * stmmac_init_tstamp_counter - init hardware timestamping counter
  * @priv: driver private structure
- * @systime_flags: timestamping flags
  * Description:
  * Initialize hardware counter for packet timestamping.
  * This is valid as long as the interface is open and not suspended.
  * Will be rerun after resuming from suspend, case in which the timestamping
  * flags updated by stmmac_hwtstamp_set() also need to be restored.
  */
-static int stmmac_init_tstamp_counter(struct stmmac_priv *priv,
-				      u32 systime_flags)
+static int stmmac_init_tstamp_counter(struct stmmac_priv *priv)
 {
+	u32 default_addend = priv->default_addend;
 	struct timespec64 now;
+	int ret;
 
 	if (!priv->plat->clk_ptp_rate) {
 		netdev_err(priv->dev, "Invalid PTP clock rate");
 		return -EINVAL;
 	}
 
-	stmmac_config_hw_tstamping(priv, priv->ptpaddr, systime_flags);
-	priv->systime_flags = systime_flags;
-
-	stmmac_update_subsecond_increment(priv);
+	ret = stmmac_update_subsecond_increment(priv, priv->systime_flags);
+	if (ret)
+		return ret;
 
 	/* initialize system time */
 	ktime_get_real_ts64(&now);
 
 	/* lower 32 bits of tv_sec are safe until y2106 */
-	stmmac_init_systime(priv, priv->ptpaddr, (u32)now.tv_sec, now.tv_nsec);
+	ret = stmmac_init_systime(priv, priv->ptpaddr, (u32)now.tv_sec,
+				  now.tv_nsec);
+	if (ret)
+		goto error;
 
 	return 0;
+error:
+	/* Restore previous configuration */
+	stmmac_restore_subsecond_increment(priv, default_addend);
+
+	return ret;
 }
 
 /**
@@ -905,8 +945,14 @@ static int stmmac_init_timestamping(struct stmmac_priv *priv)
 		return -EOPNOTSUPP;
 	}
 
-	ret = stmmac_init_tstamp_counter(priv, STMMAC_HWTS_ACTIVE |
-					       PTP_TCR_TSCFUPDT);
+	/* Reset hw ts configuration */
+	memset(&priv->tstamp_config, 0, sizeof(priv->tstamp_config));
+	priv->systime_flags = STMMAC_HWTS_ACTIVE | PTP_TCR_TSCFUPDT;
+	priv->tsfupdt_coarse = false;
+	priv->hwts_tx_en = 0;
+	priv->hwts_rx_en = 0;
+
+	ret = stmmac_init_tstamp_counter(priv);
 	if (ret) {
 		netdev_warn(priv->dev, "PTP init failed\n");
 		return ret;
@@ -927,10 +973,6 @@ static int stmmac_init_timestamping(struct stmmac_priv *priv)
 		netdev_info(priv->dev,
 			    "IEEE 1588-2008 Advanced Timestamp supported\n");
 
-	memset(&priv->tstamp_config, 0, sizeof(priv->tstamp_config));
-	priv->hwts_tx_en = 0;
-	priv->hwts_rx_en = 0;
-
 	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
 		stmmac_hwtstamp_correct_latency(priv, priv);
 
@@ -7711,18 +7753,26 @@ static int stmmac_dl_ts_coarse_set(struct devlink *dl, u32 id,
 {
 	struct stmmac_devlink_priv *dl_priv = devlink_priv(dl);
 	struct stmmac_priv *priv = dl_priv->stmmac_priv;
+	u32 systime_flags = priv->systime_flags;
+	int ret;
 
-	priv->tsfupdt_coarse = ctx->val.vbool;
-
-	if (priv->tsfupdt_coarse)
-		priv->systime_flags &= ~PTP_TCR_TSCFUPDT;
+	if (ctx->val.vbool)
+		systime_flags &= ~PTP_TCR_TSCFUPDT;
 	else
-		priv->systime_flags |= PTP_TCR_TSCFUPDT;
+		systime_flags |= PTP_TCR_TSCFUPDT;
 
 	/* In Coarse mode, we can use a smaller subsecond increment, let's
 	 * reconfigure the systime, subsecond increment and addend.
 	 */
-	stmmac_update_subsecond_increment(priv);
+	ret = stmmac_update_subsecond_increment(priv, systime_flags);
+	if (ret) {
+		NL_SET_ERR_MSG_MOD(extack,
+				   "failed to reconfigure PTP adjustment");
+		return ret;
+	}
+
+	priv->tsfupdt_coarse = ctx->val.vbool;
+	priv->systime_flags = systime_flags;
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index 3bfcc9760dce..493c5d81a36b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -28,14 +28,15 @@ static int stmmac_adjust_freq(struct ptp_clock_info *ptp, long scaled_ppm)
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
 	unsigned long flags;
 	u32 addend;
+	int ret;
 
 	addend = adjust_by_scaled_ppm(priv->default_addend, scaled_ppm);
 
 	write_lock_irqsave(&priv->ptp_lock, flags);
-	stmmac_config_addend(priv, priv->ptpaddr, addend);
+	ret = stmmac_config_addend(priv, priv->ptpaddr, addend);
 	write_unlock_irqrestore(&priv->ptp_lock, flags);
 
-	return 0;
+	return ret;
 }
 
 /**
@@ -153,12 +154,13 @@ static int stmmac_set_time(struct ptp_clock_info *ptp,
 	struct stmmac_priv *priv =
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
 	unsigned long flags;
+	int ret;
 
 	write_lock_irqsave(&priv->ptp_lock, flags);
-	stmmac_init_systime(priv, priv->ptpaddr, ts->tv_sec, ts->tv_nsec);
+	ret = stmmac_init_systime(priv, priv->ptpaddr, ts->tv_sec, ts->tv_nsec);
 	write_unlock_irqrestore(&priv->ptp_lock, flags);
 
-	return 0;
+	return ret;
 }
 
 static int stmmac_enable(struct ptp_clock_info *ptp,

---
base-commit: 37e02c42a00be692c06343e11779aadc45f45971
change-id: 20260920-stmmac-ptp-added-systime-error-bc9566262f2f

Best regards,
-- 
Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Maxime Chevallier]

Hi Lorenzo,

On 9/29/26 15:10, Lorenzo Bianconi wrote:
> stmmac_update_subsecond_increment() ignores the error returned by
> stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> addend and system time programming errors, always returning success. A
> failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> leaving the hardware timestamp counter in a non-running or partially
> configured state while the driver keeps operating as if timestamping
> were up. This matters for TAPRIO/EST offloading, which derives the gate
> base time from the hardware timestamp counter.
> 
> The same hooks are also called from the PHC callbacks: settime64 and
> adjfine drop the error and report success to clock_settime() and
> clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> ptp4l/phc2sys.
> 
> Return error codes from stmmac_update_subsecond_increment(),
> stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> settime64/adjfine callbacks instead of silently returning success. On
> failure, roll back the partially applied configuration so the hardware
> and the driver bookkeeping stay consistent, and report the reason
> through the devlink extack. Also guard against a zero sub-second
> increment, which would otherwise divide by zero when computing the
> addend.
> 
> Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> timestamping, so a failed init does not leave TX/RX timestamping
> enabled on a counter that never started.
> 
> Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>

Thanks, this is nice.

Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Maxime

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.

I discovered the issue during manual code inspection

> 
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

This issue is theoretical, I have never triggered it on a running device.

> 
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.

I tested the modified codebase on a qualcomm rb3-gen2 board.

Regards,
Lorenzo

> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 6 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 6 · Low: 0 (1)

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] Every ifup and every resume now silently resets the documented
  runtime devlink parameter `phc_coarse_adj`.
- [Medium] The commit message says that on failure the patch will 'roll
  back the partially applied configuration so the hardware and the…
- [Medium] After a failed timestamp-counter init, later timestamping and
  TAPRIO operations can still use the failed counter.
- [Medium] The hardware rollback in stmmac_update_subsecond_increment()
  is incomplete when stmmac_config_addend() times out (line 647).
- [Medium] The patch opens a lost-update race between
  stmmac_dl_ts_coarse_set() and the rtnl-protected timestamping paths.
- [Medium] When stmmac_init_systime() fails, stmmac_init_tstamp_counter()
  calls stmmac_restore_subsecond_increment(priv, default_addend) (line…

Pre-existing issues:
- [Low] The kernel-doc for stmmac_init_timestamping() says 'This function
  also registers the ptp driver.', but the function only configures the…

--

net: stmmac: propagate PTP addend and system time programming errors

This patch makes stmmac_update_subsecond_increment(),
stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
settime64/adjfine PHC callbacks return the errors from the addend and
system time programming hooks instead of always reporting success. On
failure it rolls back the partially applied configuration, and it adds a
guard against a zero sub-second increment. It also resets the persistent
timestamping state whenever timestamping is (re)initialized.

> settime64/adjfine callbacks instead of silently returning success. On
> failure, roll back the partially applied configuration so the hardware
> and the driver bookkeeping stay consistent, and report the reason
> through the devlink extack.

[Severity: Medium]
Does this hold for both failure paths?

In stmmac_update_subsecond_increment(), stmmac_config_addend() can time out.
At that point PTP_TAR already holds the new addend and TSADDREG is still
pending. The error label only restores the PTP_TCR flags and the sub-second
increment. The hardware can then end up with a new-mode addend and an
old-mode SSINC, while priv->default_addend keeps the old value.

In stmmac_init_tstamp_counter(), the rollback through
stmmac_restore_subsecond_increment() uses priv->systime_flags. By then,
stmmac_init_timestamping() has already overwritten that field with the new
fine-mode defaults. So the SSINC is recomputed for the new flags, but the
old default_addend is restored. That addend can be 0 on first open or a
coarse-mode value, and any addend applied by adjfine is lost.

Both cases are covered in more detail inline below. Could the commit message
and the "Restore previous configuration" comments be changed to match what
the error paths actually leave behind?

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index ec62fa7418f41..9741f97fa37a2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -601,31 +601,64 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv *priv, struct dma_desc *p,

[ ... ]

> +	ret = stmmac_config_addend(priv, priv->ptpaddr, val);
> +	if (ret)
> +		goto error;
> +
> +	priv->sub_second_inc = sec_inc;
> +	priv->default_addend = val;
> +
> +	return 0;
> +error:
> +	/* Restore previous configuration */
> +	stmmac_config_hw_tstamping(priv, priv->ptpaddr, priv->systime_flags);
> +	stmmac_config_sub_second_increment(priv, priv->ptpaddr,
> +					   priv->plat->clk_ptp_rate, xmac,
> +					   NULL);
> +	return ret;
>  }

[Severity: Medium]
If stmmac_config_addend() times out, does the new addend stay latched?

config_addend() writes PTP_TAR and sets TSADDREG before it polls:

drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:config_addend() {
    ...
	writel(addend, ioaddr + PTP_TAR);
	/* issue command to update the addend value */
	value = readl(ioaddr + PTP_TCR);
	value |= PTP_TCR_TSADDREG;
	writel(value, ioaddr + PTP_TCR);
    ...
}

So on -ETIMEDOUT, the TAR write and the latch request are both still
pending.

config_hw_tstamping() does a read-modify-write that clears only the
STMMAC_HWTS_CFG_MASK bits. TSADDREG is not in that mask, so TSADDREG=1 is
written back. PTP_TAR is never restored.

Here is an example. Switch devlink phc_coarse_adj from fine to coarse on a
125 MHz PTP clock, and val computes to 0. If TSADDREG then times out, the
rollback puts the MAC back in fine mode (TSCFUPDT=1) with the old SSINC.
priv->default_addend still holds the old fine value.

If the pending latch completes later, the fine-mode accumulator runs with
addend 0. The counter would stop advancing until the next adjfine.

The v3 changelog says "Do not run stmmac_config_addend() in
stmmac_update_subsecond_increment() error path", which leaves this case
open. Is that intended?

> @@ -854,35 +887,42 @@ static int stmmac_hwtstamp_get(struct net_device *dev,

[ ... ]

> -static int stmmac_init_tstamp_counter(struct stmmac_priv *priv,
> -				      u32 systime_flags)
> +static int stmmac_init_tstamp_counter(struct stmmac_priv *priv)
>  {
> +	u32 default_addend = priv->default_addend;
>  	struct timespec64 now;
> +	int ret;

[ ... ]

> +	ret = stmmac_init_systime(priv, priv->ptpaddr, (u32)now.tv_sec,
> +				  now.tv_nsec);
> +	if (ret)
> +		goto error;
>  
>  	return 0;
> +error:
> +	/* Restore previous configuration */
> +	stmmac_restore_subsecond_increment(priv, default_addend);
> +
> +	return ret;
>  }

[Severity: Medium]
What does this restore when stmmac_init_systime() fails?

Before calling in here, stmmac_init_timestamping() has already set
priv->systime_flags to STMMAC_HWTS_ACTIVE | PTP_TCR_TSCFUPDT. So
stmmac_restore_subsecond_increment() writes the same fine-mode TCR and SSIR
values that were just programmed. The only real rollback is PTP_TAR, which
is set to the saved default_addend.

On first open that saved value is 0, because netdev priv is zeroed. In fine
mode an addend of 0 means the accumulator never overflows, so the counter is
frozen. On resume after coarse mode was active, the saved value is the
coarse addend. At 125 MHz that is 0, while fine mode needs 0x80000000.

stmmac_restore_subsecond_increment() also stores this value:

	priv->default_addend = default_addend;

Later stmmac_adjust_freq() calls then scale from a base of 0. The PHC stays
registered on resume, so can it recover without a full re-init?

There is also an ordering question in stmmac_restore_subsecond_increment():

	stmmac_config_addend(priv, priv->ptpaddr, default_addend);
	stmmac_config_hw_tstamping(priv, priv->ptpaddr, priv->systime_flags);

After a TSINIT timeout, TSINIT is still set in PTP_TCR. config_addend() does
its own read-modify-write of PTP_TCR, which keeps TSINIT=1 and adds
TSADDREG. It then busy-waits up to another 100 ms on a clock domain that is
probably not responding. Is that extra wait in the failure path expected?

> @@ -905,8 +945,14 @@ static int stmmac_init_timestamping(struct stmmac_priv *priv)

[Severity: Low]
This is a pre-existing issue, not one introduced by this patch. The
kernel-doc above stmmac_init_timestamping() still says:

 * This function also registers the ptp driver.

The function does not register anything. The caller, stmmac_setup_ptp(),
does:

	if (stmmac_init_timestamping(priv) == 0)
		stmmac_ptp_register(priv);

Could that line in the comment be dropped?

>  		return -EOPNOTSUPP;
>  	}
>  
> -	ret = stmmac_init_tstamp_counter(priv, STMMAC_HWTS_ACTIVE |
> -					       PTP_TCR_TSCFUPDT);
> +	/* Reset hw ts configuration */
> +	memset(&priv->tstamp_config, 0, sizeof(priv->tstamp_config));
> +	priv->systime_flags = STMMAC_HWTS_ACTIVE | PTP_TCR_TSCFUPDT;
> +	priv->tsfupdt_coarse = false;

[Severity: Medium]
Does this throw away the devlink phc_coarse_adj setting on every open and
resume?

stmmac_init_timestamping() runs from stmmac_setup_ptp() on open and from
stmmac_resume(). The phc_coarse_adj parameter is registered with only
DEVLINK_PARAM_CMODE_RUNTIME, and the devlink core does not cache runtime
values. stmmac_dl_ts_coarse_get() just reports the field:

	ctx->val.vbool = priv->tsfupdt_coarse;

So after "ip link set dev X down/up", an MTU change that reopens the device,
or a suspend/resume, the PHC goes back to fine mode and devlink reports
false.

The other place that builds systime_flags, stmmac_hwtstamp_set(), still
honours the setting:

	priv->systime_flags = STMMAC_HWTS_ACTIVE;
	if (!priv->tsfupdt_coarse)
		priv->systime_flags |= PTP_TCR_TSCFUPDT;

The commit message explains the reset "so a failed init does not leave TX/RX
timestamping enabled on a counter that never started". tsfupdt_coarse is a
clock mode chosen by the user, not a timestamp-enable flag.

Before this patch the bool was kept, even though the hardware was forced to
fine mode, which was a separate inconsistency. Would it work to keep
tsfupdt_coarse and derive the flags from it, for example:

	priv->systime_flags = STMMAC_HWTS_ACTIVE |
			      (priv->tsfupdt_coarse ? 0 : PTP_TCR_TSCFUPDT);

Documentation/networking/devlink/stmmac.rst recommends coarse mode for Grand
Master operation. With this reset, that setup falls back to fine mode after
any suspend/resume or link down/up.

> +	priv->hwts_tx_en = 0;
> +	priv->hwts_rx_en = 0;
> +
> +	ret = stmmac_init_tstamp_counter(priv);
>  	if (ret) {
>  		netdev_warn(priv->dev, "PTP init failed\n");
>  		return ret;

[Severity: Medium]
The error is now returned from here, but do the callers do anything with it?

On open, stmmac_setup_ptp() only skips stmmac_ptp_register(), and
__stmmac_open() still succeeds. On resume the return value is ignored:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:stmmac_resume() {
    ...
	stmmac_init_timestamping(priv);
    ...
}

The PHC stays registered, stmmac_get_time() keeps returning success with the
stopped counter's value, and the device is reattached.

hwts_tx_en/hwts_rx_en are cleared before init, and nothing records that init
failed. A later stmmac_hwtstamp_set() checks only:

	if (!(priv->dma_cap.time_stamp || priv->adv_ts)) {

and netif_running(). It then sets hwts_rx_en/hwts_tx_en, programs PTP_TCR
and returns success without retrying init. If resume fails, adv_ts keeps its
earlier value.

tc_taprio_configure() in stmmac_tc.c also still takes the EST base time from
the counter without checking whether init succeeded:

	priv->ptp_clock_ops.gettime64(&priv->ptp_clock_ops, &current_time);

The commit message gives TAPRIO/EST as the motivation, and describes the old
behaviour as the driver "operating as if timestamping were up". Isn't the
resume path still doing that?

[ ... ]

> @@ -7711,18 +7753,26 @@ static int stmmac_dl_ts_coarse_set(struct devlink *dl, u32 id,
>  {
>  	struct stmmac_devlink_priv *dl_priv = devlink_priv(dl);
>  	struct stmmac_priv *priv = dl_priv->stmmac_priv;
> +	u32 systime_flags = priv->systime_flags;
> +	int ret;

[ ... ]

> -	stmmac_update_subsecond_increment(priv);
> +	ret = stmmac_update_subsecond_increment(priv, systime_flags);
> +	if (ret) {
> +		NL_SET_ERR_MSG_MOD(extack,
> +				   "failed to reconfigure PTP adjustment");
> +		return ret;
> +	}
> +
> +	priv->tsfupdt_coarse = ctx->val.vbool;
> +	priv->systime_flags = systime_flags;

[Severity: Medium]
Can this snapshot-then-commit ordering lose an update made at the same time
by stmmac_hwtstamp_set()?

The devlink param set runs under devl_lock only, without rtnl.
stmmac_hwtstamp_set() (rtnl) and stmmac_init_timestamping() (rtnl, plus
priv->lock on resume) write the same fields and PTP_TCR, and neither takes
devl_lock.

This function now takes a snapshot of the flags and then programs PTP_TCR,
SSIR and TAR. That includes a TSADDREG poll of up to 100 ms. Only after that
are tsfupdt_coarse and systime_flags published. When enabling coarse mode,
this sequence looks possible:

devlink                                SIOCSHWTSTAMP
stmmac_dl_ts_coarse_set()
  systime_flags = priv->systime_flags
  stmmac_update_subsecond_increment()
    TCR coarse, coarse SSINC/addend
                                       stmmac_hwtstamp_set()
                                         sees tsfupdt_coarse == false
                                         priv->systime_flags =
                                           ACTIVE | TSCFUPDT | filters
                                         hwts_rx_en = 1
                                         TCR fine
  priv->tsfupdt_coarse = true
  priv->systime_flags = systime_flags
    (filter bits from hwtstamp_set lost)

The result is PTP_TCR in fine mode with the coarse SSINC and addend. At
125 MHz that addend is 0, so the PHC is frozen. default_addend is also 0, so
adjfine cannot recover it.

priv->systime_flags would also no longer match hwts_rx_en, tstamp_config,
or what stmmac_enable() passes to flex_pps_config for PEROUT.

Before this patch, tsfupdt_coarse was stored first, and priv->systime_flags
was read right before the hardware write. That order did not give this
mismatch. Is something serializing these paths that I'm missing?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929-stmmac-ptp-added-systime-error-v3-1-ddd6afe936b4%40oss.qualcomm.com

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:

On Tue, 29 Sep 2026 15:10:11 +0200 you wrote:
> stmmac_update_subsecond_increment() ignores the error returned by
> stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> addend and system time programming errors, always returning success. A
> failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> leaving the hardware timestamp counter in a non-running or partially
> configured state while the driver keeps operating as if timestamping
> were up. This matters for TAPRIO/EST offloading, which derives the gate
> base time from the hardware timestamp counter.
> 
> [...]

Here is the summary with links:
  - [net,v3] net: stmmac: propagate PTP addend and system time programming errors
    https://git.kernel.org/netdev/net/c/232d49dd4b40

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Anirudh Srinivasan]

On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> stmmac_update_subsecond_increment() ignores the error returned by
> stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> addend and system time programming errors, always returning success. A
> failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> leaving the hardware timestamp counter in a non-running or partially
> configured state while the driver keeps operating as if timestamping
> were up. This matters for TAPRIO/EST offloading, which derives the gate
> base time from the hardware timestamp counter.
> 
> The same hooks are also called from the PHC callbacks: settime64 and
> adjfine drop the error and report success to clock_settime() and
> clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> ptp4l/phc2sys.
> 
> Return error codes from stmmac_update_subsecond_increment(),
> stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> settime64/adjfine callbacks instead of silently returning success. On
> failure, roll back the partially applied configuration so the hardware
> and the driver bookkeeping stay consistent, and report the reason
> through the devlink extack. Also guard against a zero sub-second
> increment, which would otherwise divide by zero when computing the
> addend.
> 
> Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> timestamping, so a failed init does not leave TX/RX timestamping
> enabled on a counter that never started.
> 
> Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> ---
> Changes in v3:
> - Do not run stmmac_config_addend() in
>   stmmac_update_subsecond_increment() error path.
> - Return error from stmmac_adjust_freq() and stmmac_set_time().
> - Reset hw ts configuration in stmmac_init_timestamping().
> - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> 
> Changes in v2:
> - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
>   routine.
> - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
>  2 files changed, 84 insertions(+), 32 deletions(-)

Hello, I'm noticing that after this patch was merged into linux-next,
boot seems to hang when ip=dhcp is used because ethernet isn't working
on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
over

IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
f2 mtu 1500 DHCP
[   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
[   24.912780] dwmac1000: Master AXI performs any burst length
[   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
[   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
SIOCSIFFLAGS: Connection timed out

I suspect that this has something to do with the error codes being
discarded in your patch/some particular quirk of this hardware where it
doesn't support these PTP related bits.

I've CC'ed the linux-riscv list, in case anyone here is more familiar
with this particular board and knows why this is happening.

Regards
Anirudh Srinivasan

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 4289 bytes --]

> On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > stmmac_update_subsecond_increment() ignores the error returned by
> > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > addend and system time programming errors, always returning success. A
> > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > leaving the hardware timestamp counter in a non-running or partially
> > configured state while the driver keeps operating as if timestamping
> > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > base time from the hardware timestamp counter.
> > 
> > The same hooks are also called from the PHC callbacks: settime64 and
> > adjfine drop the error and report success to clock_settime() and
> > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > ptp4l/phc2sys.
> > 
> > Return error codes from stmmac_update_subsecond_increment(),
> > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > settime64/adjfine callbacks instead of silently returning success. On
> > failure, roll back the partially applied configuration so the hardware
> > and the driver bookkeeping stay consistent, and report the reason
> > through the devlink extack. Also guard against a zero sub-second
> > increment, which would otherwise divide by zero when computing the
> > addend.
> > 
> > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > timestamping, so a failed init does not leave TX/RX timestamping
> > enabled on a counter that never started.
> > 
> > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > ---
> > Changes in v3:
> > - Do not run stmmac_config_addend() in
> >   stmmac_update_subsecond_increment() error path.
> > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > - Reset hw ts configuration in stmmac_init_timestamping().
> > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > 
> > Changes in v2:
> > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> >   routine.
> > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> >  2 files changed, 84 insertions(+), 32 deletions(-)
> 
> Hello, I'm noticing that after this patch was merged into linux-next,
> boot seems to hang when ip=dhcp is used because ethernet isn't working
> on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> over
> 
> IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> f2 mtu 1500 DHCP
> [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> [   24.912780] dwmac1000: Master AXI performs any burst length
> [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> SIOCSIFFLAGS: Connection timed out

Hi Anirudh,

based on the reported error, stmmac_init_tstamp_counter() fails with
-ETIMEDOUT. In particular this can occurs if:

stmmac_init_tstamp_counter()
 -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
 -> stmmac_init_systime() -> -ETIMEDOUT

I guess we should understand which one is failing and why it is failing.

Regards,
Lorenzo

> 
> I suspect that this has something to do with the error codes being
> discarded in your patch/some particular quirk of this hardware where it
> doesn't support these PTP related bits.
> 
> I've CC'ed the linux-riscv list, in case anyone here is more familiar
> with this particular board and knows why this is happening.
> 
> Regards
> Anirudh Srinivasan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Anirudh Srinivasan]

Hi Lorenzo,

On Mon, Oct 5, 2026 at 4:53 PM Lorenzo Bianconi
<lorenzo.bianconi@oss.qualcomm.com> wrote:
>
> > On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > > stmmac_update_subsecond_increment() ignores the error returned by
> > > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > > addend and system time programming errors, always returning success. A
> > > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > > leaving the hardware timestamp counter in a non-running or partially
> > > configured state while the driver keeps operating as if timestamping
> > > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > > base time from the hardware timestamp counter.
> > >
> > > The same hooks are also called from the PHC callbacks: settime64 and
> > > adjfine drop the error and report success to clock_settime() and
> > > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > > ptp4l/phc2sys.
> > >
> > > Return error codes from stmmac_update_subsecond_increment(),
> > > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > > settime64/adjfine callbacks instead of silently returning success. On
> > > failure, roll back the partially applied configuration so the hardware
> > > and the driver bookkeeping stay consistent, and report the reason
> > > through the devlink extack. Also guard against a zero sub-second
> > > increment, which would otherwise divide by zero when computing the
> > > addend.
> > >
> > > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > > timestamping, so a failed init does not leave TX/RX timestamping
> > > enabled on a counter that never started.
> > >
> > > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > ---
> > > Changes in v3:
> > > - Do not run stmmac_config_addend() in
> > >   stmmac_update_subsecond_increment() error path.
> > > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > > - Reset hw ts configuration in stmmac_init_timestamping().
> > > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > >
> > > Changes in v2:
> > > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> > >   routine.
> > > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > > ---
> > >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> > >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> > >  2 files changed, 84 insertions(+), 32 deletions(-)
> >
> > Hello, I'm noticing that after this patch was merged into linux-next,
> > boot seems to hang when ip=dhcp is used because ethernet isn't working
> > on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> > over
> >
> > IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > f2 mtu 1500 DHCP
> > [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> > [   24.912780] dwmac1000: Master AXI performs any burst length
> > [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> > [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> > SIOCSIFFLAGS: Connection timed out
>
> Hi Anirudh,
>
> based on the reported error, stmmac_init_tstamp_counter() fails with
> -ETIMEDOUT. In particular this can occurs if:
>
> stmmac_init_tstamp_counter()
>  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
>  -> stmmac_init_systime() -> -ETIMEDOUT
>
> I guess we should understand which one is failing and why it is failing.

It seems like both are timing out, both config_addend
(PTP_TCR_TSADDREG) and init_systime (PTP_TCR_TSINIT).

Regards
Anirudh Srinivasan

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Jakub Kicinski]

On Mon, 5 Oct 2026 23:53:04 +0200 Lorenzo Bianconi wrote:
> based on the reported error, stmmac_init_tstamp_counter() fails with
> -ETIMEDOUT. In particular this can occurs if:
> 
> stmmac_init_tstamp_counter()
>  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
>  -> stmmac_init_systime() -> -ETIMEDOUT  
> 
> I guess we should understand which one is failing and why it is failing.

I'm going to revert, this shouldn't have been applied to net in 
the first place. Let's continue the investigation but v4 should
be tagged with net-next.

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 4917 bytes --]

> Hi Lorenzo,
> 
> On Mon, Oct 5, 2026 at 4:53 PM Lorenzo Bianconi
> <lorenzo.bianconi@oss.qualcomm.com> wrote:
> >
> > > On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > > > stmmac_update_subsecond_increment() ignores the error returned by
> > > > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > > > addend and system time programming errors, always returning success. A
> > > > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > > > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > > > leaving the hardware timestamp counter in a non-running or partially
> > > > configured state while the driver keeps operating as if timestamping
> > > > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > > > base time from the hardware timestamp counter.
> > > >
> > > > The same hooks are also called from the PHC callbacks: settime64 and
> > > > adjfine drop the error and report success to clock_settime() and
> > > > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > > > ptp4l/phc2sys.
> > > >
> > > > Return error codes from stmmac_update_subsecond_increment(),
> > > > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > > > settime64/adjfine callbacks instead of silently returning success. On
> > > > failure, roll back the partially applied configuration so the hardware
> > > > and the driver bookkeeping stay consistent, and report the reason
> > > > through the devlink extack. Also guard against a zero sub-second
> > > > increment, which would otherwise divide by zero when computing the
> > > > addend.
> > > >
> > > > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > > > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > > > timestamping, so a failed init does not leave TX/RX timestamping
> > > > enabled on a counter that never started.
> > > >
> > > > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > > ---
> > > > Changes in v3:
> > > > - Do not run stmmac_config_addend() in
> > > >   stmmac_update_subsecond_increment() error path.
> > > > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > > > - Reset hw ts configuration in stmmac_init_timestamping().
> > > > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > > >
> > > > Changes in v2:
> > > > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> > > >   routine.
> > > > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > > > ---
> > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> > > >  2 files changed, 84 insertions(+), 32 deletions(-)
> > >
> > > Hello, I'm noticing that after this patch was merged into linux-next,
> > > boot seems to hang when ip=dhcp is used because ethernet isn't working
> > > on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> > > over
> > >
> > > IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > f2 mtu 1500 DHCP
> > > [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> > > [   24.912780] dwmac1000: Master AXI performs any burst length
> > > [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> > > [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> > > SIOCSIFFLAGS: Connection timed out
> >
> > Hi Anirudh,
> >
> > based on the reported error, stmmac_init_tstamp_counter() fails with
> > -ETIMEDOUT. In particular this can occurs if:
> >
> > stmmac_init_tstamp_counter()
> >  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
> >  -> stmmac_init_systime() -> -ETIMEDOUT
> >
> > I guess we should understand which one is failing and why it is failing.
> 
> It seems like both are timing out, both config_addend
> (PTP_TCR_TSADDREG) and init_systime (PTP_TCR_TSINIT).

It seems hw timestamping has never worked on this board, it was just
undiscovered since stmmac_init_tstamp_counter() was not reporting any
error before (this is exactly the goal of this patch).

What are the output for:
- IEEE 1588-2002 Time Stamp
- IEEE 1588-2008 Advanced Time Stamp

root@rb3-gen2:~# grep 'Time Stamp' /sys/kernel/debug/stmmaceth/eth0/dma_cap
IEEE 1588-2002 Time Stamp: N
IEEE 1588-2008 Advanced Time Stamp: Y

Regards,
Lorenzo

> 
> Regards
> Anirudh Srinivasan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Anirudh Srinivasan]

Hi Lorenzo,

On Tue, Oct 6, 2026 at 1:57 AM Lorenzo Bianconi
<lorenzo.bianconi@oss.qualcomm.com> wrote:
>
> > Hi Lorenzo,
> >
> > On Mon, Oct 5, 2026 at 4:53 PM Lorenzo Bianconi
> > <lorenzo.bianconi@oss.qualcomm.com> wrote:
> > >
> > > > On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > > > > stmmac_update_subsecond_increment() ignores the error returned by
> > > > > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > > > > addend and system time programming errors, always returning success. A
> > > > > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > > > > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > > > > leaving the hardware timestamp counter in a non-running or partially
> > > > > configured state while the driver keeps operating as if timestamping
> > > > > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > > > > base time from the hardware timestamp counter.
> > > > >
> > > > > The same hooks are also called from the PHC callbacks: settime64 and
> > > > > adjfine drop the error and report success to clock_settime() and
> > > > > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > > > > ptp4l/phc2sys.
> > > > >
> > > > > Return error codes from stmmac_update_subsecond_increment(),
> > > > > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > > > > settime64/adjfine callbacks instead of silently returning success. On
> > > > > failure, roll back the partially applied configuration so the hardware
> > > > > and the driver bookkeeping stay consistent, and report the reason
> > > > > through the devlink extack. Also guard against a zero sub-second
> > > > > increment, which would otherwise divide by zero when computing the
> > > > > addend.
> > > > >
> > > > > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > > > > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > > > > timestamping, so a failed init does not leave TX/RX timestamping
> > > > > enabled on a counter that never started.
> > > > >
> > > > > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > > > ---
> > > > > Changes in v3:
> > > > > - Do not run stmmac_config_addend() in
> > > > >   stmmac_update_subsecond_increment() error path.
> > > > > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > > > > - Reset hw ts configuration in stmmac_init_timestamping().
> > > > > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > > > >
> > > > > Changes in v2:
> > > > > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> > > > >   routine.
> > > > > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > > > > ---
> > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> > > > >  2 files changed, 84 insertions(+), 32 deletions(-)
> > > >
> > > > Hello, I'm noticing that after this patch was merged into linux-next,
> > > > boot seems to hang when ip=dhcp is used because ethernet isn't working
> > > > on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> > > > over
> > > >
> > > > IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > f2 mtu 1500 DHCP
> > > > [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> > > > [   24.912780] dwmac1000: Master AXI performs any burst length
> > > > [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> > > > [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> > > > SIOCSIFFLAGS: Connection timed out
> > >
> > > Hi Anirudh,
> > >
> > > based on the reported error, stmmac_init_tstamp_counter() fails with
> > > -ETIMEDOUT. In particular this can occurs if:
> > >
> > > stmmac_init_tstamp_counter()
> > >  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
> > >  -> stmmac_init_systime() -> -ETIMEDOUT
> > >
> > > I guess we should understand which one is failing and why it is failing.
> >
> > It seems like both are timing out, both config_addend
> > (PTP_TCR_TSADDREG) and init_systime (PTP_TCR_TSINIT).
>
> It seems hw timestamping has never worked on this board, it was just
> undiscovered since stmmac_init_tstamp_counter() was not reporting any
> error before (this is exactly the goal of this patch).
>
> What are the output for:
> - IEEE 1588-2002 Time Stamp
> - IEEE 1588-2008 Advanced Time Stamp
>
> root@rb3-gen2:~# grep 'Time Stamp' /sys/kernel/debug/stmmaceth/eth0/dma_cap
> IEEE 1588-2002 Time Stamp: N
> IEEE 1588-2008 Advanced Time Stamp: Y

This is what I see

root@debian-trixie-riscv64:/# grep 'Time Stamp'
/sys/kernel/debug/stmmaceth/end0/dma_cap
IEEE 1588-2002 Time Stamp: N
IEEE 1588-2008 Advanced Time Stamp: Y

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 5774 bytes --]

On Oct 06, Anirudh Srinivasan wrote:
> Hi Lorenzo,
> 
> On Tue, Oct 6, 2026 at 1:57 AM Lorenzo Bianconi
> <lorenzo.bianconi@oss.qualcomm.com> wrote:
> >
> > > Hi Lorenzo,
> > >
> > > On Mon, Oct 5, 2026 at 4:53 PM Lorenzo Bianconi
> > > <lorenzo.bianconi@oss.qualcomm.com> wrote:
> > > >
> > > > > On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > > > > > stmmac_update_subsecond_increment() ignores the error returned by
> > > > > > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > > > > > addend and system time programming errors, always returning success. A
> > > > > > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > > > > > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > > > > > leaving the hardware timestamp counter in a non-running or partially
> > > > > > configured state while the driver keeps operating as if timestamping
> > > > > > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > > > > > base time from the hardware timestamp counter.
> > > > > >
> > > > > > The same hooks are also called from the PHC callbacks: settime64 and
> > > > > > adjfine drop the error and report success to clock_settime() and
> > > > > > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > > > > > ptp4l/phc2sys.
> > > > > >
> > > > > > Return error codes from stmmac_update_subsecond_increment(),
> > > > > > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > > > > > settime64/adjfine callbacks instead of silently returning success. On
> > > > > > failure, roll back the partially applied configuration so the hardware
> > > > > > and the driver bookkeeping stay consistent, and report the reason
> > > > > > through the devlink extack. Also guard against a zero sub-second
> > > > > > increment, which would otherwise divide by zero when computing the
> > > > > > addend.
> > > > > >
> > > > > > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > > > > > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > > > > > timestamping, so a failed init does not leave TX/RX timestamping
> > > > > > enabled on a counter that never started.
> > > > > >
> > > > > > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > > > > ---
> > > > > > Changes in v3:
> > > > > > - Do not run stmmac_config_addend() in
> > > > > >   stmmac_update_subsecond_increment() error path.
> > > > > > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > > > > > - Reset hw ts configuration in stmmac_init_timestamping().
> > > > > > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> > > > > >   routine.
> > > > > > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > > > > > ---
> > > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> > > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> > > > > >  2 files changed, 84 insertions(+), 32 deletions(-)
> > > > >
> > > > > Hello, I'm noticing that after this patch was merged into linux-next,
> > > > > boot seems to hang when ip=dhcp is used because ethernet isn't working
> > > > > on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> > > > > over
> > > > >
> > > > > IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > f2 mtu 1500 DHCP
> > > > > [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> > > > > [   24.912780] dwmac1000: Master AXI performs any burst length
> > > > > [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> > > > > [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> > > > > SIOCSIFFLAGS: Connection timed out
> > > >
> > > > Hi Anirudh,
> > > >
> > > > based on the reported error, stmmac_init_tstamp_counter() fails with
> > > > -ETIMEDOUT. In particular this can occurs if:
> > > >
> > > > stmmac_init_tstamp_counter()
> > > >  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
> > > >  -> stmmac_init_systime() -> -ETIMEDOUT
> > > >
> > > > I guess we should understand which one is failing and why it is failing.
> > >
> > > It seems like both are timing out, both config_addend
> > > (PTP_TCR_TSADDREG) and init_systime (PTP_TCR_TSINIT).
> >
> > It seems hw timestamping has never worked on this board, it was just
> > undiscovered since stmmac_init_tstamp_counter() was not reporting any
> > error before (this is exactly the goal of this patch).
> >
> > What are the output for:
> > - IEEE 1588-2002 Time Stamp
> > - IEEE 1588-2008 Advanced Time Stamp
> >
> > root@rb3-gen2:~# grep 'Time Stamp' /sys/kernel/debug/stmmaceth/eth0/dma_cap
> > IEEE 1588-2002 Time Stamp: N
> > IEEE 1588-2008 Advanced Time Stamp: Y
> 
> This is what I see
> 
> root@debian-trixie-riscv64:/# grep 'Time Stamp'
> /sys/kernel/debug/stmmaceth/end0/dma_cap
> IEEE 1588-2002 Time Stamp: N
> IEEE 1588-2008 Advanced Time Stamp: Y

Unfortunately I do not have this board for debugging. The first idea
I got is maybe 100ms is too small for this SoC? Can you please try to
increase it to like 500ms?

Regards,
Lorenzo
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Anirudh Srinivasan]

Helo Lorenzo,

On Tue, Oct 6, 2026 at 9:33 AM Lorenzo Bianconi
<lorenzo.bianconi@oss.qualcomm.com> wrote:
>
> On Oct 06, Anirudh Srinivasan wrote:
> > Hi Lorenzo,
> >
> > On Tue, Oct 6, 2026 at 1:57 AM Lorenzo Bianconi
> > <lorenzo.bianconi@oss.qualcomm.com> wrote:
> > >
> > > > Hi Lorenzo,
> > > >
> > > > On Mon, Oct 5, 2026 at 4:53 PM Lorenzo Bianconi
> > > > <lorenzo.bianconi@oss.qualcomm.com> wrote:
> > > > >
> > > > > > On Tue, Sep 29, 2026 at 03:10:11PM +0200, Lorenzo Bianconi wrote:
> > > > > > > stmmac_update_subsecond_increment() ignores the error returned by
> > > > > > > stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the
> > > > > > > addend and system time programming errors, always returning success. A
> > > > > > > failure to program the addend (PTP_TCR_TSADDREG) or to initialize the
> > > > > > > system time counter (PTP_TCR_TSINIT) is therefore silently swallowed,
> > > > > > > leaving the hardware timestamp counter in a non-running or partially
> > > > > > > configured state while the driver keeps operating as if timestamping
> > > > > > > were up. This matters for TAPRIO/EST offloading, which derives the gate
> > > > > > > base time from the hardware timestamp counter.
> > > > > > >
> > > > > > > The same hooks are also called from the PHC callbacks: settime64 and
> > > > > > > adjfine drop the error and report success to clock_settime() and
> > > > > > > clock_adjtime(), so a dead PTP reference clock goes unnoticed by
> > > > > > > ptp4l/phc2sys.
> > > > > > >
> > > > > > > Return error codes from stmmac_update_subsecond_increment(),
> > > > > > > stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the
> > > > > > > settime64/adjfine callbacks instead of silently returning success. On
> > > > > > > failure, roll back the partially applied configuration so the hardware
> > > > > > > and the driver bookkeeping stay consistent, and report the reason
> > > > > > > through the devlink extack. Also guard against a zero sub-second
> > > > > > > increment, which would otherwise divide by zero when computing the
> > > > > > > addend.
> > > > > > >
> > > > > > > Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en,
> > > > > > > tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing
> > > > > > > timestamping, so a failed init does not leave TX/RX timestamping
> > > > > > > enabled on a counter that never started.
> > > > > > >
> > > > > > > Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers")
> > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > Changes in v3:
> > > > > > > - Do not run stmmac_config_addend() in
> > > > > > >   stmmac_update_subsecond_increment() error path.
> > > > > > > - Return error from stmmac_adjust_freq() and stmmac_set_time().
> > > > > > > - Reset hw ts configuration in stmmac_init_timestamping().
> > > > > > > - Link to v2: https://lore.kernel.org/r/20260924-stmmac-ptp-added-systime-error-v2-1-beb2a6b5f866@oss.qualcomm.com
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Initialize sec_inc to 0 in stmmac_restore_subsecond_increment()
> > > > > > >   routine.
> > > > > > > - Link to v1: https://lore.kernel.org/r/20260920-stmmac-ptp-added-systime-error-v1-1-8ac9e7a3fce2@oss.qualcomm.com
> > > > > > > ---
> > > > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 106 ++++++++++++++++------
> > > > > > >  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |  10 +-
> > > > > > >  2 files changed, 84 insertions(+), 32 deletions(-)
> > > > > >
> > > > > > Hello, I'm noticing that after this patch was merged into linux-next,
> > > > > > boot seems to hang when ip=dhcp is used because ethernet isn't working
> > > > > > on the TH1520 Lichee Pi 4a. These lines get printed in a loop over and
> > > > > > over
> > > > > >
> > > > > > IP-Config: end0 hardware address 72:ca:a8:eb:27:[   24.872982] thead-dwmac ffe7070000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > f2 mtu 1500 DHCP
> > > > > > [   24.900412] thead-dwmac ffe7070000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
> > > > > > [   24.912780] dwmac1000: Master AXI performs any burst length
> > > > > > [   24.912801] thead-dwmac ffe7070000.ethernet end0: No Safety Features support found
> > > > > > [   25.010229] thead-dwmac ffe7070000.ethernet end0: PTP init failed
> > > > > > SIOCSIFFLAGS: Connection timed out
> > > > >
> > > > > Hi Anirudh,
> > > > >
> > > > > based on the reported error, stmmac_init_tstamp_counter() fails with
> > > > > -ETIMEDOUT. In particular this can occurs if:
> > > > >
> > > > > stmmac_init_tstamp_counter()
> > > > >  -> stmmac_update_subsecond_increment() -> stmmac_config_addend() -> -ETIMEDOUT
> > > > >  -> stmmac_init_systime() -> -ETIMEDOUT
> > > > >
> > > > > I guess we should understand which one is failing and why it is failing.
> > > >
> > > > It seems like both are timing out, both config_addend
> > > > (PTP_TCR_TSADDREG) and init_systime (PTP_TCR_TSINIT).
> > >
> > > It seems hw timestamping has never worked on this board, it was just
> > > undiscovered since stmmac_init_tstamp_counter() was not reporting any
> > > error before (this is exactly the goal of this patch).
> > >
> > > What are the output for:
> > > - IEEE 1588-2002 Time Stamp
> > > - IEEE 1588-2008 Advanced Time Stamp
> > >
> > > root@rb3-gen2:~# grep 'Time Stamp' /sys/kernel/debug/stmmaceth/eth0/dma_cap
> > > IEEE 1588-2002 Time Stamp: N
> > > IEEE 1588-2008 Advanced Time Stamp: Y
> >
> > This is what I see
> >
> > root@debian-trixie-riscv64:/# grep 'Time Stamp'
> > /sys/kernel/debug/stmmaceth/end0/dma_cap
> > IEEE 1588-2002 Time Stamp: N
> > IEEE 1588-2008 Advanced Time Stamp: Y
>
> Unfortunately I do not have this board for debugging. The first idea
> I got is maybe 100ms is too small for this SoC? Can you please try to
> increase it to like 500ms?

That doesn't help either.

Maybe someone more familiar with this board/has used PTP on it before
can help out understanding why this is happening. Maybe this is some
issue to do with clocks.

Regards
Anirudh

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Maxime Chevallier]

Hi,

On 10/6/26 17:12, Anirudh Srinivasan wrote:

> Maybe someone more familiar with this board/has used PTP on it before
> can help out understanding why this is happening. Maybe this is some
> issue to do with clocks.

Good point, can you give us the full dmesg log of the board booting ?

Maxime

Re: [PATCH net v3] net: stmmac: propagate PTP addend and system time programming errors

[Anirudh Srinivasan]

Hi,

On Tue, Oct 6, 2026 at 10:28 AM Maxime Chevallier
<maxime.chevallier@bootlin.com> wrote:
>
> Hi,
>
> On 10/6/26 17:12, Anirudh Srinivasan wrote:
>
> > Maybe someone more familiar with this board/has used PTP on it before
> > can help out understanding why this is happening. Maybe this is some
> > issue to do with clocks.
>
> Good point, can you give us the full dmesg log of the board booting ?

https://gist.github.com/asrinivasanTT/d1b7957cb6ec7bdfed66af5ea3a84631

Regards
Anirudh