On Fri, Jun 26, 2020 at 01:15:11PM +0300, Vladimir Oltean wrote: > So, to your point: I didn't see any driver that _rejects_ time in the > past. If it works, I don't know. If it doesn't work, I would do the > time fixup at driver level, so in my opinion there's no need for an > application-level flag. What do you think?
I agree with your analysis. Ideally the drivers would handle this perfectly.** But even if they could, still it will take months, maybe years to fix all the kernel drivers. Moreover, the user space stack would still need to work with the "legacy" kernels. So I think it will have to be a flag. Thanks, Richard ** Without hardware support, it is actually quite tricky to solve the race condition in software in a way which is 100% reliable. You are correct that setting the start time even a whole second in the future might not be enough on a non-preempt_rt kernel. Regarding the start=0 for HW without start time control, this is not an ideal interface. I would like to have a proper "frequency output" or "clock output" ABI in the PHC world. If you have the time, maybe this is something you like to work on? _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
