On Thu, 19 Jan, 2023 19:46:31 -0800 Jakub Kicinski [off-list ref] wrote:

On Wed, 18 Jan 2023 13:33:56 -0800 Jacob Keller wrote:

quoted

quoted

The adjtime function supports using hardware to set the clock offset when
the delta was supported by the hardware. When the delta is not supported by
the hardware, the driver handles adjusting the clock. The newly-introduced
adjphase function is similar to the adjtime function, except it guarantees
that a provided clock offset will be used directly by the hardware to
adjust the PTP clock. When the range is not acceptable by the hardware, an
error is returned.

Makes sense. Once you've verified that the delta is within the accepted
range you can just re-use the existing adjtime function.

Seems like we should add a "max_time_adj" to struct ptp_clock_info
and let the core call adjphase if the offset is small enough to fit.
Instead of having all drivers redirect the calls internally.

With guidance from Saeed on this topic, I have a patch in the works for
advertising the max phase adjustment supported by a driver through the
use of the PTP_CLOCK_GETCAPS ioctl. This is how the ptp stack handles
advertising the max frequency supported by a driver today. In linuxptp,
this ioctl is wrapped in a function call for getting the max frequency
adjustment supported by a device before ptp is actually run. I believe a
similar logic should occur for phase (time) adjustments. This patch
would introduce a "max_phase_adj" in ptp_clock_info that would be
handled in ptp_clock_adjtime in the ptp core stack.