On Thu, 19 Jan 2023 19:56:24 -0800 Rahul Rameshbabu wrote:

quoted

quoted

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.

Nice, can we make the core also call ->adjtime automatically if driver
doesn't define ->adjphase and the abs(delta) < .max_phase_adj ?

The other question is about the exact semantics of ->adjphase
- do all timecounter based clock implementations support it
by definition?