On Tue, 7 Mar 2023 at 07:33, Richard Cochran <richardcoch...@gmail.com> wrote: > On Tue, Mar 07, 2023 at 12:54:55AM +0100, Andrew Zaborowski wrote: > > It seems that port_is_ieee8021as(p) returning zero if p->as_capable == > > ALWAYS_CAPABLE was originally intended for skipping checks in > > port_capable but this is quite unclear. > > Maybe you should ask your Intel colleague what he had in mind? > > > There are only three callers > > left in the current code and this quirk doesn't seem to make them any > > more compliant with either 802.1AS version or the Automotive profile. > > More compliant? Either something complies or not. > > > On the other hand > > Where was the first hand? > > > the calculation of neighborRateRatio (in the Rx path) > > can now depend on the return value of port_is_ieee8021as() which seems > > to have been the intention, rather than on whether p->follow_up_info is > > set. The description of follow_up_info in the man page implies it > > rather affects the Tx path. > > It can be used on the client. > > > (The NRR will also need to be calculated > > in a future CMLDS instance, with or without 802.1AS, so this if clause > > will change again). > > Sorry, but this is completely incomprehensible. > > A proper commit message has three elements: > > 1. context > 2. problem > 3. solution
Right, the commit message wasn't great after editing it a few times, sorry. The (minor) problem this attempts to solve, and I didn't state that, is the confusing semantics and reduced utility of port_is_ieee8021as if one relies on the name. Best regards _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
