Hi Miroslav,
Thanks for the quick review!
The overall use case is to use pps-gpio and GPS clock to synchronize system
clock to UTC, and then synchronize that UTC time to nodes on the network
using PTP.
We use ppsctl to bind PPS kernel consumer to GPIO signal:
tmx.modes = ADJ_STATUS;
tmx.status |= (STA_PPSFREQ | STA_PPSTIME);
Unfortunately, when phc2sys starts, even if it's reading from the system
clock and synchronizing to PHC, it resets the UTC leap second on the system
clock and discards PPS flags.
Discarding previous status flags seems like a more desirable behavior in
the sysclk_set_sync() case, since in that case you're controlling the clock
and you may actually remove flags like PPS, that's why I did not modify
that function.
Hopefully that helps understand the use case. Good catch on the
realtime_leap_bit, I will fix that.
Thanks,
Alex
On Wed, Jan 13, 2021 at 1:01 AM Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Tue, Jan 12, 2021 at 11:54:47PM -0800, Alex Sergeev wrote:
> > The current version of the code resets status flags, with the exception
> > of the leap second flag.
> >
> > The fix is to read previously set flags and add STA_INS/STA_DEL on top
> > of them.
>
> Can you please describe the use case when the status shouldn't be
> reset? And why only in the sysclk_set_leap() function and not in
> sysclk_set_sync()?
>
> In any case, I think the realtime_leap_bit variable should contain
> just the STA_INS or STA_DEL flag, not other unreleated flags.
>
> --
> Miroslav Lichvar
>
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
