On Tue, 6 Jun 2023 14:24:20 -0400, Dylan Robinson wrote: > I guess what this all is trying to convey is that since peer delay > messages from a non-zero clock domain, are required to be invoked on > domain 0 when their transportSpecific value is 1, if we see a non-zero > domain number in a peer delay message we can assume that the message > is either malformed or has a transportSpecific value not equal to 1.
Just to tie this back to the patch, which doesn't look at the incoming transportSpecific value or the incoming clock domain, just at the ports own configuration, and the code only responds to messages that match its own configuration. This means that ensuring valid combinations of transportSpecific and clock domain numbers should probably be outside of the scope of this fix.
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
