On 7/10/26 3:08 PM, Vadim Fedorenko wrote:

On 08/07/2026 18:05, Ivan Vecera wrote:

quoted

Add PTP clock support for the ZL3073x DPLL driver. A PTP clock device
is registered for each DPLL channel that is in NCO mode, providing
gettimex64, settime64, adjtime, adjfine and perout callbacks.

Here we come back to the discussion of NCO mode. Is DPLL channel
actually a pin (virtual or physical)? If it's not, then it means that
channel is exposed as independent DPLL device, that shouldn't affect
other devices, but AFAIU, it can in the current implementation. If it is
a pin, why do you check device's mode rather then pins?

And another question - what happens when channel changes its mode to
non-NCO? Do we have ptp device disappearing from the system?

Hi Vadim,

I understand your point. The PTP code was originally developed before
the NCO pin switching was implemented, when it made sense to split PTP
support into two patches - basic PTP for NCO-only channels (patch 2) and
then extending it to all modes via TIE write (patch 4).

Now that NCO mode can be entered and left dynamically via the NCO pin,
this split no longer makes sense. Having patch 2 register PTP only for
NCO-mode channels creates an awkward intermediate state where a dynamic
NCO switch would require dynamic PTP clock registration/unregistration.

I'll squash patches 1&3 and 2&4 in v2, so the PTP clock is always
registered regardless of the initial channel mode, with per-callback
mode checks.

Thanks,
Ivan