On Tue, Feb 28, 2023 at 07:38:44PM +0100, Andrew Zaborowski wrote: > Hi Richard and Erez, > > On Tue, 28 Feb 2023 at 16:02, Richard Cochran <richardcoch...@gmail.com> > wrote: > > On Tue, Feb 28, 2023 at 09:36:07AM +0100, Erez wrote: > > > May break when using non Linuxptp, as far as I understand, linuxptp only > > > sets the field, but never checks the value. > > > > The risk is that some hardware implementations may check those fields > > and then fail to generate time stamps. > > > > In the case of the PTP minor version field, there are already two > > known bad HW devices that fail when the field is non-zero. Of course, > > this violates 1588-2008, but it proves the point that vendors don't > > follow the standard. > > Ok, that was a concern but I didn't know how likely it would be. > Given this would you agree to zeroing those values based on a setting?
No, I just wanted to point out the risk. So far, HW vendors track record has been abysmal. If there is a way to do wrong, then somebody sure will. The SW should zero the controlField unconditionally as called out in 1588-2019 clause 13.3.2.13. Previously I overlooked this silly detail because the change is not identified in 19.4 "Compatibility ... to IEEE Std 1588-2008". Anyhow, since we advertise PTP v2.1 then we should really clear the controlField. As a general rule, linuxptp doesn't make special hacks for broken hardware designs. I want this change in linuxptp version 4.0 together with the PTP 2.1 version bump, and so that will delay the release to allow some minimum soak time. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
