lkml.org 
[lkml]   [2020]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 3/5] net: fec: initialize clock with 0 rather than current kernel time
Date
Richard Cochran <richardcochran@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

\
 
 \ /
  Last update: 2020-07-08 14:26    [W:0.104 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site