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

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote:
> Vladimir Oltean <olteanv@gmail.com> writes:
> 
> > On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
> >> Vladimir Oltean <olteanv@gmail.com> writes:
> >> >
> >> > 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?
> >> 
> >> > 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