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

On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote:

Vladimir Oltean [off-list ref] writes:

quoted

On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:

quoted

Vladimir Oltean [off-list ref] writes:

quoted

What do you mean 'no ticking', and what do you mean by 'non-initialized
clock' exactly? I don't know if the fec driver is special in any way, do
you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
all return 0? That is not at all what is to be expected, I think. The
PHC is always ticking. Its time is increasing.

That's how it is right now. My point is that it likely shouldn't. Why is
it ticking when nobody needs it? Does it draw more power due to that?

quoted

What would be that initialization procedure that makes it tick, and
who is doing it (and when)?

The user space code that cares, obviously. Most probably some PTP stack
daemon. I'd say that any set clock time ioctl() should start the clock,
or yet another ioctl() that enables/disables the clock, whatever.

That ioctl doesn't exist, at least not in PTP land. This also addresses
your previous point.

struct timespec ts;
...
clock_settime(clkid, &ts)

That's the starting point of my own code, and I bet it's there in PTP
for Linux, as well as in PTPD, as I fail to see how it could possibly
work without it.

This won't stop it from ticking, which is what we were talking about,
will it?

Thanks,
-Vladimir