Re: [PATCH net-next v6 3/3] dpll: zl3073x: add PTP clock support

Sashiko findings and my replies:

 > By returning rc directly here, does this bypass the sec_adjusted
 > check at the end of the function? [...]
 > Should this path handle the timeout failure similarly to the fallback
 > path?

If tod_ready_wait fails, we cannot be certain that WR_NEXT_1HZ was
actually applied. Returning the error and letting the caller handle
the retry is the safer choice, because masking the error would
silently report success when the adjustment may not have been applied
at all.

 > If a previous API call (like zl3073x_dpll_ptp_settime64) issued a
 > ToD write and returned without waiting for the 1 Hz edge, could a
 > subsequent sub-second adjustment clobber it? [...]
 > Does the driver need to wait for pending ToD writes before issuing
 > sub-second adjustments regardless of the delta size?

All PTP callbacks are serialized by zldpll->lock. A subsequent
sub-second adjtime goes through zl3073x_chan_tod_adjust() which calls
zl3073x_chan_tod_read() which starts with zl3073x_chan_tod_ready_wait()
— this waits for any pending WR_NEXT_1HZ to complete. Phase step and
TIE write operate on independent hardware blocks and do not conflict
with pending ToD writes.

 > Similarly, zl3073x_dpll_ptp_adjphase() issues a TIE write without
 > checking for pending ToD writes. Could this phase adjustment also be
 > overwritten?

TIE write adjusts the DPLL input-to-output phase through a separate
hardware block. It does not modify the ToD counter and is not affected
by a pending WR_NEXT_1HZ.

Thanks,
Ivan