Re: [PATCH net-next v6 2/3] dpll: zl3073x: add channel ToD, phase step and TIE operations

Sashiko findings with replies:

 > Should the kernel-doc match what the function actually does here?
 > [case 0 returns without testing SEM]

Will restructure tod_ready_wait to check the SEM bit first. If SEM
is clear, no operation is pending and we can return 0 immediately
regardless of the CMD field value. This also handles the unknown-CMD
case from a prior boot stage gracefully — if the semaphore is clear,
whatever CMD bits remain are stale and irrelevant.

 > The documented return list [...] does not mention -EOPNOTSUPP.

Will update the return documentation.

 > Can this loop exhaust its 20 retries on healthy hardware and return
 > -EBUSY?

Testing shows that a single iteration of the loop body (two ToD
reads) takes approximately 17-19 ms. With 20 retries that gives a
budget of 340-380 ms, which is more than enough to outlast the 20 ms
margin window near a 1 Hz edge. After the edge crosses, the next
read returns ~980 ms of margin and the loop breaks immediately.

 > How is the measured margin guaranteed to still hold when the
 > WR_NEXT_1HZ command finally reaches the device? [...]
 > Would a post-write confirmation [...] be worth adding?

The 20 ms threshold provides sufficient margin for the write
sequence (ready wait + three register writes + command). A post-write
confirmation would add complexity for a scenario that requires ~20 ms
of preemption under a mutex, which is unreachable in practice.

 > The kernel-doc says delta_ns "must be within +-1s", which reads as an
 > inclusive bound, while the guard accepts only the open interval

Will reword to clarify the exclusive bound.

 > The ToD ready wait logic fails permanently if the hardware control
 > register inherits an unknown command from a prior boot stage.

Addressed by the SEM-first restructuring described above. If SEM is
clear, the function returns 0 regardless of the CMD bits.

Thanks,
Ivan