On Sat, 2018-08-18 at 00:03 -0400, Richard Cochran wrote: > On Thu, Aug 16, 2018 at 10:42:10AM -0700, Vedang Patel wrote: > > > > - In port_p2p_transition(), we are setting up the delay timer when > > BMCA is set > > as ‘noop’. Usually it is initialized then the device transitions > > to > > PS_LISTENING. But, we are skipping the LISTENING state. Another > > alternative > > is to transition to PS_LISTENING and then unconditionally > > transfer to > > PS_MASTER/PS_SLAVE. But, that seems more of an hack than what is > > currently > > being done. Any other alternatives? > Another idea: > > Can you have INITIALIZING -> LISTENING, and arrange for > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES to happen right away? > > Then your fsm does LISTENING -> SLAVE on the > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES event. > > (haven't looked at arranging that timeout, just brainstorming...) > We can do something on the lines of the following (completely untested) snippet:
diff --git a/port.c b/port.c index f4a9fbb5a8d7..214a8329d27e 100644 --- a/port.c +++ b/port.c @@ -1623,7 +1623,7 @@ int port_initialize(struct port *p) p->fda.fd[FD_FIRST_TIMER + i] = fd[i]; } - if (port_set_announce_tmo(p)) { + if (set_tmo_log(p->fda.fd[FD_ANNOUNCE_TIMER], 1, -10)) { goto no_tmo; } if (unicast_client_enabled(p) && unicast_client_set_tmo(p)) { This way, the timer will fire once (immediately after it's setup) even if inhibit_announce is set. But, there is going to be a likely effect on the normal working of linuxptp. We can fix this by only doing this when BMCA == noop. Again, will have to actually test this to see what issues might pop up. Thanks, Vedang > Thanks, > Richard > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel