On Mon, 2018-10-01 at 10:59 -0700, Richard Cochran wrote: > On Mon, Oct 01, 2018 at 05:24:48PM +0000, Patel, Vedang wrote: > > > > I will add the comment for clearing the SYNC_RX_TIMER. It is > > basically > > to clear out the event returned by poll(). > But why? Does the original code have a bug? Please explain. > In the original code, whenever we receive a FD_SYNC_RX_TIMER timeout, it is usually accompanied by a state transition. So, port_*_transition() will take care of clearing the event for us (by calling port_clr_tmo() at the beginning). But, when BMCA == 'noop', there is nothing to do, so we are not clearing out the event and poll() will report the event in every loop. I am just taking care of clearing this event here. > > > > But, I don't understand how moving the inhibit_announce before this > > will help. > You avoid changing the behavior of the non-noop-BCMA code. > > > > > I am not removing the hunk anywhere. > You are right. I misread the next patch. > > BUT you avoid changing the original behavior by doing this: > > if (p->inhibit_announce) { > port_clr_tmo(p->fda.fd[FD_ANNOUNCE_TIMER]); > port_clr_tmo(p->fda.fd[FD_SYNC_RX_TIMER]); > } else { > port_set_announce_tmo(p); > } > The SYNC_RX_TIMER needs to be cleared out whenever BMCA == 'noop' (or any other future state machine which does not do any state transition in this case). I will add the condition to clear out the timer only when BMCA == 'noop'.
Thanks, Vedang > See? > > Thanks, > Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel