>
> IEEE 1588-2019 only define Integer64, but not UInteger64.
> Not sure why, but probably there is no UInteger64 in IEEE standard.
> Are you using UInteger64 for a standard parameter/variables?
>
[Devasish]: Yes this is not part of IEEE 1588. But it is part of ITU-T
G.8275. But this can be used fo
>
> > + /* Megabits per secon converted to attoseconds per bit. */
> > + return 1ULL/ iface->if_info.speed;
> Performing division in running is not a very good idea.
> It is better to perform the division when updating the speed and store
> it in if_info.
>
> Are you sure we
>
> > + goto failed;
> > + }
>
> I think it is better to merge this ioctl and the socket creation with
> sk_get_ts_info().
> No reason for duplication.
> You can use a static function or inline one.
>
> > +
> > + if (ecmd.req.link_mode_masks_nwords >= 0 ||
> > +
LSTAB_UNKNOWN is too generic, add LSTAB_EXPIRED result to return the latest
lstab correction and indicate that the tab used to resolve it is expired.
This is useful for more precise reporting of lstab file state and will enable an
override of expired table.
Signed-off-by: Maciek Machnikowski
Rev
This patch adds support for the leapfile in the generic pps source.
Such implementations prevents situtation when TAI offset is not set in the
system (which is true when there is no NTP daemon running that sets it) from
setting the UTC time in the disciplined PHC.
Leapfile and lstab will only be u
To enable handling lstab in the same way by different pps sources, move
update_leapsecond_table function from the nmea_pps_source to the generic lstab
file. This also required moving leapfile filename and its modification time to
the struct lstab.
Signed-off-by: Maciek Machnikowski
Reviewed-by: J
Current implementation of generic pps source relies on the UTC-TAI offset read
from system. Some OSes don't set that offset by default and return 0. In such
case ts2phc sets PHC time to UTC timescale without notifying user.
This patch series moves leapfile handling to lstab and reuses the logic th
