The main loop has become a bit messy, mixing two completely disjunct code
paths. This patch separates the two use cases for the sake of clarity.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This non-portable, implementation specific message is designed to inform
external programs about the relationship between the local clock and the
remote master clock.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The code to detect a new master used pointer equality using a stale
pointer within the clock instance. Instead, the clock needs to remember
the identity of the foreign master in order to correctly detect a
change of master.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
If a buggy driver or hardware delivers bogus time stamps, then we might
crash with a divide by zero exception.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
We are going to need this more than once for working with the
cumulativeScaledRateOffset fields.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
We have one timer used for both delay request mechanisms, and we ought
to set the message interval accordingly.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
- all of the original goals have been implemented
- add gPTP to the list of supported features
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
As some PHC hardware/drivers don't provide PPS, it may be useful to keep the
system clock synchronized to PHC via clock_gettime(). While the precision
of the clock is only in microsecond range, the error seems to be quite stable.
The -d parameter now can be omitted if -s is provided.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
As some PHC hardware/drivers don't provide PPS, it may be useful to keep the
system clock synchronized to PHC via clock_gettime(). While the precision
of the clock is only in microsecond range, the error seems to be quite stable.
The -d parameter now can be omitted if -s is provided.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
This fixes the following issue reported by valgrind, which occurs
after a port disable/initialize subsequent to having entered slave
mode.
==10651== Invalid read of size 4
==10651== at 0x804E6E2: fc_clear (port.c:175)
==10651== by 0x805132F: port_event (port.c:1352)
==10651== by 0x804B383: clock_poll (clock.c:597)
==10651== by 0x80498AE: main (ptp4l.c:278)
==10651== Address 0x41cba60 is 16 bytes inside a block of size 60 free'd
==10651== at 0x4023B6A: free (vg_replace_malloc.c:366)
==10651== by 0x804EB09: free_foreign_masters (port.c:287)
==10651== by 0x804FB14: port_disable (port.c:722)
==10651== by 0x8051228: port_dispatch (port.c:1298)
==10651== by 0x804B3C6: clock_poll (clock.c:602)
==10651== by 0x80498AE: main (ptp4l.c:278)
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Richard Cochran
Miroslav Lichvar
Delio Brignoli