Richard Cochran <richardcoch...@gmail.com> writes: > On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote: >> There's no correct answer, I'm afraid. Whatever the default value of the >> clock may be, it's bound to be confusing for some reason, _if_ the >> reason why you're investigating it in the first place is a driver bug. >> Also, I don't really see how your change to use Jan 1st 1970 makes it >> any less confusing. > > +1 > > For a PHC, the user of the clock must check the PTP stack's > synchronization flags via the management interface to know the status > of the time signal.
Sorry, but I'm looking at it from the POV of PTP stack, so I don't have another one to check. If PTP clock itself had some means of checking for its quality (like last time is was synchronized, skew and offset estimations at that time, etc.), then it'd render its initial value mostly unimportant indeed. But even then, the original problem was that Ethernet packets were time stamped with the wrong (different) PTP clock, and there is no any flags or clock ID in the time stamp of Ethernet packet, so any flags attached to PTP clock are still useless. Thanks, -- Sergey
