[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 at 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