Re: [PATCH 3/5] net: fec: initialize clock with 0 rather than current kernel time

[Richard Cochran]

On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote:
> Richard Cochran <richardcochran@xxxxxxxxx> 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.
> 
> Actually, as I just realized, the right solution for my original problem
> would rather be adding PTP clock ID that time stamped Ethernet packet to
> the Ethernet hardware time stamp (see my previous reply as well).

I think you misunderstood my point.  I wasn't commenting on the
"stacked" MAC/PHY/DSA time stamp issue in the kernel.

I am talking about the question of whether to initialize the PHC time
to zero (decades off from TAI) or ktime (likely about 37 seconds off
from TAI).  It does not really matter, because the user must not guess
whether the time is valid based on the value.  Instead, the user
should query the relevant PTP data sets in a "live" online manner.

For example, to tell whether a PHC is synchronized to anything at all,
you need to check PORT_DATA_SET.portState and probably also
CURRENT_DATA_SET.offsetFromMaster depending on your needs.

In addition, if you care about global time, you need to check:

TIME_PROPERTIES_DATA_SET
  currentUtcOffset
  currentUtcOffsetValid
  ptpTimescale
  timeTraceable
  frequencyTraceable

Thanks,
Richard