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

Richard Cochran [off-list ref] writes:

On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote:

quoted

Richard Cochran [off-list ref] writes:

quoted

On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:

quoted

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 think I did. It's rather that initialization value of PHP clock has
consequences in MAC/PHY/DSA, and there is no way to check any flags
/there/. And it's exactly the place where I needed the info, see
background explanation below.

I understand what your point is, but I try to explain that it's
irrelevant for my particular use-case.

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.

I'm implementing PTP master clock, and there are no PTP data sets (yet)
in my case, as it's me who will eventually create them.

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.

These are fields of PTP stack software that is not running in my case.

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

TIME_PROPERTIES_DATA_SET
  currentUtcOffset
  currentUtcOffsetValid
  ptpTimescale
  timeTraceable
  frequencyTraceable

I'm going to become PTP master clock, I already have very precise
estimations of PTP time, I know UTC offset, all this independently from
any PTP stack. Moreover, I've already synchronized PHY clock to this
time scale with +-5ns accuracy, and then I suddenly get somewhat wrong
hardware time stamps for Ethernet packets that I send/receive. You see?

Setting initial value of PTP clock to 0 would allow me to figure what
happens (time stamp coming from /different/ PTP clock) half a day
earlier. Not a big deal, I agree, yet I wanted to help a little bit
somebody who might happen to run into a similar trouble in the future.

Thanks,
-- Sergey