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

[Sergey Organov]

Vladimir Oltean <olteanv@xxxxxxxxx> writes:

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

It won't. Supposedly it'd force clock (that doesn't tick by default and
stays at 0) to start ticking.

If the ability to stop the clock is in fact useful (I don't immediately
see how it could), and how to do it if it is, is a separate issue. I'd
then expect clock_stop(clkid), or clock_settime(clkid, NULL) to do the
job.

Thanks,
-- Sergey