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

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 <redacted>
---
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 (local)

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 (local)
---
 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